Search Results igs_ad_api_int

Overview

IGS_AD_API_INT is a reporting and integration view owned by the APPS schema within the Oracle E-Business Suite Student System (IGS) product family. The object is documented as VALID in ETRM for releases 12.1.1 and 12.2.2. Its name follows the IGS naming convention for interface staging objects: the "AD" segment associates it with the admissions/student administration area, "API" denotes the public application programming interface layer, and the "_INT" suffix indicates an interface or inbound staging structure. The view presents the contents of the underlying interface table IGS_AD_API_INT_ALL through a filtered, Multi-Org-enabled lens, exposing the operational columns required for processing incoming records and for diagnostic reporting on their status.

The view is not an end-user inquiry screen; it functions as a programmatic access point. Concurrent programs, PL/SQL APIs, and external integration routines query it to determine which staged rows are pending, matched, or in error. Because it surfaces WHO columns, request identifiers, and error codes alongside the functional data, it also serves as the primary evidence source when troubleshooting failed loads into the admissions tables.

Underlying Base Objects

The view is defined over a single documented base object, IGS_AD_API_INT_ALL. The defining SQL performs a SELECT of explicit columns plus TAB.ROWID aliased as ROW_ID from that table, meaning the view is a straightforward projection with no joins, unions, or aggregations. No additional base objects are documented in the ETRM metadata. The important consequence of this definition is that the view is functionally a row-preserving, column-renaming layer: every row in IGS_AD_API_INT corresponds one-to-one with a row in IGS_AD_API_INT_ALL, and the ROW_ID column supplies the physical row locator needed for positioned updates. The "_ALL" suffix on the base table confirms that the table is partitioned by operating unit through the ORG_ID column, and the view is the interface point through which Multi-Org security and application logic address those rows.

Key Columns

The columns fall into four functional groups:

• Technical and audit columns: ROW_ID (the base table row locator), CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE. These identify the concurrent request that created or last touched the row.
• Multi-Org and processing control: ORG_ID (operating unit), STATUS, MATCH_IND, and ERROR_CODE. STATUS indicates the processing state of the interface row; MATCH_IND records whether a matching person or record was found; ERROR_CODE carries the failure reason when processing does not complete.
• Functional admissions data: PERSON_ID_TYPE, ALTERNATE_ID, START_DT, and END_DT define the person identifier being staged and its effective date range. INTERFACE_ID and INTERFACE_API_ID link the row to the parent interface definition and API call.
• Descriptive flexfield and region data: ATTRIBUTE_CATEGORY, ATTRIBUTE1 through ATTRIBUTE20, and REGION_CD. The twenty attribute columns follow the standard EBS DFF pattern and hold client-specific or region-specific supplementary data.

Common Use Cases and Queries

Typical diagnostic queries filter on STATUS, ERROR_CODE, or ORG_ID. To list failed inbound rows for the current operating unit:

• SELECT interface_id, alternate_id, status, error_code, creation_date FROM igs_ad_api_int WHERE status = 'E' ORDER BY creation_date DESC;
• SELECT org_id, status, COUNT(*) FROM igs_ad_api_int GROUP BY org_id, status;
• SELECT request_id, program_id, COUNT(*) FROM igs_ad_api_int WHERE request_id IS NOT NULL GROUP BY request_id, program_id;

These patterns support error reconciliation, throughput monitoring of the admissions interface, and audit of which concurrent request populated each staged record. Because the view exposes the base table ROWID as ROW_ID, corrective updates should generally be applied to IGS_AD_API_INT_ALL rather than through the view.