Search Results irc_party_bk2




Overview
Explore in AI Chat

Overview

IRC_PARTY_BK2 is a database package owned by the APPS schema within Oracle E-Business Suite Release 12.1.1 and 12.2.2. The "BK" suffix in the Oracle EBS naming convention denotes a "backward compatibility" or "bookmark" wrapper — a lightweight package layered over an existing API to preserve a legacy call signature while the underlying implementation moves to a newer API. Consistent with that convention, IRC_PARTY_BK2 does not carry primary business logic of its own. Instead, its role in the iRecruitment (IRC) product family is to expose the registered-user maintenance capability of the party/recruitment subsystem through a stable, versioned entry point that other components can continue to call.

The package sits within the IRC module's party-handling layer, whose members include IRC_PARTY_API and the related wrapper packages. Its documented status is VALID, and its API classification is OTHER, indicating that it is a supporting utility rather than a public, actively promoted API. Its narrow scope — two documented entry points — reflects the design intent of the "_BK2" family: minimal surface area, delegation to the current API, and protection of callers against future refactors.

Key Procedures and Functions

Two procedures are documented for this package:

  • UPDATE_REGISTERED_USER_B — The "B" (before) procedure. It forms the pre-processing half of the standard Oracle EBS API pattern. Its purpose is to prepare or validate the context for a registered-user update, performing any setup work required before the transactional change is attempted, so that the main update logic executes against a consistent state.
  • UPDATE_REGISTERED_USER_A — The "A" (after) procedure. It forms the post-processing half of the same pattern, invoked after the registered-user change has been applied. Its purpose is to complete the operation — for example, propagating derived data or finalising state — once the core update has succeeded.

The "_B"/"_A" pairing is the canonical Oracle EBS convention for a single logical operation split into before and after phases, allowing callers, forms triggers, or the delegation chain to inject pre- and post-processing around the update. The actual update logic is expected to reside in the underlying IRC_PARTY_API, which references IRC_PARTY_BK2. Parameter lists are not documented for these procedures and are therefore not reproduced here.

Tables Accessed

The ETRM metadata does not enumerate specific tables referenced by IRC_PARTY_BK2 through APPS synonyms. Given that the package is a wrapper delegating to IRC_PARTY_API and centred on the operation named UPDATE_REGISTERED_USER, its effective data footprint is the set of tables touched by the underlying party API when a registered-user record is maintained. These are typically the iRecruitment and party-related tables resident in the APPS schema and exposed through APPS public synonyms. Notably, the dependency section lists only SYS.STANDARD as a referenced object, which corroborates the view that the package body is thin and performs no direct SQL of its own.

Usage Notes

IRC_PARTY_BK2 is referenced by the APPS.IRC_PARTY_API package and by itself, and ETRM records it as being referenced by one other package. It is consequently an internal delegation target rather than a standalone API: callers should invoke the underlying IRC_PARTY_API, which in turn reaches the corresponding _BK2 procedure. Typical invocation paths include iRecruitment pages and forms triggers that record or amend a registered user, and any product or custom code that flows through IRC_PARTY_API. Custom code should not call IRC_PARTY_BK2 directly, because the wrapper carries no documented standalone interface and may be deprecated as the delegation chain evolves.