Search Results hr_applicant_be2




Overview
Explore in AI Chat

Overview

HR_APPLICANT_BE2 is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM repository as an "OTHER" API object. The "_BE2" suffix follows Oracle's naming convention for business logic helper packages, indicating that this package encapsulates applicant-related business rules that support the core Human Resources applicant processing framework. In the context of Oracle EBS 12.1.1 and 12.2.2, this package functions as a supporting component within the Oracle iRecruitment and Core HR applicant lifecycle infrastructure.

The package is documented as VALID in both release environments. It is paired with a companion package body and SQL statement set, and it maintains a narrow dependency footprint: it references the SYS.STANDARD package and is referenced by two other APPS packages, HR_APPLICANT_BK2 and itself. This tight coupling suggests it operates as a lower-tier utility invoked by the higher-level applicant business logic layer (the "_BK2" package typically represents the bulk-processing or batch counterpart).

Key Procedures and Functions

The documented ETRM metadata lists one procedure or function: HIRE_APPLICANT_A.

  • HIRE_APPLICANT_A — This is the single documented entry point exposed by the package. Its name follows Oracle's "_A" convention for private or internal (helper) routines within the applicant business logic family, as distinct from the public "_API" layer used by external callers. The routine is responsible for executing the hire-applicant operation itself, converting an eligible applicant record into an employee or assignment record within the HR system. Consistent with Oracle standards, the parameter list is not enumerated in the ETRM excerpt, and no parameter signatures should be assumed.

The package body may contain additional private procedures, but only HIRE_APPLICANT_A is catalogued in the documented metadata. Customizations should target this documented routine only where the ETRM record confirms its behavior.

Tables Accessed

Based on the documented table references resolved through APPS synonyms, HR_APPLICANT_BE2 touches the following:

  • PER_WF_EVENTS_S — The Workflow event subscriptions table. This indicates the hire operation raises or subscribes to Oracle Workflow business events (for example, an applicant-hired event) so that downstream processes such as onboarding, notification, and integration subscribers are notified. This is typical for HR applicant-to-employee transitions.
  • DBMS_LOB — Oracle's built-in Large Object package. Its presence implies the package manipulates CLOB or BLOB data, most plausibly applicant attachments, comments, or rich text fields associated with the application record.
  • DUAL — The standard single-row pseudo-table, used for evaluating expressions and returning scalar values such as sequence numbers or date defaults.

The metadata does not list direct HR applicant or person tables; those accesses are evidently delegated through the higher-level HR_APPLICANT_BK2 and related packages that invoke this one.

Usage Notes

HR_APPLICANT_BE2 is not intended for direct invocation by end users or external interfaces. It is an internal helper package, called indirectly by the Oracle iRecruitment application and by HR_APPLICANT_BK2, which wraps and sequences its operations. Typical invocation paths include the iRecruitment "Hire Applicant" and "Convert to Employee" flows, and concurrent or workflow-driven batch processes that transition applicants into the PER tables.

Because the ETRM record documents only HIRE_APPLICANT_A, custom development should avoid calling undocumented procedures directly. Any customization that must intervene in the hire sequence is better anchored to the documented open interfaces or to the higher-level _BK2 package. As the package raises Workflow events via PER_WF_EVENTS_S, integrations that depend on applicant-hire notifications should treat this package as an upstream source of record. No signature-level documentation is provided, so integrators must not assume parameter contracts.