Search Results hr_message




Overview

APPS.HR_MESSAGE is a utility package body in Oracle E-Business Suite (R12.1.1 and R12.2.2) that provides the message-handling infrastructure for the Oracle HRMS (Human Resources Management System) product family. Its principal business function is the centralized retrieval and formatting of application messages — errors, warnings, and informational text — that HRMS forms, concurrent programs, and PL/SQL APIs present to end users.

The package depends on FND_MESSAGE, the Oracle Application Object Library (AOL) foundation package responsible for fetching message text from the FND_MESSAGES repository, and on the SYS.STANDARD package. This dependency pattern confirms that HR_MESSAGE acts as an HRMS-specific wrapper and convenience layer over the generic FND_MESSAGE API, allowing HR code to raise, tokenize, and inspect messages consistently without repeatedly coding low-level AOL message calls.

According to ETRM metadata for 12.2.2, HR_MESSAGE is classified as API classification OTHER and is referenced by 42 other packages, indicating that it is a widely reused internal service component rather than a public, customer-facing API. No database objects reference HR_MESSAGE, which is consistent with a leaf-level utility that is called by application code but does not itself drive schema-level dependencies.

Key Procedures and Functions

The documented package exposes seven procedures and functions:

  • PROVIDE_ERROR — Registers or raises an error message through the HRMS message framework. It is the primary entry point used by HRMS code to surface validation failures and business-rule exceptions to the user or calling program.
  • PARSE_ENCODED — Decodes an encoded message string into its component parts. Encoded messages typically embed the application short name, message name, and token values in a single concatenated value, allowing deferred resolution of the message text.
  • LAST_MESSAGE_NUMBER — Returns the numeric identifier of the most recently processed message, supporting message-sequence diagnostics and retrieval of the last message raised.
  • LAST_MESSAGE_NAME — Returns the message name (the FND_MESSAGES lookup key) of the most recently processed message.
  • LAST_MESSAGE_APP — Returns the application short name associated with the last message, which identifies the owning product (typically PER or an HRMS-family application).
  • GET_TOKEN_VALUE — Retrieves the value assigned to a named substitution token within a message. HRMS messages commonly use tokens such as &TOKEN or :TOKEN placeholders that are replaced at runtime.
  • GET_MESSAGE_TEXT — Returns the fully resolved, user-displayable text of a message after token substitution has been applied.

Tables Accessed

The ETRM documentation does not list any directly referenced base tables via APPS synonyms for HR_MESSAGE. Message text and message definitions are obtained indirectly through the FND_MESSAGE dependency, which reads the AOL message repository (FND_MESSAGES and related multilanguage tables) owned by the Application Object Library. Therefore, HR_MESSAGE itself performs no direct DML against HRMS tables — it reads message metadata through FND_MESSAGE and exposes it to callers in HRMS terms.

Usage Notes

HR_MESSAGE is invoked programmatically rather than through a dedicated form or concurrent program. Typical invocation points include Oracle HRMS PL/SQL APIs and business rules that need to raise a formatted error, forms-level validation code that must display a localized message, and custom extensions or CEMLI objects that reuse HRMS error-handling conventions. Callers typically use PROVIDE_ERROR to raise a failure and then use LAST_MESSAGE_APP, LAST_MESSAGE_NAME, and LAST_MESSAGE_NUMBER to obtain the identity of the message, with GET_MESSAGE_TEXT and GET_TOKEN_VALUE used to render the resolved text. Because HR_MESSAGE is referenced by 42 other packages and is not itself referenced by database objects, it should be treated as a stable internal utility whose signatures are governed by Oracle, and custom code should call the documented procedures rather than reimplement them.