Search Results hz_imp_load_wrapper




Overview
Explore in AI Chat

Overview

The APPS.HZ_IMP_LOAD_WRAPPER package body is the orchestration layer of the Oracle EBS Trading Community Architecture (TCA) bulk import framework. Its principal business function is to drive the loading of party, contact, address, and relationship data from the HZ interface (staging) tables into the production TCA entities, providing a controlled, restartable, and auditable entry point for high-volume customer and supplier master data. In Oracle EBS 12.1.1 and 12.2.2, the package is the runtime engine invoked by the Customer Interface and related concurrent programs, coordinating batch identification, work unit generation, parallel loader execution, error capture, and post-load cleanup.

Key Procedures and Functions

The documented API surface exposes nine procedures and functions that together implement a complete load cycle:

  • DATA_LOAD — the primary driver that executes the end-to-end import for a submission, invoking preprocessing, work unit generation, loader execution, and cleanup.
  • BATCH_DATA_LOAD — performs import processing scoped to one or more import batches, allowing targeted reprocessing of selected data sets.
  • ONLINE_DATA_LOAD — supports online (form-driven or synchronous) loads rather than the concurrent, batch-oriented path.
  • RETRIEVE_WORK_UNIT — returns the next available work unit for processing, forming the basis of parallel worker coordination.
  • RETRIEVE_PP_WORK_UNIT — retrieves work units for a specific processing phase or parallel program variant.
  • GENERATE_ENTITIES_WORK_UNITS — partitions the staged rows in the interface tables into discrete work units assigned to entity loaders.
  • DATA_LOAD_PREPROCESSING — executes preparatory validation and setup steps before loading commences.
  • CLEANUP_STAGING — purges or resets interface staging rows after a successful load.
  • STAGING_DATA_EXISTS — a check function that reports whether unprocessed staging data remains, used to gate further processing.

Tables Accessed

The package operates extensively over the HZ import interface and production tables. Staging tables such as HZ_IMP_PARTIES_INT, HZ_IMP_ADDRESSES_INT, HZ_IMP_ADDRESSUSES_INT, HZ_IMP_CONTACTS_INT, HZ_IMP_CONTACTPTS_INT, HZ_IMP_CONTACTROLES_INT, HZ_IMP_CLASSIFICS_INT, HZ_IMP_CREDITRTNGS_INT, HZ_IMP_FINNUMBERS_INT, HZ_IMP_FINREPORTS_INT, and HZ_IMP_RELSHIPS_INT hold inbound records awaiting validation and load. Corresponding _SG staging variants act as the working sets. Bookkeeping and diagnostics are maintained in HZ_IMP_BATCH_DETAILS, HZ_IMP_BATCH_SUMMARY, HZ_IMP_ERRORS, and HZ_IMP_TMP_ERRORS. Production targets include HZ_PARTIES, HZ_PARTY_SITES, HZ_RELATIONSHIPS, HZ_CONTACT_POINTS, HZ_ORGANIZATION_PROFILES, and HZ_CLASS_CATEGORIES. The package relies on FND infrastructure tables including FND_CONCURRENT_REQUESTS and FND_NEW_MESSAGES for request tracking and message resolution.

Usage Notes

HZ_IMP_LOAD_WRAPPER is normally invoked through the TCA bulk import concurrent programs, which submit it as the loading engine following successful staging. It is not intended for direct ad hoc invocation; callers should use the supported concurrent program or the public import APIs. The package is referenced by fifteen other database objects, underscoring its role as a dependency for higher-level import and reconciliation logic. Because processing is work-unit based, the package supports parallel workers and restartable recovery, with STAGING_DATA_EXISTS and error tables enabling reruns of failed batches. Customizations that bypass the wrapper or modify staging tables directly risk inconsistent batch summaries and orphaned error records, so extensions should respect the standard sequencing of preprocessing, work unit generation, loader execution, and cleanup.