Search Results bis_error_message_pvt

Overview

APPS.BIS_ERROR_MESSAGE_PVT is a private PL/SQL API belonging to the Oracle E-Business Suite BIS (Business Intelligence/Applications) technology stack. Its documented purpose is to keep track of error messages generated during runtime processing. The package operates as a "PVT" (private) API, meaning it is intended for internal use by other BIS packages rather than being called directly by end-user application code or through public interfaces.

The package header and body carry historic source headers (BISVERMB.pls / BISVERMS.pls) dating from the original 1998–1999 authorship, with the last recorded revision occurring in December 2002. The package provides a lightweight, in-memory error logging framework built around the standard Oracle EBS API error-table pattern: an initialization step, an error-recording step, and accessors for the accumulated error data. The global package variable g_gen_error_tbl, declared as BIS_UTILITIES_PUB.Error_Tbl_Type, holds the session-level collection of error messages managed across the calling session.

Key Procedures and Functions

The ETRM metadata documents four procedures and functions, though the package includes six callable elements in total. The documented elements are:

• INIT_LOG — Initializes the error logging session. The body shows this procedure is overloaded: a no-argument version that simply delegates to the core version, and a version that returns an out return status and an out error table. Its implementation sets the return status to FND_API.G_RET_STS_SUCCESS and deletes any previously accumulated contents of the global error table, effectively resetting the log. As the source comment states, it is called "to start logging the messages." Because the search term "init_log" matches this procedure, it is the standard entry point for the API.
• UPDATE_ERROR_LOG — Records a failed generation into the error log. Its documented parameters include an error message, the return status, and the error table. This is the routine that accumulates entries into the global error collection during processing.
• GET_ERROR_COUNT — Returns the number of error messages currently held in the log, allowing callers to determine programmatically whether any errors were recorded during a processing run.
• GET_ERROR_TBL — Returns the populated error table collection to the caller for inspection, propagation, or display.

The two remaining elements in the header (not itemized in the metadata excerpt) follow the same pattern and complete the six-element interface. Together these routines implement the standard initialize / accumulate / query / retrieve lifecycle common to Oracle EBS private error-handling APIs.

Tables Accessed

The only table documented as referenced via APPS synonyms is PLITBLM. This table is associated with Oracle Applications message and error-message storage (the "message" infrastructure used by FND_MESSAGE and related utilities). It underpins the retrieval of translated or context-specific message text that the API logs. The package otherwise operates primarily against the in-memory collection g_gen_error_tbl rather than persisting error data to a database table; message text resolution is the reason a physical table is consulted at all.

Usage Notes

BIS_ERROR_MESSAGE_PVT is invoked by at least one other package (the metadata records a single dependent package). Typical invocation follows the Oracle EBS private-API convention: the calling routine first calls INIT_LOG to reset and prepare the log, then calls UPDATE_ERROR_LOG whenever a generation or sub-operation fails, then queries GET_ERROR_COUNT to test for failures, and finally calls GET_ERROR_TBL to obtain the accumulated messages for reporting or for merging into a public API's own error table. Because the API is classified PVT, customizations should generally call the public APIs that wrap it rather than invoking it directly. In Oracle EBS 12.1.1 and 12.2.2 the package remains part of the shipped APPS schema; the 12.2 upgrade and online patching architecture do not alter its private nature, and any custom code depending on it should treat its interface as subject to change across patches.