Search Results activate_apl_asg

Overview

APPS.HR_ASSIGNMENT_BKC is the Business API Hook package body generated by the Oracle HRMS API Hook Pre-processor for the Assignment business object. The "_BKC" suffix identifies this as the "Before" hook container (the "Before Kind Check" variant), which is invoked by the business API framework prior to the core validation and DML logic executed by the corresponding _BE or API layer. Its primary business function is to provide Oracle E-Business Suite customers with a supported extension point for the Assignment activation flow — most notably the activation of an Applicant assignment (the "APL_ASG" activity) — without modifying Oracle seeded code.

The package header comment, generated on 2009/03/30 and delivered with the $Header: peasgapi.pkb 120.20.12010000.4 2008/09/29 tag, confirms that this object was produced automatically by the API Hook Pre-processor rather than written by hand. The activating flow it supports transitions an assignment status, optionally records a change reason, and respects datetrack update modes — all standard elements of the HRMS DateTrack architecture used throughout Oracle HRMS 12.1.1 and 12.2.2.

Key Procedures and Functions

• ACTIVATE_APL_ASG_A — The primary hook procedure for the assignment activation event. It receives the effective date, datetrack update mode, assignment identifier, object version number, assignment status type, change reason, and effective start/end dates. Inside the body it captures the current commit unit via hr_api.return_commit_unit, then conditionally delegates to the customer-defined business logic in HR_ASSIGNMENT_BEC.ACTIVATE_APL_ASG_A when hr_api.call_app_hooks evaluates to true. It closes the validation set through hr_multi_message.end_validation_set and re-validates the commit unit using hr_api.validate_commit_unit before returning.
• ACTIVATE_APL_ASG_B — A stub procedure that mirrors the activation hook signature (minus the effective start/end dates). Its body contains only entry and exit hr_utility.set_location tracing calls, providing a no-op placeholder that customers may extend. The presence of both A and B variants reflects the generator's convention of emitting parallel hook entry points across the assignment API lifecycle.

Tables Accessed

The ETRM metadata for this object records no directly referenced tables via APPS synonyms. This is consistent with the hook pattern: HR_ASSIGNMENT_BKC does not itself query or manipulate base tables such as PER_ASSIGNMENTS_F or PER_ALL_ASSIGNMENTS_F. All persistence operations are delegated to the underlying business API layer and to the customer's _BEC implementation. Any table access performed by an activated assignment therefore flows through the parent API, not through this hook package.

Usage Notes

This package is normally invoked indirectly. When a user activates an assignment — for example through the Assignment form or a self-service transaction — the HRMS business API framework calls the "before" hook chain, which routes into HR_ASSIGNMENT_BKC.ACTIVATE_APL_ASG_A. The procedure is also invoked from PL/SQL by custom code that calls the assignment activation API and expects the business-event hook to fire. Because the package body is generated code, it should not be edited directly; the supported extension path is to implement logic in the corresponding _BEC ("Business Event Code") package, which this body calls when hr_api.call_app_hooks returns true.

The ETRM metadata further records that the package is referenced by one other package, and that its procedures are limited to the two activation hooks described above. The recommended workflow mirrors standard HRMS hook practice: copy the _BEC sample, implement the required validation or audit logic, and rely on the _BKC generator output to bridge the API call to that custom code. Tracing entries written by hr_utility.set_location assist developers in confirming that the hook executed.