Search Results provide_error




Overview
Explore in AI Chat

Overview

HR_MESSAGE is an Oracle E-Business Suite PL/SQL package owned by the APPS schema and classified under the generic API category "OTHER." It functions as a utility layer that sits above the Oracle Application Object Library message facility, FND_MESSAGE, and provides a structured, record-oriented interface for interrogating the errors that Oracle EBS applications raise during execution. Its central purpose is to decode and expose the state of the FND_MESSAGE global variables once an application error has been trapped, so that calling code can determine which application raised the last message, which message was raised, and what token substitution values accompany it.

The package declares the AUTHID CURRENT_USER pragma, meaning its procedures execute with the privileges of the invoking user rather than the defining user. The header comment identifies it as an early ported component (hrmesage.pkh version 115.1), which explains its terse coding conventions and its emphasis on remaining transparent to errors that are not application-generated, such as native ORA- errors.

Key Procedures and Functions

Seven callable units are documented for this package. Their responsibilities are complementary and are intended to be used in a defined sequence.

  • PROVIDE_ERROR — The initialization and entry point for the package. It retrieves the encoded error message into a record component and then calls FND_MESSAGE supplied routines to capture the application that placed the last message on the stack together with that message's name. Documented behavior states it never fails outright: if an application error is present and the current SQLCODE indicates an application error, the global variables are initialized; otherwise SQLCODE and SQLERRM are propagated through the procedure unchanged. It does not alter the local state of FND_MESSAGE.
  • PARSE_ENCODED — Decodes the encoded message string obtained by PROVIDE_ERROR into its constituent parts, enabling subsequent token and text retrieval.
  • LAST_MESSAGE_NUMBER — Returns the identifier of the most recent message placed on the FND_MESSAGE stack.
  • LAST_MESSAGE_NAME — Returns the name of the most recent message on the stack.
  • LAST_MESSAGE_APP — Returns the application short name responsible for generating the most recent message.
  • GET_TOKEN_VALUE — Extracts the substituted value associated with a named token in the current message, allowing callers to reconstruct the human-readable error text.
  • GET_MESSAGE_TEXT — Returns the fully assembled, readable message text for the error currently held in the package's record structure.

Tables Accessed

The ETRM metadata for HR_MESSAGE lists no base tables referenced through APPS synonyms. This is consistent with the package's design: it does not perform its own SQL against application tables but instead depends entirely on in-memory state maintained by FND_MESSAGE. Message metadata and translated text are resolved indirectly through the FND_MESSAGE API, which itself reads from the message repository on the caller's behalf. As a consequence, HR_MESSAGE introduces no direct read or write dependencies on business data tables, minimizing its concurrent-programming and locking footprint.

Usage Notes

HR_MESSAGE is documented as being referenced by 42 other packages, confirming its role as a shared error-handling utility across the HR and related product families rather than a standalone API. The header comment imposes a strict calling convention: PROVIDE_ERROR must be executed before any other function in the package, because the remaining routines depend on the record structure it populates. Typical invocation patterns include exception handlers in PL/SQL packages and concurrent program logic that must surface a meaningful message to the user instead of a raw code, and Oracle Forms code that needs to display the application, name, and substituted text of the last raised error. Because the package is transparent to non-application errors, callers that trap ORA- exceptions should branch on the SQLCODE check described in the Post Success documentation rather than assuming the message attributes will be populated. Custom code should follow the same sequence — provide, then parse, then query — to guarantee correct results.