Results for “pe_pei_shd”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PE_PEI_SHD is a stored PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified under the OTHER API category in the ETRM repository. Its name follows Oracle's naming convention for a shared ("_SHD") shadow or handle-layer package associated with the People Extra Information entity in Oracle Human Resources (PER). The package provides the row-handling and argument-conversion layer beneath the People Extra Information maintenance APIs, exposing the structure of a single PER_PEOPLE_EXTRA_INFO row as a global PL/SQL record type (g_rec_type) and providing the low-level routines that validate, lock, and transform that record during insert, update, and delete operations.

The g_rec_type record declares the full column footprint of the People Extra Information table, including PERSON_EXTRA_INFO_ID, PERSON_ID, INFORMATION_TYPE, the concurrent-manager WHO columns (REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE), the thirty PEI_ATTRIBUTEn DFF columns (varchar2(150) each), and the twenty PEI_INFORMATIONn descriptive-flexfield columns (varchar2(150) each), together with PEI_ATTRIBUTE_CATEGORY and PEI_INFORMATION_CATEGORY. The package is declared AUTHID CURRENT_USER, so it executes with the privileges of the calling schema rather than as definer-rights code. The header signature indicates the package body dates from Release 12 maintenance (pepeirhi.pkh 120.0), and the object remains present and documented through EBS 12.1.1 and 12.2.2.

Key Procedures and Functions

The ETRM metadata documents four units within PE_PEI_SHD. Parameter lists are intentionally not reproduced here; only documented purpose is described.

• API_UPDATING — Signals or tracks that a People Extra Information API operation is in progress. It is the standard shadow-package indicator used so that dependent logic and the base table handlers can distinguish genuine API-driven maintenance from direct table manipulation, and it supports the row-level change detection used when the API writes to PER_PEOPLE_EXTRA_INFO.
• LCK — Performs the row-level lock on the target Person Extra Information record prior to an update or delete. This prevents concurrent sessions from modifying the same PEI row while an API transaction is open, providing the serialization guarantee expected of an API-based DML path.
• CONVERT_ARGS — Maps and converts the incoming API arguments into the internal g_rec_type record layout, including DATE handling for PROGRAM_UPDATE_DATE and translation between the caller's datatypes and the table columns. It centralizes the argument-to-record translation so the same conversion logic serves all callers of the PEI APIs.
• CONSTRAINT_ERROR — Raises or propagates the standardized constraint-violation error used when a PEI row fails table constraints or API-level validation. Centralizing this allows callers to receive consistent, catchable error semantics rather than raw Oracle constraint exceptions.

Tables Accessed

Two base tables are documented as referenced through APPS synonyms.

• PER_PEOPLE_EXTRA_INFO — The primary table. It stores descriptive-flexfield and attribute information attached to a person record in Oracle HRMS. PE_PEI_SHD reads its column definitions to define g_rec_type and writes or locks rows through its handlers, using PERSON_ID as the link to PER_ALL_PEOPLE_F and PERSON_EXTRA_INFO_ID as the surrogate key.
• ALL_CONSTRAINTS — The data dictionary view consulted for constraint metadata. The package uses it to resolve the constraint names enforced on the PEI table so that violations can be recognized and reported through CONSTRAINT_ERROR rather than surfaced as opaque ORA- errors.

Usage Notes

PE_PEI_SHD is not an end-user-invocable API; it is an internal layer. The documented metadata records that it is referenced by eight other packages, which is characteristic of a shared handler invoked by the public People Extra Information API and by concurrent programs that load or maintain PEI data. Typical invocation paths include:

• Oracle HRMS forms and self-service pages that maintain person extra information, which call the public PER APIs, which in turn delegate row locking, argument conversion, and constraint handling to PE_PEI_SHD.
• Concurrent programs and interface/loader routines that mass-insert or update PER_PEOPLE_EXTRA_INFO, relying on the package's DFF column mapping.
• Custom PL/SQL that needs to manipulate PEI rows without bypassing validation, invoking the API stack rather than issuing direct DML.

Because the package is AUTHID CURRENT_USER, calling schemas must themselves hold the necessary privileges on PER_PEOPLE_EXTRA_INFO and ALL_CONSTRAINTS, or execute through the standard APPS-based grants. Direct calls to CONSTRAINT_ERROR, LCK, CONVERT_ARGS, or API_UPDATING should be avoided in custom code; developers should use the documented public PER API for People Extra Information so that these handlers run in their intended sequence. The search term "shi shi cking permit" does not correspond to any documented object in this package and appears to be an unrelated text fragment.