Search Results igr_i_char_int_pk

Overview

IGR_I_CHAR_INT is an interface (staging) table in the Oracle E-Business Suite IGS – Student System schema. The ETRM metadata classifies the product area as obsolete, and the table is documented as "Not implemented in this database," meaning the object is catalogued for reference in EBS 12.1.1 and 12.2.2 but is not deployed in the target instance. Its stated purpose is to hold admission inquiry characteristic interface records — the transient rows that capture characteristics associated with admission inquiries before they are validated, transformed, and loaded into the permanent Student System admission tables.

In the EBS inbound-interface pattern, a table such as this acts as a landing zone between an external source system (a prospect or recruitment system) and the application's base tables. Rows are written with interface-scoped surrogate identifiers, processed by a concurrent program, and then marked as succeeded or failed via status and error columns. The ETRM heuristic Data Vault classification for this object is standalone: no foreign-key relationships were mined, so the object is best modelled as an independent staging construct rather than as a hub, link, or satellite. Where a Data Vault pattern is applied downstream, the validated results would typically feed a characteristic satellite attached to a student or inquiry hub; the interface table itself remains a source-system artifact.

Key Information Stored

The documented physical schema comprises 19 columns owned by IGS. The most significant columns are:

• INTERFACE_INQ_CHAR_ID — the surrogate primary key, defined by the unique index IGR_I_CHAR_INT_PK. It identifies a single interface row and is not a business identifier.
• INTERFACE_INQ_APPL_ID — links the characteristic row to its parent inquiry application record within the same interface batch. This is the principal grouping column for processing.
• INQUIRY_CHARACTERISTIC_TYPE — the classification of the characteristic being captured (for example, a recruitment source or interest attribute). Together with INTERFACE_INQ_APPL_ID this forms the closest thing to a business-key candidate; the only documented unique index is the surrogate PK, so no true business key is enforced.
• STATUS and MATCH_IND — the processing outcome and match flags used to determine whether the row was applied, rejected, or matched to an existing record.
• ERROR_CODE and ERROR_TEXT — the diagnostic pair populated when validation or load fails, enabling remediation and reprocessing.
• INTERFACE_RUN_ID — identifies the interface execution that created the row, allowing batches to be isolated.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — standard concurrent-manager audit columns tying each row to the program and request that processed it.
• PERSON_ID and ENQUIRY_APPL_NUMBER — the external or derived person reference and the enquiry application number carried from the source system.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the mandatory EBS who-columns, present on the table but omitted from the WHERE clauses of most interface queries.

Common Use Cases and Queries

Typical usage centres on monitoring, error triage, and reconciliation of an interface run. A row-count and status summary for a given run is the most frequent query:

• SELECT status, match_ind, COUNT(*) FROM igr_i_char_int WHERE interface_run_id = :run_id GROUP BY status, match_ind;
• SELECT interface_inq_char_id, interface_inq_appl_id, inquiry_characteristic_type, error_code, error_text FROM igr_i_char_int WHERE status = 'E'; — to list rejected rows for correction.
• SELECT a.interface_inq_appl_id, a.person_id, a.enquiry_appl_number, c.inquiry_characteristic_type FROM igr_i_char_int c JOIN <admission inquiry interface header> a ON a.interface_inq_appl_id = c.interface_inq_appl_id; — to reconstitute a characteristic set for one enquiry application.

Reporting use cases include throughput and failure-rate metrics per interface run, source-system data-quality profiling of characteristic types, and pre-load reconciliation against the source extract. Because the table is not implemented in this database, these patterns describe intended behaviour and should be validated against the actual deployment before use.

Related Objects

The metadata documents no foreign-key relationships, consistent with the standalone Data Vault classification. The following objects are the most likely participants in the same interface flow, joined on the columns indicated:

• The admission inquiry interface header/parent table, joined on INTERFACE_INQ_APPL_ID, which supplies PERSON_ID and ENQUIRY_APPL_NUMBER context.
• The corresponding IGS interface error or staging tables keyed by INTERFACE_INQ_CHAR_ID or INTERFACE_RUN_ID.
• The concurrent program and request metadata identified by PROGRAM_APPLICATION_ID, PROGRAM_ID, and REQUEST_ID.
• The permanent admission inquiry characteristic base table that the interface loads into after validation.
• Person and enquiry base tables referenced through PERSON_ID and ENQUIRY_APPL_NUMBER.

Implementers should treat IGR_I_CHAR_INT as an obsolete, non-deployed artefact for reference only, and confirm current object names against the live IGS schema before designing interfaces or reports.