Search Results igs_pe_intl_visa_flex
Overview
IGS_AD_IMP_026 is a PL/SQL package body in the APPS schema that supports the SEVIS (Student and Exchange Visitor Information System) interface within Oracle E-Business Suite. Its primary business function is the bulk import and validation of international student data — specifically visa, passport, visit history, address, and person EIT (Extra Information Type) records — from the staging/interface tables maintained in the IGS product family into the permanent party (HZ) and person (IGS_PE) base tables. The package originated from bug 2599109 in December 2002 and has undergone multiple revisions addressing record-level validation efficiency, overlap checking, logging, and message clarity.
The object is classified as OTHER under the ETRM API classification scheme. It is referenced by three other packages, indicating it functions as a shared validation and import utility rather than an end-user-facing API. The header revision notes confirm that the package was explicitly designed to be called by the Visa, Passport, and Visit History public APIs, achieved by moving the previously internal validate_record logic to the package level and exposing public validation entry points.
Key Procedures and Functions
The documented interface exposes eight procedures and functions:
- PRC_PE_VISA — Imports and processes visa interface records from the staging table into the base visa table.
- PRC_PE_PASSPORT — Imports and processes passport interface records into the permanent passport table.
- PRC_PE_VISIT_HISTRY — Imports and processes visit history interface records into the base visit history table.
- PRC_PE_EIT — Imports person Extra Information Type records from the EIT interface table into the base EIT table.
- PRC_PE_ADDR — Imports address interface records, resolving them against the HZ location and party site entities.
- VALIDATE_VISA_PUB — Public validation routine for visa data, called by the Visa public API. Includes overlap checks against existing visa history per bug 2783882.
- VALIDATE_VISIT_HISTRY_PUB — Public validation routine for visit history data, performing analogous overlap checking.
- VALIDATE_PASSPORT_PUB — Public validation routine for passport data, invoked by the Passport public API.
Revision notes indicate that validation was moved out of the main per-record loop into a bulk pre-loop step (bug 3130316) to improve performance, and that generic duplicate/overlap messages were replaced with component-specific messages (bug 4654248). The internal cursor visa_dtls selects interface rows with status '2' for a given interface_run_id, joining to IGS_AD_INTERFACE_ALL to obtain the person identifier.
Tables Accessed
The package operates across interface and base tables using APPS synonyms:
- Interface/staging tables: IGS_PE_VISA_INT, IGS_PE_PASSPORT_INT, IGS_PE_VST_HIST_INT, IGS_PE_EIT_INT, IGS_AD_ADDR_INT_ALL, and IGS_AD_INTERFACE_ALL — these hold unvalidated inbound SEVIS data and supply the person_id linkage and run identifiers.
- Base tables: IGS_PE_VISA, IGS_PE_PASSPORT, IGS_PE_VISIT_HISTRY, and IGS_PE_EIT — the destination tables into which validated records are inserted or updated.
- Party model tables: HZ_LOCATIONS and HZ_PARTY_SITES — referenced during address import to resolve or create location and party site associations.
- PLITBLM — an Oracle-supplied PL/SQL table/array type used for bulk collection processing during the bulk validation phase introduced in bug 3130316.
Usage Notes
This package is typically invoked by concurrent programs or the SEVIS inbound interface processing that batch-loads student visa, passport, and visit history data. It is also invoked programmatically by the IGS Visa, Passport, and Visit History public APIs, which call VALIDATE_VISA_PUB, VALIDATE_PASSPORT_PUB, and VALIDATE_VISIT_HISTRY_PUB respectively. The internal import procedures commit every 100 processed records, as noted in bug 2734697. Because imports depend on the interface_run_id and status flag of '2', callers must first populate the relevant interface tables and set status appropriately. Custom code should not bypass the public validation routines, since overlap checking against existing visa and visit history records is enforced there.