Search Results dbms_streams_messaging




Overview
Explore in AI Chat

Overview

DBMS_STREAMS_MESSAGING is a standard Oracle database-supplied PL/SQL package owned by the SYS schema and shipped with the Oracle RDBMS kernel. Within Oracle E-Business Suite 12.1.1 and 12.2.2, it provides the low-level messaging primitive that underpins Oracle Streams and, by extension, Advanced Queuing and the data-replication features used by EBS components such as Oracle Alert, Workflow background engines, and the Applications Technology stack. The package exposes a simplified enqueue/dequeue interface over the underlying ANYDATA payload type, allowing a session or application to place a message onto a Streams capture queue and later retrieve it. In the EBS context it is best understood as a horizontal infrastructure dependency rather than an Applications-owned API: it is catalogued in ETRM with an API classification of OTHER, is VALID, and is referenced only by PUBLIC and SYS synonyms. No EBS product schema directly owns or invokes it through a documented call path, which reflects its role as a supporting kernel service.

Key Procedures and Functions

ETRM documents four total procedures/functions, which resolve to two named entry points, each with overloaded or paired variants for the enqueue and dequeue directions:

  • ENQUEUE — Places a message onto a Streams queue. The caller supplies the queue name, the message payload (wrapped as ANYDATA), and associated message properties such as correlation and priority. In EBS this effectively lets a session publish an event or data change into the replication stream without constructing a full AQ enqueue call.
  • DEQUEUE — Retrieves a previously enqueued message from a Streams queue, returning the ANYDATA payload and message metadata to the caller. Dequeue supports the usual navigation and visibility options used to consume messages in order or selectively.

The four documented entries therefore represent the enqueue and dequeue directions plus their companion forms. Parameter lists are not reproduced here; consult the Oracle-supplied package specification (via the "show dependent code" links in ETRM) before invoking them directly.

Tables Accessed

The ETRM dependency extract lists the package's direct references as SYS, ANYDATA, and STANDARD. This means DBMS_STREAMS_MESSAGING does not statically bind to EBS application tables through APPS synonyms; the documented "tables referenced via APPS synonyms" is empty. Instead, it operates on Streams/AQ queue infrastructure — the underlying queue tables that physically persist messages — which are created at database level rather than as EBS product tables. Its only compile-time dependencies are the SYS schema, the ANYDATA type used to carry polymorphic payloads, and the STANDARD package providing core PL/SQL runtime support. From the EBS perspective, the effective target storage is the Streams capture/apply queue populated when a queue is created, not an Applications table.

Usage Notes

Because it is referenced by zero other EBS packages and is not surfaced through any form, concurrent program, or Applications-owned API in ETRM, DBMS_STREAMS_MESSAGING is not invoked directly by standard EBS processing. It is instead reached transitively through Oracle Streams and AQ, which the database uses internally for replication and for features that EBS relies on but does not call by name. Direct invocation is accordingly the preserve of DBA and custom development work — for instance, bespoke integrations that publish or consume messages across EBS instances via Streams. Two practical cautions apply. First, the package is a SYS-owned kernel object: grants are managed by the database, and application schemas must be granted EXECUTE explicitly before custom code can call it. Second, as of EBS 12.2.2 and later database releases, Oracle Streams has been superseded by Oracle GoldenGate and is excluded from most certified configurations; the same messaging needs are normally met with DBMS_AQ. Administrators should therefore treat DBMS_STREAMS_MESSAGING as legacy infrastructure, confirm the target database release still supports it, and prefer a supported queueing API for new development.