Search Results final_process_cwk_asg

Overview

APPS.HR_ASSIGNMENT_BKH is a generated PL/SQL package body that belongs to the Oracle HRMS API hook pre-processor framework, as indicated by the header comment "Code generated by the Oracle HRMS API Hook Pre-processor" and the source revision peasgapi.pkb 120.37.12020000.11. The "_BKH" suffix designates the package as a Business Knowledge Hook (BKH) container rather than as the base business API itself. Its role is to provide a controlled extension point through which custom business rules — typically localization, legislative, or customer-specific logic — can be injected into the standard processing path of the assignment final-process API without modifying Oracle's shipped code.

In the 12.1.1 and 12.2.2 releases, the HRMS API architecture separates the base API (the "BE" or business entity layer), the pre-processor ("BPH" / "BKH") and post-processor ("BAH" / "BKH") hook packages, and the so-called "A" and "B" wrapper procedures that bracket hook execution. The documentation classifies this package as API classification OTHER, confirming it is not a public, supported entry point but an internal hook carrier.

Key Procedures and Functions

Two procedures are documented for this package body, both related to the business event final_process_cwk_asg (Final Process of a Candidate Work Assignment):

• FINAL_PROCESS_CWK_ASG_A — The primary "pre-process" hook thunk. It sets an HR_UTILITY trace location on entry, then calls the corresponding procedure on the HR_ASSIGNMENT_BEH hook implementation, forwarding the assignment identifier, object version number, final process date, effective dates, and the warning flags (organization-without-manager warning, assignment future-changes warning, and entries-changed warning). After the hook returns, it terminates the multi-message validation set via HR_MULTI_MESSAGE.END_VALIDATION_SET and validates the commit unit through HR_API.VALIDATE_COMMIT_UNIT, using the module tag 'FINAL_PROCESS_CWK_ASG' and the action code 'AP'. This structure ensures hook errors are collected and reported through the standard HRMS message stack inside the caller's transaction.
• FINAL_PROCESS_CWK_ASG_B — The corresponding "post-process" hook thunk. As documented, it contains only trace entry and exit calls and performs no business logic; its purpose is to give the pre-processor hook framework a stable call site after the base processing has occurred, so that a customer extension can override or extend it if required.

No private functions are documented; both procedures are declared in the package specification and are invoked exclusively by the generated API shell.

Tables Accessed

The provided ETRM metadata lists no direct table references via APPS synonyms for this package body. This is consistent with its design: HR_ASSIGNMENT_BKH is a thin dispatcher. It does not issue SQL against HR tables itself. Any DML is performed either by the underlying HR_ASSIGNMENT_BEH hook implementation or by the base HR_ASSIGNMENT_API it wraps, typically against PER_ALL_ASSIGNMENTS_F and related assignment/date-tracked entities. The package therefore carries no direct read/write privilege on business tables and derives all data access from the BE layer.

Usage Notes

This package is not intended to be called directly from forms, concurrent programs, or custom code. It is invoked automatically as part of the standard HRMS API chain whenever the Final Process action is executed against a candidate work assignment — for example, from the Assignment form or from batch personnel processes that trigger final processing. The chain runs: application code → base API wrapper → HR_ASSIGNMENT_BKH.FINAL_PROCESS_CWK_ASG_A → HR_ASSIGNMENT_BEH hook → base logic → HR_ASSIGNMENT_BKH.FINAL_PROCESS_CWK_ASG_B.

Developers extend behavior by implementing the corresponding procedure in the customer hook package (the BEH layer), not by editing this generated BKH body, which is overwritten during patching and upgrades. The HR_API.CALL_APP_HOOKS check guards whether the application-specific hook is to be executed at runtime, allowing hooks to be enabled or disabled by configuration. The package is referenced by one other package, consistent with its role as an inner link in the API call graph rather than a top-level interface.