Search Results create_applicant_a

Overview

APPS.HR_APPLICANT_BK1 is a companion ("BK1") PL/SQL package within the Oracle E-Business Suite Human Resources (HR) Applications product family. Its name and dependency signature identify it as the backward-compatibility or "before" processing stub conventionally paired with the primary applicant API package, APPS.HR_APPLICANT_API. The suffix _BK1 indicates it exists to preserve the prior interface behavior of the applicant API, allowing existing calls written against earlier releases to continue resolving without modification after an upgrade.

In functional terms, the package participates in the creation and maintenance of applicant records in the Oracle HR applicant tracking data model, which underpins recruitment, iRecruitment, and related talent-acquisition flows. Rather than containing independent business logic, HR_APPLICANT_BK1 forwards its two public entry points to the live API routines that perform row-level validation, defaulting, and DML against the applicant tables. It is a thin compatibility layer that shields callers from changes to the underlying API contract.

The documented status is VALID in the APPS schema, and its only external dependencies are SYS.STANDARD (the PL/SQL built-in package) plus the core HR_APPLICANT_API package. No standalone tables are attributed to the package itself; all data access occurs through the primary API.

Key Procedures and Functions

• CREATE_APPLICANT_B — The "before" procedure in the standard EBS API pair. Its name denotes the pre-processing entry point that executes prior to the insert. It is invoked to establish the row context for a new applicant, and in the paired API convention it typically supplies default values, performs the initial validation of the incoming applicant attributes, and prepares the record for insertion.
• CREATE_APPLICANT_A — The "after" procedure matching CREATE_APPLICANT_B. It runs following the insert to complete the creation of the applicant record. It handles the post-insert processing steps associated with the applicant entity, allowing the caller to encapsulate the full create operation as a single API call.

The B/A naming pair mirrors the standard EBS API convention in which the _A (after) routine is called after the _B (before) routine. Because HR_APPLICANT_BK1 is referenced by HR_APPLICANT_API, HR_PERSON_BUSINESS_EVENT, and itself, its procedures are consumed internally by the HR applicant API layer and by the person business-event infrastructure that publishes business events on applicant-related changes. Parameter lists are not reproduced here; the interface is defined by the primary API.

Tables Accessed

The ETRM metadata for HR_APPLICANT_BK1 records no directly referenced tables. All database access is delegated to APPS.HR_APPLICANT_API, which in turn reads and writes the core applicant and person tables (for example, the applicant, applicant assignment, and person tables) through APPS synonyms. This delegation is consistent with the package's role as a compatibility wrapper: it neither owns nor manipulates table data directly, so no table-level dependencies appear in its own dependency list.

Usage Notes

HR_APPLICANT_BK1 is an internal implementation object and is not normally invoked directly by end users. It is called programmatically in three situations:

• From APPS.HR_APPLICANT_API, which is the supported public interface for creating and maintaining applicant records. Custom integration code should always call HR_APPLICANT_API, never the BK1 package.
• From HR_PERSON_BUSINESS_EVENT, where applicant creation interacts with the person business-event subscription and publication mechanism.
• From custom or legacy code that was written against the historical applicant API signature and continues to resolve to this compatibility entry point.

This behavior is consistent across Oracle EBS 12.1.1 and 12.2.2; the package remains VALID in the APPS schema in both releases. Developers performing impact analysis on HR_APPLICANT_API or HR_PERSON_BUSINESS_EVENT should account for this package as a dependent object, since changes to the primary API can affect compile validity here.