Search Results per_ose_shd




Overview
Explore in AI Chat

Overview

APPS.PER_OSE_SHD is a shadow (suffix _SHD) package body belonging to the Oracle Human Resources (PER) product family. It supports the Organization Structure Elements facility, which defines and maintains the hierarchical relationships between organizations in Oracle EBS, such as business groups, legal entities, operating units, and inventory organizations. In Oracle EBS 12.1.1 and 12.2.2 the versioned _SHD packages are generated as part of the table-driven API (TAPI) infrastructure: the public API package (PER_ORG_STRUCTURE_ELEMENTS_API and its related utilities) delegates its business logic into the shadow body so that the API can operate on a mirror or audit copy of the base table. The object is documented with a status of VALID in the APPS schema and is classified in ETRM as API classification OTHER, reflecting its role as internal plumbing rather than a directly callable public interface. Its core purpose is to encapsulate the DML, concurrency control, argument conversion, and error handling logic required to insert, update, and validate organization structure element records while preserving the integrity of the organization hierarchy.

Key Procedures and Functions

ETRM documents five procedures/functions on this package body:

  • RETURN_API_DML_STATUS — Returns the current DML status of the API. It allows the calling layer to determine whether a prior API invocation performed an insert, update, or delete, which is essential for commit and rollback decisions in multi-step transactions.
  • CONSTRAINT_ERROR — Centralized handler for constraint violations raised during DML against the organization structure elements table. It translates Oracle integrity-constraint exceptions into a controlled, user-friendly application error.
  • API_UPDATING — Indicates whether the API is currently in an update cycle. Used internally to gate validation and side effects so that logic applies only during genuine update operations rather than during query or setup activity.
  • LCK — Locking routine that enforces concurrency control on the organization structure element record before modification, preventing lost updates when multiple sessions touch the same hierarchy row.
  • CONVERT_ARGS — Argument conversion utility that normalizes incoming API parameter values into the internal datatypes and formats expected by the business logic, ensuring consistent behavior across callers.

Tables Accessed

The package references two tables through APPS synonyms:

  • PER_ORG_STRUCTURE_ELEMENTS — The primary transactional table. The package reads, inserts, updates, and validates rows here, maintaining the parent/child and version relationships that define an organization hierarchy.
  • ALL_CONSTRAINTS — Read for metadata about declared constraints, enabling the CONSTRAINT_ERROR logic to map an Oracle error number to the correct constraint and produce an accurate message.

The dependency list also shows references to FND_MESSAGE (message retrieval and formatting), HR_API (the HR API framework), HR_UTILITY (shared HR utilities), and the SYS STANDARD package. ETRM records that APPS.PER_OSE_SHD is not referenced by any database object, confirming it is invoked only through the API stack that it shadows.

Usage Notes

PER_OSE_SHD is not intended for direct invocation and does not appear in any client-facing interface. It is invoked indirectly whenever forms, concurrent programs, or custom code call the public Oracle HR organization-structure APIs. In Oracle EBS 12.1.1 and 12.2.2 this typically occurs from the Organization Hierarchy or Organization Structures forms, from HR concurrent processes that rebuild or validate hierarchies, and from customization code that inserts or maintains PER_ORG_STRUCTURE_ELEMENTS rows. Because ETRM records the object as referenced by six other packages, changes to it can ripple through the dependent API and validation routines. Developers performing upgrades, patches, or diagnostics on organization structure data should treat it as internal infrastructure: modifications belong in the public API or form layer, and the shadow body should be left to the standard EBS patching process. Any customization touching organization hierarchies should validate through the API so that the locking, argument conversion, and constraint handling implemented here remain in effect.