Search Results get_message

Overview

XLA_MESSAGES_PKG is a PL/SQL package owned by the APPS schema that forms part of the Subledger Accounting (XLA) infrastructure in Oracle E-Business Suite releases 12.1.1 and 12.2.2. Its principal business function is to centralize the construction, identification, and retrieval of application messages used by the XLA engine and its dependent modules. Because subledger accounting processes — journal entry generation, event processing, accounting program execution, and error reporting — must surface consistent and translatable messages to end users, XLA_MESSAGES_PKG provides a controlled wrapper over the Oracle Application Object Library messaging API (FND_MESSAGE). The package allows callers to both register a message on the internal message stack and obtain the numeric message identifier, while also supporting token substitution so that dynamic values such as account numbers, event identifiers, or period names can be embedded within the message text.

The header comment traces the object's lineage to 1995, when it was originally created, and records that it was adapted for XLA in February 2001. The packaged body carries the revision marker 120.4, indicating its most recent shipped iteration in the 12.x code line. ETRM classifies the object as an "OTHER" API, meaning it is a supporting internal utility rather than a public, officially supported extension interface.

Key Procedures and Functions

The ETRM metadata documents sixteen procedures and functions within the package. The three specifically named in the available source excerpt and documentation are:

• BUILD_MESSAGE — Overloaded to register a named message against an application short name and to optionally attach one or more token/value pairs. In the documented form, the procedure calls FND_MESSAGE.SET_NAME to load the message and stores the numeric message number in a package global (g_message_number) retrieved via FND_MESSAGE.GET_NUMBER. Overloads extend this behaviour so that a message may be completed with the value for one token, and by implication further overloads support additional tokens. The procedure holds the message context; it does not itself raise or display the error.
• GET_MESSAGE — Retrieves the message text associated with the previously built or specified message, allowing calling code to obtain the fully substituted string rather than emitting it immediately. This is the object most commonly searched for by developers investigating the "get_message" reference.
• GET_MESSAGE_PREFIXED — Returns the message text prefixed with a standard identifier such as the owning application short name or message identifier, producing the composite format frequently written to concurrent program logs and XLA exception tables.

The remaining documented routines follow the same design pattern, providing build, get, and prefixed variants across the package's messaging surface.

Tables Accessed

No base tables are recorded as directly referenced by the package body through APPS synonyms. Message definitions are resolved through the Application Object Library message repository, which the FND_MESSAGE API queries on the package's behalf (principally FND_NEW_MESSAGES and related AOL message views). This indirection means XLA_MESSAGES_PKG performs no direct DML and holds no application data of its own; the sole state it maintains is in-memory package globals such as g_message_number.

Usage Notes

XLA_MESSAGES_PKG is invoked by other PL/SQL units rather than by end-user forms. ETRM records that it is referenced by fourteen other packages, confirming its role as a shared utility within the XLA and subledger accounting stack. Typical invocations occur from accounting program error handlers, event and journal line validation routines, and create-accounting logic where a message must be composed with substitution tokens and then either logged or raised. Custom code developed against the XLA schema may call GET_MESSAGE or BUILD_MESSAGE to obtain consistent, translated text that mirrors seeded application messages, but developers should note the API's "OTHER" classification: Oracle does not guarantee backward compatibility of the signature, and direct reliance on internal globals such as the stored message number is discouraged.