Search Results irc_party_bk3




Overview
Explore in AI Chat

Overview

IRC_PARTY_BK3 is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It belongs to the Oracle iRecruitment (IRC) product family and forms part of the generated API hook infrastructure that surrounds the iRecruitment party and application-registration business logic. The package is classified as an "OTHER" API type within the ETRM repository and was generated by the Oracle HRMS API Hook Pre-processor, as confirmed by the header comment referencing irhzpapi.pkb and the creation timestamp of 2012/11/27. Its principal role is to act as a thin "before" (BK) wrapper — the BK3 suffix identifies it as the third before-processing hook layer — that delegates to the corresponding business-entity layer (irc_party_be3) while coordinating commit-unit and validation-set handling through the HR API infrastructure. The package therefore does not itself contain recruitment business rules; instead it ensures that when a registered user submits a job application, the appropriate application hooks fire within a properly managed transactional context.

Key Procedures and Functions

The package exposes two documented procedures:

  • REGISTERED_USER_APPLICATION_A — The primary hook procedure for the registered-user job application flow. It accepts a parameter set covering the effective date, person identifier, applicant number, application received date, vacancy and posting content identifiers, assignment identifier, and the assignment object version number used for optimistic locking. The procedure records its entry point via hr_utility.set_location, captures the current commit unit through hr_api.return_commit_unit, and then conditionally calls irc_party_be3.REGISTERED_USER_APPLICATION_A when hr_api.call_app_hooks returns true. On completion it closes the validation set with hr_multi_message.end_validation_set and validates the commit unit against the entity label 'REGISTERED_USER_APPLICATION' with the 'AP' (application) context code before logging its exit.
  • REGISTERED_USER_APPLICATION_B — A companion procedure in the same registration flow that carries a reduced parameter set limited to the effective date, person identifier, applicant number, application received date, vacancy identifier, and posting content identifier. It provides location tracing on entry and exit only; no downstream business-entity call or commit-unit handling is visible in the supplied body, indicating it serves as a lighter-weight hook point invoked earlier or under narrower conditions than the "_A" variant.

Tables Accessed

The ETRM metadata does not list any direct table references through APPS synonyms for this package body. This is consistent with its design: IRC_PARTY_BK3 functions as a procedural hook layer rather than a data-access layer. All persistent reads and writes for applicant registration and application creation are performed downstream by irc_party_be3 and the underlying iRecruitment base tables, such as the application and assignment entities implied by the PERSON_ID, VACANCY_ID, and ASSIGNMENT_ID parameters. The package's interaction with data is indirect, mediated through the HR API framework calls (hr_api and hr_multi_message), which manage validation messaging and transaction boundaries for the entities being manipulated.

Usage Notes

This package is not intended for direct invocation by customers. It is called by the Oracle HRMS API hook framework when the registered-user application business process executes, most commonly during candidate self-service job application submission in iRecruitment and related Oracle self-service forms. Because the procedures are generated from the API hook pre-processor, they may be regenerated during patching; any customization should therefore be placed in the associated business-entity or custom-hook layers rather than in this body. The ETRM metadata records that the package is referenced by one other package, reflecting its position as a dependency within the iRecruitment API call chain rather than as an entry point. Developers diagnosing application-registration issues should treat IRC_PARTY_BK3 as a tracing and hook-delegation artifact whose set_location output ('Entering'/'Leaving' markers at locations 10 and 20) is useful for confirming that the hook fired before investigating the business logic in irc_party_be3 and the underlying HR API validation routines.