Search Results hr_applicant_dataupd




Overview

HR_APPLICANT_DATAUPD is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified as an OTHER API in the ETRM repository. Its header identifies it as hraplupd.pkh and declares it with AUTHID CURRENT_USER, meaning it executes with the privileges of the calling schema rather than the definer. The package supports the Oracle iRecruitment and Oracle Human Resources applicant data model, providing the logic required to create, convert, and maintain applicant records and their associated application rows. Its central concern is the relationship between a person, a person type usage, an assignment, and an application row in PER_APPLICATIONS. The package also carries upgrade-support code, evidenced by its reference to the PAY_UPGRADE_DEFINITIONS and PAY_UPGRADE_STATUS tables and by procedures such as VALIDATERUN, RUNUPDATEMODE, ISADPATCHMODE, and ISDEFERMODE. These procedures indicate the package can be executed in a controlled "upgrade" or "patch" mode, allowing batch updates to applicant data to be deferred, resumed, or validated before execution. In Oracle EBS 12.1.1 and 12.2.2, this places HR_APPLICANT_DATAUPD among the internal maintenance packages that support data conversion and remediation across the recruitment and HR person model.

Key Procedures and Functions

The package documents eight procedures.

  • ConvertToApplicant — Converts a person into an applicant. According to the header comments, it acts when it finds active applicant assignments that have been opened and the application carries a termination date. It operates over a ROWID range, processing from a start rowid to an end rowid and returning a count of rows processed, which makes it suitable for set-based or batched processing.
  • Update_APL_using_LTU — Updates application data using LTU logic, driven by an error buffer, a return code, a worker identity, a total worker count, and parameters identifying the owner, table, update name, and batch size. This is the worker-level routine used for parallel batch execution over a named driver table.
  • Update_APL_inCM_Manager — The manager (coordinator) routine for the concurrent "Update APL in CM" process. It accepts an error buffer, return code, batch size, number of workers, a process-all flag, a caller identifier, and an optional application ID that defaults to zero when the parameter is not supplied in the concurrent program definition.
  • Update_APL_inCM_Worker — The corresponding worker routine, invoked repeatedly with a worker ID, a batch size, and the total worker count to process one partition of the application update workload.
  • ValidateRun — Validates the run configuration, ensuring that the requested execution mode and parameters are consistent before processing begins.
  • RunUpdateMode — Executes the update mode, controlling whether updates are applied or merely evaluated.
  • IsADPatchMode — Reports whether the current execution is running under an AD patch (Online Patching) context.
  • IsDeferMode — Reports whether deferred processing is in effect.

Tables Accessed

Through APPS synonyms the package reads and writes PER_ALL_ASSIGNMENTS_F and PER_ALL_PEOPLE_F, which hold the assignment and person records that determine applicant eligibility and assignment status. PER_APPLICATIONS holds the applicant application rows that are created or updated. PER_PERSON_TYPES and PER_PERSON_TYPE_USAGES_F define and track the person type (for example, applicant versus employee) applied to a person, which is fundamental to the conversion logic. PAY_UPGRADE_DEFINITIONS and PAY_UPGRADE_STATUS are the upgrade control tables that record batch definitions, progress, and completion status for the upgrade-oriented procedures.

Usage Notes

The package is not exposed as an end-user form API. It is invoked through concurrent programs — notably the "Update APL in CM" concurrent program, whose manager and worker entry points are declared here — which use the manager-worker pattern to parallelize processing across a configurable number of workers and batch sizes. Direct invocation should be restricted to Oracle-seeded concurrent programs or to controlled upgrade scripts, since the procedures assume a populated upgrade definition and a valid run mode. Referenced-by count in the ETRM metadata is zero, indicating no other API package depends on it; it is a leaf-level maintenance routine. The order of processing matters: ValidateRun and the IsADPatchMode/IsDeferMode checks should be evaluated before RunUpdateMode or the worker procedures are called, so that online-patching and deferral conditions are honored. The AUTHID CURRENT_USER declaration means callers must be granted execute on the package under APPS.