Search Results row_data

Overview

APPS.HR_SUMMARY_API is a public Oracle E-Business Suite PL/SQL API that manages the HR_SUMMARY entity, a generic key-summary repository used by Oracle HRMS security, configuration, and process-tracking components. Rather than modeling each entity in a dedicated table, HR_SUMMARY stores heterogeneous records — item types, key types, key values, restriction types and values, restriction usage, valid key types, valid restrictions, templates, and process runs — discriminated by a TYPE column and addressed through a combination of business group, text values, and foreign key values. HR_SUMMARY_API encapsulates the transactional logic for creating and locating those rows, so callers never need to reproduce the business-group scoping or the multi-branch identification logic themselves.

The package body carries the standard header marker $Header: hrsumapi.pkb 115.5 2002/11/26 10:30:14 sfmorris noship $, indicating a long-stable interface shipped under the APPS schema. It is classified as an API in the ETRM repository, owned by APPS, and is referenced by four other packages, which confirms its role as a shared foundation layer rather than an end-user entry point.

Key Procedures and Functions

The package exposes twenty-four documented program units, organized around three responsibilities: optimistic locking, identification, and creation.

• LCK — Performs row-level locking of a summary record using an ID value and object version number, delegating to the shared business-group locking routine PER_BIL_SHD.LCK. It enforces the optimistic-locking contract expected of an EBS API.
• ROW_DATA — The core lookup routine. It evaluates the supplied business group, TYPE, text values, and foreign key values against HR_SUMMARY using a cursor that branches by TYPE, returning the ID value and object version number when the summary record already exists. This is the procedure most commonly associated with the search term "row_data".
• Identification functions — GET_ID, GET_ITU_ID, GET_VKT_ID, GET_RU_ID, and GET_RV_ID retrieve surrogate identifiers for the general case and for specific summary categories (item type usage, valid key type, restriction usage, and restriction value respectively).
• Creation procedures — CREATE_ITEM_TYPE, CREATE_KEY_TYPE, CREATE_KEY_VALUE, CREATE_ITEM_VALUE, CREATE_VALID_RESTRICTION, CREATE_RESTRICTION_TYPE, CREATE_RESTRICTION_USAGE, CREATE_RESTRICTION_VALUE, CREATE_ITEM_TYPE_USAGE, CREATE_VALID_KEY_TYPE, CREATE_KEY_TYPE_USAGE, CREATE_TEMPLATE, and CREATE_PROCESS_RUN each insert a row of the corresponding summary category, deriving or validating identity through the lookup logic above.

Tables Accessed

All data manipulation is directed at a single table, HR_SUMMARY, accessed through its APPS synonym. The table is both the read source for ROW_DATA and the identification functions and the write target for the CREATE_* procedures. Because every category of HRMS summary data shares this table, the TYPE discriminator plus BUSINESS_GROUP_ID, TEXT_VALUE1, TEXT_VALUE2, FK_VALUE1, and FK_VALUE2 constitute the effective unique key. The locking procedure instead routes to PER_BIL_SHD.LCK, which applies the shared business-group locking semantics used across the HRMS product family.

Usage Notes

HR_SUMMARY_API is an internal infrastructure API. It is typically invoked by other HRMS packages — the four documented dependent packages — rather than directly from a form or concurrent program, and customer code that calls it should do so only when maintaining summary configuration data that the standard product does not expose. Callers must supply a valid business group and, for creation, should first invoke the appropriate identification function or ROW_DATA to avoid duplicate rows within the same business group. The LCK procedure should be called before update-style operations to honor the object version number contract.

Because the package body was last versioned at release 115.5 in 2002 and remains present in both 12.1.1 and 12.2.2, the interface is stable and fully backward compatible. No NOSHIP-only internal helpers are documented, and the entire surface is safe for supported extension use provided the caller respects business-group partitioning and the TYPE-specific value conventions enforced by ROW_DATA.