Search Results data_load_preprocessing




Overview

HZ_IMP_LOAD_WRAPPER is the central orchestration package within the Oracle E-Business Suite Trading Community Architecture (TCA) bulk import framework. It provides the entry points that drive the loading of customer, contact, and address records from the HZ import interface tables into the base TCA registry. The package is owned by APPS and is classified as an OTHER API in the ETRM repository, reflecting its role as an internal driver rather than a public extension API. The header revision (ARHLWRPS.pls 120.14) and the use of AUTHID CURRENT_USER indicate it has been a stable, long-lived component since Release 11i and remains in use through 12.1.1 and 12.2.2.

The package encapsulates the full data-load lifecycle: staging-table preprocessing, work-unit generation and retrieval for parallel workers, the actual DML against the TCA registry, and post-load cleanup. It is the programmatic backbone behind the Customer Interface concurrent program and the interactive bulk import flows, and it is referenced by 15 other packages in the ETRM inventory.

Key Procedures and Functions

The ETRM metadata documents nine procedures that together constitute the public surface of the package:

  • DATA_LOAD — The main wrapper for running a data load. It accepts the batch identifier, originating system, What-If analysis flag, registry de-duplication options, batch mode, worker count, error limit, rerun flag, and concurrent request context (request ID, program ID, program application ID). It returns the standard concurrent-program Errbuf and Retcode OUT parameters.
  • BATCH_DATA_LOAD — A wrapper for running a batch data load. It is documented as a caller of DATA_LOAD and provides the batch-oriented invocation path.
  • ONLINE_DATA_LOAD — The entry point used for interactive, single-record or small-volume loads originating from the application forms, as opposed to large batch imports.
  • RETRIEVE_WORK_UNIT — Allocates and returns a unit of work for a batch worker, enabling parallel processing of the staging data.
  • RETRIEVE_PP_WORK_UNIT — Retrieves a work unit in the context of post-processing, distinct from the primary load pass.
  • GENERATE_ENTITIES_WORK_UNITS — Divides the entities staged for a batch into work units that can be distributed to concurrent workers by RETRIEVE_WORK_UNIT.
  • DATA_LOAD_PREPROCESSING — Performs the preprocessing of staging data before the main load. This is the object most commonly associated with the search term "data_load_preprocessing." It prepares and validates interface rows so that the load phase consumes clean, consistent input.
  • CLEANUP_STAGING — Removes or archives staging rows once processing for a batch completes, preventing the interface tables from accumulating obsolete data.
  • STAGING_DATA_EXISTS — A check routine that determines whether staging data is present for a given batch or context, typically used to guard processing steps against empty input.

Tables Accessed

The package operates primarily against the HZ import interface tables. The documented references include HZ_IMP_ADDRESSES_INT and its shadow table HZ_IMP_ADDRESSES_SG, HZ_IMP_ADDRESSUSES_INT / HZ_IMP_ADDRESSUSES_SG, HZ_IMP_CLASSIFICS_INT / HZ_IMP_CLASSIFICS_SG, and HZ_IMP_CONTACTPTS_INT / HZ_IMP_CONTACTPTS_SG. The _INT tables hold incoming staged rows; the _SG counterparts hold surrogate/derived values used during processing. HZ_IMP_CONTACTROLES_INT carries contact-role staging data.

Batch-level control and reporting is handled through HZ_IMP_BATCH_DETAILS and HZ_IMP_BATCH_SUMMARY, which record the progress and outcome of each import batch. Reference lookups draw on HZ_CLASS_CATEGORIES and HZ_CONTACT_POINTS. Concurrent-processing context is obtained from FND_CONCURRENT_REQUESTS, and worker or error messaging leverages FND_NEW_MESSAGES.

Usage Notes

HZ_IMP_LOAD_WRAPPER is normally invoked as the PL/SQL body of concurrent programs — most notably the Customer Interface and its batch variants — where DATA_LOAD or BATCH_DATA_LOAD is executed with the standard concurrent-program parameter signature. Interactive forms such as the Customers and Contacts screens call ONLINE_DATA_LOAD for real-time processing.

Because the package holds the work-unit distribution logic, system administrators control throughput through the P_NUM_OF_WORKERS, P_ERROR_LIMIT, and P_BATCH_MODE_FLAG parameters rather than by custom coding. The What-If and registry de-duplication options allow users to preview matching results before committing data to the registry. Release considerations apply when planning upgrades: the package is part of the TCA bulk import framework and should be patched through standard ADOP/autopatch cycles rather than modified directly, since custom changes to its specification or body are not upward-compatible and are overwritten by Oracle patches. When diagnosing failed imports, the HZ_IMP_BATCH_SUMMARY and HZ_IMP_BATCH_DETAILS tables, together with the concurrent request log produced by DATA_LOAD, are the primary sources of error information, and CLEANUP_STAGING must be run — or allowed to run — to release staging resources between batches.