Search Results api_trc_on

Overview

APPS.HR_DATA_PUMP is the Oracle E-Business Suite Data Pump engine for the Oracle HRMS (Human Resources Management System) product family. It provides the runtime infrastructure that extracts, stages, and transfers large volumes of HR data between source and target systems, and it supplies the logging and tracing framework used by the Meta Mapper-generated code paths and the get_id function calls that surround Data Pump activity. The header comment in hrdpump.pkh (version 120.1, dated 2006) describes the package simply as holding "the definition for the Data Pump engine." The package is classified as OTHER in the ETRM repository and resides in the APPS schema under Oracle EBS 12.1.1 and 12.2.2.

Although its procedures are declared public, the source notes explicitly state that they "should not be called directly." Concurrent manager definitions are shipped to allow Data Pump to be run through the concurrent manager, which is the supported entry point for the engine. The package is therefore infrastructure rather than an end-user application API.

Key Procedures and Functions

ETRM documents ten procedures and functions for this package:

• ENTRY — logs an entry message, flagging entry into a procedure for diagnostic and audit purposes.
• EXIT — logs an exit message, flagging exit from a procedure, complementing ENTRY to bracket execution.
• API_TRC_ON — turns tracing on before an API call, enabling the Data Pump trace/logging strategy.
• API_TRC_OFF — turns tracing off after an API call. This is the routine associated with the search term "api_trc_off" and is the counterpart to API_TRC_ON.
• MESSAGE — writes a message to the Data Pump log/error infrastructure.
• FAIL — handles failure conditions within the engine, raising or recording the failure.
• SLAVE — the slave/worker-side processing entry point for distributed Data Pump execution.
• MAIN — the master-side entry point that drives a Data Pump run.
• PURGEMAIN — the master-side purge routine for removing or archiving Data Pump run data.
• PURGESLAVE — the slave-side purge routine.

The ENTRY/EXIT and API_TRC_ON/API_TRC_OFF pairs implement the public portion of the Data Pump logging strategy; the header notes that these are complemented by private procedures and were declared public specifically so they can be invoked from Meta Mapper generated code and get_id calls.

Tables Accessed

Through APPS synonyms the package references the following tables and objects:

• HR_PUMP_BATCH_HEADERS, HR_PUMP_BATCH_LINES, HR_PUMP_BATCH_LINE_USER_KEYS — the core batch staging tables holding header, line, and user-key detail for each Data Pump batch.
• HR_PUMP_BATCH_EXCEPTIONS, HR_PUMP_BATCH_EXCEPTIONS_S — record and sequence exceptions encountered while processing batch lines.
• HR_PUMP_RANGES — defines the data ranges/chunks that the engine processes.
• HR_PUMP_REQUESTS — tracks Data Pump request submissions and their status.
• HR_API_MODULES — the HRMS API module registration used by the tracing mechanism.
• FND_NEW_MESSAGES — the Oracle Application Object Library message repository used for message lookup.
• DBMS_SQL — dynamic SQL execution for the extraction/transfer logic.
• PLITBLM — the PL/SQL index-by-table of VARCHAR2 type used for bulk collections.

Together these objects constitute the persistent state of a Data Pump run: batches, lines, exceptions, ranges, and requests, with FND_NEW_MESSAGES supplying message text and HR_API_MODULES supporting trace control.

Usage Notes

HR_DATA_PUMP is normally invoked through concurrent manager definitions rather than by direct call. Oracle's documentation states the procedures are public but should not be called directly, and that concurrent manager definitions exist to allow Data Pump to run via the manager. Tracing around API calls is performed by calling API_TRC_ON prior to the API and API_TRC_OFF following it; these two procedures are the ones most commonly referenced in custom or generated code and in searches such as "api_trc_off."

ETRM shows the package is referenced by 267 other packages, confirming its role as a shared infrastructure dependency across HRMS. Customizations should invoke the API TRC pairs and logging routines only as directed by Oracle, and should not call MAIN, SLAVE, FAIL, or the purge routines directly, since these are driven by the concurrent manager and the engine's own control flow.