Search Results per_per_shd




Overview
Explore in AI Chat

Overview

PER_PER_SHD is a shadow (audit/history) package body owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. As the "_SHD" suffix indicates, it is the shadow counterpart to the PER_PER business package that underlies the core Oracle HRMS Person (PER) module. It is designed to work in conjunction with the corresponding shadow table PER_ALL_PEOPLE_SHD, which stores the full historical record of changes made to rows in PER_ALL_PEOPLE_F, the primary datetracked table of person records.

The business function of this package is to capture and expose audit information for the PER_ALL_PEOPLE_F table. Every INSERT, UPDATE, or DELETE performed against the person table is mirrored by a shadow row containing the before-image and after-image values, the DML operation type, the change timestamp, and the user who made the change. PER_PER_SHD is the procedural layer that application code (typically the shadow-aware DML logic invoked by the base PER_PER business package) calls to write those shadow rows and to keep the shadow data consistent with the datetracked effective-dating semantics used throughout Oracle HRMS.

Key Procedures and Functions

The ETRM documentation records eight procedures and functions within the package body. Their documented purposes are as follows:

  • RETURN_API_DML_STATUS — Returns the DML status flag indicating whether the most recent API operation performed by the package resulted in an insert, update, or delete against the shadow table.
  • CONSTRAINT_ERROR — Centralised error handler that raises or records constraint violations encountered while writing shadow rows, ensuring consistent handling of integrity failures (for example, against ALL_CONSTRAINTS).
  • API_UPDATING — Flag/utility used to signal that an API-driven update is in progress, so that shadow processing and related logic behave correctly during nested API calls.
  • FIND_DT_DEL_MODES — Determines the datetrack delete mode applicable to the shadow operation, distinguishing between the datetrack delete modes (for example, ZAP versus DATE_TO) that determine whether the shadow row is physically deleted or end-dated.
  • FIND_DT_UPD_MODES — Determines the datetrack update mode applicable to the shadow operation, distinguishing between the datetrack update modes (for example, UPDATE versus CORRECTION) that govern whether the change creates a new effective-dated version.
  • UPD_EFFECTIVE_END_DATE — Updates the effective end date on the shadow row so that the shadow record remains consistent with the datetracked effective date range of the corresponding person record.
  • LCK — Performs locking of the shadow record (or the corresponding person row) prior to modification, preventing concurrent updates from corrupting the history.
  • CONVERT_ARGS — Converts and normalises the API argument list into the form required by the shadow insert/update logic before the shadow row is written.

Tables Accessed

The documented dependent tables referenced through APPS synonyms are:

  • PER_ALL_PEOPLE_F — The primary datetracked person table. The package reads the before-image and after-image of the person row being changed, and uses the effective start/end dates to construct the corresponding shadow record.
  • HR_COMMENTS — Stores free-text comments associated with the change; the shadow logic preserves the comment text alongside the historical row so that the reason for the change is retained in the audit trail.
  • ALL_CONSTRAINTS — Used by the constraint-error handling logic to identify and interpret constraint violations raised during DML operations, mapping Oracle error numbers back to the violated constraint.

Usage Notes

PER_PER_SHD is not intended to be called directly by end users or custom extensions. It is invoked indirectly whenever PER_PER (its parent business package) or the HR_API layer performs a DML operation against PER_ALL_PEOPLE_F through the standard Oracle HRMS APIs. The package is documented as referenced by twenty other packages, confirming that it sits deep within the HRMS API call stack rather than at its surface.

In a typical flow, a form or concurrent program such as the Person form (PERWSHRG) or an employee-hire concurrent process calls HR_PERSON_API, which in turn invokes PER_PER; the shadow package is then invoked to write the audit row. Because this is shadow infrastructure rather than a public API, customisations should never call it directly. Any code that manipulates PER_ALL_PEOPLE_F outside the supported HRMS APIs risks producing an incomplete or inconsistent shadow history. The package depends on HR_API, HR_UTILITY, DT_API, HR_COMMENTS, PER_PER_BUS, and STANDARD, and remains VALID in both 12.1.1 and 12.2.2.