Search Results check_slaves_status




Overview
Explore in AI Chat

Overview

APPS.PER_RI_PRE_DATAPUMP is a PL/SQL package body in the Oracle E-Business Suite Human Resources (PER) product family. Its stated purpose in the source header is to serve as a wrapper for Data Pump functionality invoked from the workbench, and its documented function relates to the Enrollment Process. In practical terms, the package orchestrates the pre-processing and upload of HR enrollment data files through Oracle Data Pump, coordinating the concurrent requests and staging tables that move benefit enrollment and beneficiary information into the EBS database.

The package header identifies it as a "no ship" object, meaning it is an internal implementation utility rather than a supported public API. It was created in January 2006 and revised through May 2006, with specific fixes recorded for beneficiary upload logic. It is classified as OTHER in the ETRM API registry, confirming that it is not part of the formal published interface for Oracle HRMS.

The user search term "check_slaves_status" corresponds to a private procedure declared within this package body. This routine polls the concurrent manager status of subordinate "slave" requests spawned by the Data Pump process and reports whether any of them terminated in error.

Key Procedures and Functions

The ETRM metadata documents a single public procedure, PRE_DATAPUMP_PROCESS. This is the wrapper entry point described in the package header. It initiates the Data Pump operation from the workbench context, preparing the environment, launching the underlying Data Pump job and its associated child requests, and driving the enrollment and beneficiary upload sequence. Detailed parameter signatures are not published in the documentation and should not be assumed.

In addition to the documented entry point, the package body contains the private procedure check_slaves_status. This procedure accepts a parent request identifier and returns an output flag indicating whether any monitored subordinate request has ended in error. Internally it declares a cursor against FND_CONCURRENT_REQUESTS to retrieve the phase and status codes for the given request. The procedure loops while the request phase is not complete, setting the error flag when a status code of "E" is observed. A poll-loop counter is used to throttle repeated queries against the concurrent requests table, avoiding excessive polling. Diagnostic tracing is routed through HR_UTILITY.set_location so that execution can be followed when debug is enabled.

Tables Accessed

  • FND_CONCURRENT_REQUESTS — queried by check_slaves_status to read phase_code and status_code for the parent or child request, enabling the package to detect completion and error conditions.
  • HR_PUMP_BATCH_LINES — holds the staged batch lines that the Data Pump process reads or writes while loading enrollment and beneficiary data.
  • HR_API_MODULES — referenced to resolve the HR API module definitions used when the uploaded records are applied through the business logic layer.

All access is performed through APPS synonyms, consistent with standard EBS coding practice.

Usage Notes

This package is invoked from the HR workbench when a user submits an enrollment or beneficiary upload that relies on the Data Pump mechanism. It is not referenced by any other documented APPS package, which confirms its role as a top-level internal driver rather than a shared library routine. Custom code should not call PRE_DATAPUMP_PROCESS or check_slaves_status directly; the supported approach is to use the workbench or the corresponding concurrent program. The check_slaves_status logic is relevant operationally because the Data Pump job spawns multiple concurrent slave requests, and a failure in any one of them must be surfaced to the workbench user rather than silently ignored.