Search Results get_requestor_person_id

Overview

PQH_AME_UTILS is a PL/SQL utility package owned by the APPS schema in Oracle E-Business Suite, classified under the ETRM taxonomy as OTHER rather than as a public API. Its source header (pqameutl.pkh 120.0) places the specification at approximately 2005, making it a long-standing component of the HR self-service approval infrastructure. The package name derives from two elements: "PQH", the product short code for Oracle HRMS self-service and public sector HR functionality, and "AME", the Approvals Management Engine used to derive routing and approval rules across EBS applications.

Functionally, the package serves as a thin interrogation layer over the HR_API_TRANSACTIONS table. AME rule evaluation requires context about the transaction being approved — what kind of transaction it is, which record it affects, which process generated it, who raised it, and who holds final approval authority. When AME invokes a rule function or a condition for a given transaction, it supplies only a transaction identifier. PQH_AME_UTILS translates that identifier into the discrete attributes AME needs. The package therefore acts as the bridge between the generic AME transaction context and HR-specific transactional metadata.

The package specification declares no public procedures and exposes no DML entry points. Its contract is entirely read-oriented: five functions return transaction attributes as scalar values. This read-only character explains its classification and its narrow footprint within the EBS object model — it is infrastructure plumbing rather than an integration surface.

Key Procedures and Functions

The specification documents five functions, each accepting a transaction identifier and returning a single attribute value as a VARCHAR2.

• GET_ITEM_TYPE — Returns the AME item type associated with the transaction. Item type identifies the category of object under approval, allowing AME to select the correct rule set and approval group configuration.
• GET_ITEM_KEY — Returns the AME item key, the unique identifier of the specific item instance within that item type. Together with item type, this key forms the AME transaction context used to locate the approval definition.
• GET_PROCESS_NAME — Returns the name of the process that created the transaction. This allows approval logic to distinguish between transactions originating from different flows, such as a promotion versus a termination.
• GET_FINAL_APPROVER — Returns the final approver associated with the transaction, supporting rule conditions and notifications that depend on who ultimately authorizes the action.
• GET_REQUESTOR_PERSON_ID — Returns the person identifier of the requestor, that is, the individual who submitted the transaction. This is the function most commonly referenced in custom AME rule code, since many approval rules are conditioned on the requestor's relationship to the subject of the transaction.

All five are declared as functions rather than procedures, so they can be embedded directly in SQL statements and AME rule expressions. The ETRM metadata does not document individual parameter lists beyond the transaction identifier; consumers should treat the signature as stable but avoid assuming return-type behavior for null or orphaned transaction identifiers.

Tables Accessed

The package is documented as accessing two tables through APPS synonyms.

• HR_API_TRANSACTIONS — The primary source table. It stores the transaction-level record containing item type, item key, process name, requestor, and related routing attributes. All five functions derive their return values from columns in this table. The package specification also declares package-level global variables (g_item_type, g_item_key, g_process_name, g_person_id, g_creator_person_id, g_transaction_id, g_function_id) anchored to HR_API_TRANSACTIONS column types, indicating that values are cached at package level during a lookup.
• PER_ALL_ASSIGNMENTS_F — The assignment table for persons. Access to this table supports resolution of person-related attributes, most plausibly the requestor person identifier and final approver, where the relationship must be resolved through the requestor's current assignment rather than from the transaction row alone.

No insert, update, or delete operations are documented. The package should be considered strictly a reader of transactional and assignment data.

Usage Notes

PQH_AME_UTILS is invoked in the context of AME approval processing for HR transactions. The typical call path is from AME rule functions and conditions configured through the Approvals Management Engine setup, where a rule references a package function that internally calls one of these utilities to obtain the attribute value that drives the rule outcome. It may also be called from Oracle Forms-based approval screens and from custom PL/SQL code that needs to reconstruct the AME context for a given transaction, such as reporting on pending approvals or building notification logic.

ETRM records zero packages referencing PQH_AME_UTILS, which is consistent with its role: it is called directly by configuration and custom code rather than being wrapped by other seeded packages. Because it is not a documented public API, extensions that depend on it should be treated as internal integrations. Customers upgrading from 12.1.1 to 12.2.2 should verify behavior in a test environment, although the specification header indicates the interface has remained stable. Direct SQL against HR_API_TRANSACTIONS should not be used as a substitute, since the package encapsulates any logic applied to the transaction identifier before the attribute is returned.