Search Results igs_ad_rel_con_int

Overview

IGS_AD_REL_CON_INT is a view in the APPS schema belonging to the IGS (Student System) product family in Oracle EBS 12.1.1 and 12.2.2. It presents the contact point interface data used by the Oracle Student System for the processing and validation of relationship contact information before that information is loaded into the permanent person or organization contact tables. The view exposes a single logical row per staged contact point record, including email addresses, phone numbers, and processing status flags, and its column list mirrors the denormalized structure of the interface staging table.

The object is documented in ETRM with a status of VALID and is classified as a VIEW. In EBS reporting and integration contexts, views such as this one are commonly used to decouple downstream queries and concurrent programs from the physical staging table, providing a stable projection that can be queried without knowledge of partition or organization-specific storage details.

Underlying Base Objects

The view text documented in ETRM shows that IGS_AD_REL_CON_INT is defined entirely over a single base object: IGS_AD_REL_CON_INT_ALL. The projection is a straightforward SELECT of columns from that table, aliased as TAB, along with the ROWID of the underlying row exposed as ROW_ID. No joins, unions, or aggregations are present. This "ALL" suffix in the base table name is significant in EBS: tables with the _ALL suffix are multi-organization enabled, and the view projects the ORG_ID column directly, allowing consumers to filter contact point records by operating unit or organization.

Because the view contains no WHERE clause, it returns every row present in IGS_AD_REL_CON_INT_ALL, including rows at any status. No base tables or additional referenced objects are documented beyond IGS_AD_REL_CON_INT_ALL. The view text documented in ETRM was captured from the 12.2.2 environment, and the same projection logic applies in 12.1.1.

Key Columns

• ROW_ID — the ROWID of the underlying row in IGS_AD_REL_CON_INT_ALL, useful for direct row identification and DML by interface processing programs.
• ORG_ID — the operating unit / organization identifier, reflecting the multi-org nature of the base table.
• INTERFACE_REL_CON_ID — the primary interface identifier for the contact point record.
• INTERFACE_RELATIONS_ID — the interface identifier of the parent relationship record to which the contact point belongs.
• CONTACT_POINT_TYPE — the type of contact point, such as email or phone.
• EMAIL_ADDRRESS — the staged email address value. Note the spelling "ADDRRESS" with the doubled R, which is the literal column name in the underlying table and view; this spelling is a known artifact and must be used exactly in SQL.
• EMAIL_FORMAT — indicates the expected or validated format for the email contact point.
• PRIMARY_FLAG — indicates whether the contact point is the primary one for its owner.
• PHONE_LINE_TYPE, PHONE_COUNTRY_CODE, PHONE_AREA_CODE, PHONE_NUMBER, PHONE_EXTENSION — the individual components of a staged telephone contact point.
• STATUS, MATCH_IND, ERROR_CODE, DUP_CONTACT_POINT_ID — interface processing controls: the current status of the staged row, the match indicator against existing data, the error code produced on validation failure, and the identifier of any duplicate contact point detected.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard who-column auditing attributes.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program context identifying the run that created or last processed the row.

Common Use Cases and Queries

The primary use case is monitoring and troubleshooting the relationship contact point import process. Technical consultants query the view to inspect which email address values were staged, whether they passed validation, and what error codes were raised. A second use case is reconciliation: comparing the staged values against the permanent contact tables once the import completes.

To list all staged email contact points for a given organization:

• SELECT interface_rel_con_id, interface_relations_id, email_addrrress, email_format, primary_flag, status FROM apps.igs_ad_rel_con_int WHERE org_id = :p_org_id AND contact_point_type = 'EMAIL';

To identify rows that failed validation:

• SELECT interface_rel_con_id, email_addrrress, error_code, dup_contact_point_id FROM apps.igs_ad_rel_con_int WHERE status = 'E' OR error_code IS NOT NULL;

To trace the concurrent program run that staged the data:

• SELECT request_id, program_id, program_update_date, created_by, creation_date FROM apps.igs_ad_rel_con_int WHERE interface_relations_id = :p_relations_id ORDER BY creation_date;

Because the view is a simple projection over a multi-org staging table, queries should always constrain on ORG_ID where meaningful, and any reference to the email column must reproduce the documented spelling EMAIL_ADDRRESS precisely.