Search Results c_oa_message




Overview
Explore in AI Chat

Overview

XLA_EXCEPTIONS_PKG is a shared error-handling utility within the Oracle Subledger Accounting (XLA) module of Oracle E-Business Suite. Its role is to centralize the raising, formatting, and propagation of application exceptions and user-facing messages across the XLA schema. Rather than embedding literal message text and error codes in each subledger accounting program, developers call this package so that error conditions are reported consistently, whether the caller is a concurrent program, an OAF page, or a standard Oracle Forms interface. The package is declared with AUTHID CURRENT_USER, meaning that name resolution and privilege checking occur in the schema of the invoking session rather than in the APPS schema, which is significant given that XLA routines are frequently called from cross-schema contexts.

The header history indicates the package was created in January 1995 by P. Juvara for an earlier accounting engine and was adapted for XLA by P. Labrevois in February 2001. It therefore predates the general ledger and subledger accounting redesign and carries forward a proven exception-reporting pattern.

Key Procedures and Functions

The ETRM metadata documents nine procedures and functions in total, of which two are named explicitly:

  • RAISE_EXCEPTION — Raises the standard XLA application exception. It is the mechanism by which a validation or processing failure is signalled back to the calling program so that normal execution halts and the error is surfaced to the user or the concurrent manager log. This is the procedure most directly associated with the search term "raise_message," since raising an exception is the action that ultimately displays a message.
  • RAISE_MESSAGE — Presents a message to the user through the appropriate channel, selected by the package constants C_STANDARD_MESSAGE ('S') and C_OA_MESSAGE ('O'). The 'O' constant indicates an OA Framework (OAF) message, while 'S' indicates the standard EBS message dictionary path. The procedure therefore abstracts over the two dominant EBS user-interface technologies so that callers need not know whether they are executing in a Forms session or an OAF page.

The package also declares a package-level variable, exception_text VARCHAR2(2000), which carries the message payload between the raising and display routines.

Tables Accessed

The documented metadata lists no base tables referenced through APPS synonyms. This is consistent with the package's design intent: it is a message and exception formatting utility, not a data-processing program. Any message text it displays is resolved through the Oracle Application Object Library message dictionary rather than through direct SQL against XLA transaction or accounting tables. Consequently the package performs no inserts, updates, or deletes on subledger accounting data and raises no transactional integrity concerns of its own.

The package does declare three predefined exceptions — application_exception bound to error -20001, resource_busy bound to ORA-00054, and too_many_rows bound to ORA-01422 — which allow callers to trap and translate database-level conditions into XLA-standard messages.

Usage Notes

XLA_EXCEPTIONS_PKG is used pervasively. The ETRM metadata records that it is referenced by 225 other packages, making it one of the most widely depended-upon utilities in the XLA schema. Any custom code that extends subledger accounting — for example, a custom accounting method, a custom derivation rule, or a custom subledger program — should follow the same convention and call RAISE_EXCEPTION or RAISE_MESSAGE rather than raising raw application errors, so that error text remains consistent with seeded XLA behaviour.

Because the package is not an API in the strict sense (its ETRM classification is OTHER), it is not governed by the same upgrade-compatibility guarantees as public XLA APIs. Developers should nonetheless treat it as a stable internal contract, and should be aware that the 225-package dependency footprint means any change to its behaviour has wide blast radius across the subledger accounting product. The 12.1.1 and 12.2.2 releases share the same documented signature set, so code written against this package remains portable between those versions.