Search Results oe_message_purge_pvt




Overview
Explore in AI Chat

Overview

APPS.OE_MESSAGE_PURGE_PVT is a private PL/SQL package in Oracle E-Business Suite that provides the programmatic foundation for purging obsolete processing messages generated by the Order Management (OM) module. During order import, order entry, and downstream order lifecycle processing, Oracle Order Management writes diagnostic and error records into the OE_PROCESSING_MSGS and OE_PROCESSING_MSGS_TL tables. Over time these message rows — particularly those resolved long ago or associated with closed orders — accumulate and degrade query performance and inflate the size of OM tables. OE_MESSAGE_PURGE_PVT supplies the purge logic used to selectively remove these records.

The package carries the PVT classification, indicating it is a private API. It is not intended for direct invocation by external application code; rather, it is consumed by a public wrapper or by the concurrent program that drives message purging. The header comment visible in the source identifies a current version of 1.0 and references a source file control string dated 2005, consistent with the long-standing maturity of this utility across the 11i and R12 code lines, including 12.1.1 and 12.2.2.

Key Procedures and Functions

The package exposes a single documented procedure: PURGE.

  • PURGE — Removes processing message records from the Order Management message tables according to the criteria supplied by the caller. The procedure accepts the standard concurrent program OUT parameters (errbuf and retcode) along with a set of selection criteria that constrain which messages are eligible for deletion. These criteria include a commit batch size; a start and end date range; a message source; customer identifier and customer number; order type; a start and end order number range; and a message status code. By exposing this breadth of filtering, PURGE allows the caller to target a precise subset of messages — for example, all error messages of a given source within a date window, or all messages tied to a specific customer or order range — rather than performing a blanket deletion. The procedure is declared with default values on several parameters, so callers may supply only the criteria relevant to a given purge run.

Tables Accessed

The ETRM metadata documents three tables referenced through APPS synonyms:

  • OE_PROCESSING_MSGS — The core Order Management processing message table. This is the primary target of deletion operations, holding the individual message records that accumulate during order processing.
  • OE_PROCESSING_MSGS_TL — The translation (TL) table associated with OE_PROCESSING_MSGS. It stores language-specific message text. Referencing this table ensures that translated message content is purged in step with the base message records, maintaining referential integrity between the base and translation rows.
  • OE_ORDER_HEADERS_ALL — The order header base table. It is accessed to resolve the relationship between messages and their parent orders, supporting the order number range, order type, and customer criteria used to scope which messages qualify for purge.

Usage Notes

Because OE_MESSAGE_PURGE_PVT is a private package, it is not designed for direct calls from custom forms or external integrations. It is typically invoked indirectly — most commonly through the Order Management concurrent program that performs message purging, where the PURGE procedure executes under the standard concurrent manager framework. The errbuf and retcode OUT parameters follow the concurrent program convention, indicating successful or failed completion and returning a diagnostic message.

The configurable commit batch size lets administrators balance transaction size against rollback segment and undo consumption when purging large volumes of messages, which is important when historical message populations are substantial. The date range, order number range, customer, and status filters should be chosen carefully to avoid removing messages still required for active troubleshooting or audit. As with any data-purge utility, a validated backup and a low-volume test run are advisable before executing a wide-ranging purge in a production environment.