Search Results get_manager

Overview

FND_TRANSACTION_PIPE is a server-side PL/SQL package owned by the APPS schema in Oracle E-Business Suite. Its name reflects its purpose: the package manages inter-process communication over database pipes for the EBS transaction framework centered on FND_TRANSACTION. Rather than persisting business data directly, FND_TRANSACTION_PIPE provides the transport and coordination layer that lets concurrent workers detect each other, exchange lightweight messages, and hand off processing work. The underlying mechanism is the Oracle-supplied DBMS_PIPE package, which supports named, session-scoped message queues inside the database.

The documented ETRM entry classifies the package as an "OTHER" API and records it as VALID in both the 12.1.1 and 12.2.2 releases. It exposes two documented program units, GET_MANAGER and SEND_MESSAGE, and is referenced by one other package. Within the dependency graph, FND_TRANSACTION_PIPE references STANDARD and, through synonyms, a set of FND dictionary and concurrency tables that define the environment for the pipe exchange. The package is also referenced by APPS.FND_TRANSACTION and by itself, indicating internal recursive use.

Key Procedures and Functions

• GET_MANAGER — Returns the manager handle or coordinator context for the transaction pipe. It is the entry point by which a caller obtains the controlling process identity used to route messages within the pipe protocol.
• SEND_MESSAGE — Transmits a message into the transaction pipe. It is the outbound counterpart to GET_MANAGER, depositing a payload that the manager or a peer process subsequently reads.

Both units follow the naming convention of a producer/consumer pattern. Parameter lists are not reproduced here; callers should inspect the package specification and body in the target environment, since the documented metadata does not expose argument detail.

Tables Accessed

• FND_APPLICATION — Supplies application context, allowing the package to scope its behavior to the correct EBS application.
• FND_CONCURRENT_PROCESSES — Identifies running concurrent processes, enabling the package to target or resolve specific workers.
• FND_CONCURRENT_PROGRAMS — Provides program definitions associated with the processes participating in the transaction.
• FND_CONCURRENT_QUEUES — Resolves the queue context for the concurrent manager environment.
• FND_CONC_PROCESSOR_PROGRAMS — Links concurrent processors to programs, used to determine which worker should handle a given transaction.
• FND_RESPONSIBILITY — Supplies responsibility context so that processing respects EBS security and functional ownership.

In addition, the package uses the synonyms for DBMS_PIPE and DBMS_RANDOM, the former for the pipe transport itself and the latter typically for generating unique pipe names or session tokens that avoid collisions between concurrent workers.

Usage Notes

FND_TRANSACTION_PIPE is an internal infrastructure component rather than a general-purpose API. It is most commonly exercised indirectly. The concurrent manager stack and the FND_TRANSACTION package invoke it during transaction processing; FND_TRANSACTION is the only documented external referencer. In this respect the pipe package behaves as a supporting utility beneath the transaction layer, and direct calls from custom code are uncommon.

Where custom development does interact with it, the typical scenario is a bespoke concurrent program that must synchronize with the standard transaction workflow or notify a worker process of pending work. Because the package depends on DBMS_PIPE, callers inherit pipe semantics: messages are transient, session-bound, and not transactional. A rollback does not un-send a message, and a process restart discards queued payloads. Pipe buffers are also size-limited, so large objects should never be passed through this mechanism.

From a maintenance and upgrade perspective, the package is marked VALID in both 12.1.1 and 12.2.2, and the ETRM metadata shows no signature change between the two releases. Its classification as OTHER indicates it is not part of Oracle's published, guaranteed API surface. Customizations that call GET_MANAGER or SEND_MESSAGE directly therefore carry upgrade risk and should be minimized, wrapped, and regression-tested during any EBS patching or upgrade cycle.