Search Results gl_message




Overview
Explore in AI Chat

Overview

GL_MESSAGE is a utility package body owned by the APPS schema in Oracle E-Business Suite, classified under the general-purpose "OTHER" API category. It functions as the central messaging, logging, and language-handling engine for the Oracle General Ledger application. Rather than serving a single business transaction, GL_MESSAGE provides a shared services layer that other General Ledger programs call to obtain translated message text, expand message tokens into their runtime values, direct output to concurrent program log and output files, and record diagnostic information into the FND_LOG infrastructure. Because it abstracts message retrieval, substitution, and destination handling into one reusable package, it allows GL concurrent programs, forms-based logic, and custom extensions to emit consistent, language-aware messages without duplicating formatting code. It is a foundational, low-level component: the ETRM metadata records that GL_MESSAGE is not referenced by any database object in the dependency chain, yet it is referenced by 57 other packages, confirming its role as a widely consumed infrastructure dependency rather than a caller of higher-level business logic.

Key Procedures and Functions

  • GET_MESSAGE — Retrieves a message definition, typically resolving the message name through FND_MESSAGE, so callers receive language-appropriate text.
  • MSG_TKN_EXPAND — Expands message tokens within a message string, substituting placeholder values supplied by the caller with their runtime content.
  • SET_LANGUAGE — Establishes the language context used for message resolution and translation.
  • WRITE_BUFFER — Manages the in-memory buffer that accumulates message output before it is written to a destination.
  • WRITE_OUTPUT — Writes formatted lines to the concurrent program output file.
  • WRITE_LOG — Writes log lines to the concurrent program log file.
  • WRITE_FNDLOG_MSG — Routes a message to the FND_LOG diagnostic framework.
  • WRITE_FNDLOG_STRING — Writes a free-text string to the FND_LOG diagnostic framework.
  • FUNC_SUCC — Returns a success status indicator for standardized function return handling.
  • FUNC_FAIL — Returns a failure status indicator for standardized function return handling.
  • FUNC_ENT — Provides an entry-point status marker used when a routine begins execution.

Tables Accessed

The documented dependency list identifies only DUAL, referenced through APPS synonyms. DUAL is used for trivial single-row selection and expression evaluation, consistent with a package that primarily manipulates PL/SQL values and message constructs. The substantive data access is channeled through dependent packages rather than direct table references: FND_MESSAGE supplies message definitions and translation, FND_FILE provides concurrent program log and output file handles, and FND_LOG supplies the logging API behind WRITE_FNDLOG_MSG and WRITE_FNDLOG_STRING. Message text therefore originates from the FND message repository via FND_MESSAGE, not from GL-specific tables. This design keeps GL_MESSAGE decoupled from application data tables and safe to call from any General Ledger context.

Usage Notes

GL_MESSAGE is typically invoked indirectly. General Ledger concurrent programs, whose PL/SQL drivers execute under the APPS schema, call it to emit progress and error messages to the log and output files, to expand tokens such as program or parameter names into standardized text, and to publish diagnostics to FND_LOG. The FUNC_ENT, FUNC_SUCC, and FUNC_FAIL helpers indicate a convention in which individual routines signal entry, success, and failure states in a uniform manner, simplifying tracing across the 57 packages that depend on it. SET_LANGUAGE and GET_MESSAGE cooperate so message text respects the session language, while MSG_TKN_EXPAND ensures messages display substituted values correctly. Custom code extending General Ledger should call GL_MESSAGE rather than writing directly to FND_FILE or FND_LOG, because it encapsulates the expected formatting, buffering through WRITE_BUFFER, and language handling in one place. The package status is VALID, and no database object depends on GL_MESSAGE upward, meaning modifications carry no reverse-dependency risk—though its broad downstream consumption demands caution when changing behavior.