Search Results fnd_transaction_queue




Overview
Explore in AI Chat

Overview

FND_TRANSACTION_QUEUE is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite. It forms part of the Oracle Advanced Queuing (AQ) based infrastructure used by the concurrent manager ecosystem, specifically for moving transaction payloads between concurrent processing components. The package encapsulates the enqueue/dequeue logic that allows transaction messages to be staged in an AQ queue and consumed asynchronously by concurrent manager processes rather than being passed synchronously. In EBS 12.1.1 and 12.2.2 this asynchronous pattern underpins the internal "manager" communication between the concurrent manager and the transaction manager worker processes. The package is classified under the ETRM as OTHER (no published API classification), meaning it is an internal, Oracle-owned utility rather than a formally supported public API. Its status is VALID in the documented release. It is not referenced by any other database object, indicating it sits at the top of its dependency chain and is invoked directly by the concurrent manager runtime. It does, however, reference the package APPS.FND_TRANSACTION_QUEUE itself (recursive internal calls) and one payload type, SYSTEM.FND_CP_TM_AQ_PAYLOAD.

Key Procedures and Functions

The ETRM documentation records two documented program units within this package body:

  • GET_MANAGER — Retrieves manager-related context or state associated with the transaction queue. In the AQ transaction-queue pattern, this routine is used to resolve and return the manager identity or manager-side configuration needed to process queued transaction messages. It supports the package's role in coordinating which concurrent manager instance handles a given queued message.
  • SEND_MESSAGE — Enqueues a message onto the transaction queue. This is the producer-side operation: a caller packages a payload (of the FND_CP_TM_AQ_PAYLOAD structure) and SEND_MESSAGE places it onto the AQ queue for later consumption by the manager/worker process. SEND_MESSAGE encapsulates the DBMS_AQ enqueue call and the associated queue/agent setup, insulating callers from the raw AQ API.

No parameter lists are published in the ETRM record, and none should be assumed. The two procedures constitute the outward-facing surface of an otherwise internal messaging package.

Tables Accessed

The package reads Oracle EBS concurrent-processing dictionary tables (via APPS synonyms) to resolve queue, program, and manager definitions, and writes to the AQ queue for message transport. Documented objects referenced include:

  • FND_CONCURRENT_QUEUES — queue definitions that identify which concurrent queue a transaction message targets.
  • FND_CONCURRENT_PROGRAMS — program definitions used to associate a message with the concurrent program to be run.
  • FND_CONCURRENT_PROCESSES — the running concurrent process records, used to validate or target the manager/worker process.
  • FND_CONC_PROCESSOR_PROGRAMS — mapping between concurrent processors and the programs they can execute.
  • FND_APPLICATION — application context resolution for the transaction.
  • FND_RESPONSIBILITY — responsibility context associated with the queued transaction.
  • DBMS_AQ — the AQ PL/SQL API used to enqueue and dequeue messages.

Together these provide the metadata needed to route a transaction message to the correct manager, while DBMS_AQ and the FND_CP_TM_AQ_PAYLOAD type carry the actual message content.

Usage Notes

FND_TRANSACTION_QUEUE is an internal Oracle EBS component and is not intended for direct invocation by customer extension code. It is exercised by the concurrent manager and transaction manager runtime whenever transactions must be handed off asynchronously between managers and worker processes. Because it depends on AQ and on the concurrent processing dictionary, its behavior is tied to the state of the concurrent manager configuration. In 12.2.x, where the online patching (adop) and editioning model applies, the package is compiled in the APPS schema alongside other FND objects. Customizations should not call GET_MANAGER or SEND_MESSAGE directly; instead, standard concurrent submission APIs should be used. The package's validity should be verified after patching or upgrade, as an INVALID state will disrupt concurrent manager message processing.