Search Results delete_job

Overview

HR_JOB_API_BK3 is a generated Oracle HRMS API hook package body owned by APPS. It is one of the companion "BK" (Before/After hook) packages produced automatically by the Oracle HRMS API Hook Pre-processor, which decomposes the public HRMS business APIs into a chain of numbered hook entry points. The header comment confirms this origin (pejobapi.pkb 120.0, generated and shipped in 2008, hook code created 2009/03/30), placing it in the 12.1.1 and 12.2.2 release lineage.

The package serves the Job business object. Jobs are the position-independent work categories defined in Oracle HRMS and used by requisitions, assignments, postings, and grading structures. When a caller invokes the public HR_JOB_API.DELETE_JOB API, the pre-processor framework sequences the request through numbered hook packages such as this one. HR_JOB_API_BK3 supplies the "3" layer of the delete chain, wiring application-level validation hooks and customer-level (BP/AP) extension hooks around the core delete logic. No table is directly manipulated here; the package's role is orchestration, not data access.

Key Procedures and Functions

• DELETE_JOB_A — The application-level ("A") delete hook. It sets a diagnostic location marker, captures the current commit unit via hr_api.return_commit_unit, and, when hr_api.call_app_hooks returns true, delegates to hr_job_api_be3.DELETE_JOB_A. It then closes the multi-message validation set and calls hr_api.validate_commit_unit with the operation name DELETE_JOB and point AP.
• DELETE_JOB_B — The customer ("B") delete hook. It records the commit unit and, when hr_api.call_cus_hooks is true, invokes PA_JOB_UTILS.CHECK_JOB_RELATIONSHIPS for the job being removed. Commit-unit validation is again performed with operation DELETE_JOB at point BP.

The A/B split reflects the Oracle HRMS extension model: "A" hooks carry Oracle-supplied application logic, while "B" hooks expose customer extension points. Neither procedure is intended for direct invocation by end users; the public entry point remains HR_JOB_API.DELETE_JOB.

Tables Accessed

The ETRM metadata does not document any tables accessed through APPS synonyms by this package. That is consistent with its generated-hook design: validation and persistence occur in the peer "BE" (business entity) packages and in the underlying HR_JOB_API base package, which ultimately operate on the HR_ALL_POSITIONS_F / PER_JOBS structures. The notable dependency here is a package rather than a table: PA_JOB_UTILS.CHECK_JOB_RELATIONSHIPS, a Projects (PA) utility that verifies a job is not referenced by project or requisition relationships before deletion proceeds.

Usage Notes

This package is invoked indirectly. Typical entry paths include the Job definition form, which routes deletions through HR_JOB_API.DELETE_JOB; concurrent or batch job maintenance routines; and custom PL/SQL that calls the public HR_JOB_API rather than this hook layer. The hook chain is executed only when the corresponding feature flags (call_app_hooks, call_cus_hooks) are enabled, so behavior can differ between environments based on API hook configuration.

Because the code is pre-processor generated, it should not be edited directly; regeneration overwrites changes. Customizations belong in the customer hook points (the "B" procedures and their registered PL/SQL) — in this case, extending the delete validation logic that PA_JOB_UTILS.CHECK_JOB_RELATIONSHIPS already performs. The package is referenced by one other package, confirming its position inside the wider job API hook chain rather than as a standalone utility. Its most relevant value to a user searching "delete_job" is that it demonstrates where Oracle and customer delete-hook logic converge for the Job entity, and why errors raised during job deletion are often surfaced through this validation chain.