Search Results hr_applicant_be3




Overview
Explore in AI Chat

Overview

HR_APPLICANT_BE3 is a server-side PL/SQL package owned by the APPS schema in Oracle E-Business Suite. The "BE" naming convention identifies it as a business entity package belonging to the Oracle Human Resources (HR) product family, specifically the recruitment and applicant-tracking functional area. Its companion packages HR_APPLICANT_BK3 (the "BK" or book/implementation layer) and HR_APPLICANT_BE3 operate together as part of Oracle's generated business-entity architecture for the PER_APPLICANTS schema object. In this architecture the BE layer owns the actual transactional logic and DML, while the BK layer typically exposes the callable entry points that forms and other clients invoke.

The package status is documented as VALID in the 12.2.2 ETRM extract, confirming that it is installed and compiled successfully. Its API classification is recorded as OTHER, meaning it is not exposed as a public, supported open interface or public API, but rather serves as an internal implementation component of the applicant data model. The object was introduced to encapsulate the business rules governing the lifecycle state transitions of an applicant record.

Key Procedures and Functions

The ETRM metadata documents a single procedure within the package:

  • TERMINATE_APPLICANT_A — Handles the termination action for an applicant. Consistent with the "A" suffix convention used throughout the HR business-entity packages, this is the action routine that applies the terminate operation to an applicant record, enforcing the validation and side effects associated with ending an applicant's relationship with a recruitment activity. Parameter details are not published in the ETRM extract and should not be assumed.

Because the package is a generated business-entity layer, the remaining logic for insert, update, delete, and locking operations on the applicant entity is expected to reside in the paired HR_APPLICANT_BK3 package, with HR_APPLICANT_BE3 supplying the underlying action and validation code.

Tables Accessed

The documented table references — resolved through APPS synonyms — are:

  • PER_WF_EVENTS_S — The Workflow event subscription table. Its presence indicates that applicant termination raises or subscribes to Oracle Workflow business events, allowing downstream processes (notification, approval routing, or integration) to react when an applicant is terminated.
  • DBMS_LOB — Not a table but the Oracle-supplied large-object utility package. Its inclusion in the dependency list reflects that the package manipulates LOB columns, consistent with applicant records that carry attachments, comments, or other unstructured content.
  • DUAL — The standard single-row utility table, used for scalar queries, sequence lookups, or conditional evaluation within PL/SQL.

The primary entity being transacted upon — PER_APPLICANTS — is implied by the package name and function, though it does not appear directly in the documented reference list because access is routed through the BK layer.

Usage Notes

HR_APPLICANT_BE3 is referenced by exactly one other package according to the ETRM metadata, namely HR_APPLICANT_BE3's companion HR_APPLICANT_BK3 (the listing also shows the package referencing itself, which is a common artifact of generated code). This confirms that the package is not intended to be called directly by external clients. Instead it is invoked indirectly whenever a user or process performs a terminate action on an applicant through the Oracle HRMS recruitment forms, through the corresponding BK3 entry point, or through internal workflow business-event processing.

Typical invocation paths include the Applicant/Assignment maintenance forms in the Oracle iRecruitment and Core HR recruitment flows, and any concurrent or workflow-driven process that ends an applicant's candidacy. Customizations should never call HR_APPLICANT_BE3 directly; supported integration should target the formally published applicant APIs or the BK layer entry points. Any change to the terminate business rules must be applied through patching of the seeded package, since modification of the APPS-owned object would violate the EBS support model.