Search Results xdp_adapter_core_pipe




Overview
Explore in AI Chat

Overview

The APPS.XDP_ADAPTER_CORE_PIPE package body is a low-level infrastructure component within the Oracle E-Business Suite database tier. It belongs to the XDP product family, which provides the outbound and inbound integration framework commonly associated with Oracle EBS channel management, order or service activation flows, and the connection to external provisioning or fulfillment gateways. Its central responsibility is to manage the database pipe mechanism that transports adapter messages between the EBS application schema and external processes. Where higher-level adapter packages decide what to communicate, XDP_ADAPTER_CORE_PIPE handles the mechanics of how a channel is established, named, and used to move payloads in and out of the database. The package is owned by APPS, is reported with VALID status, and is classified as an OTHER API rather than a user-facing or concurrent-program API. It builds upon the companion package XDP_ADAPTER_CORE_DB, which supplies the underlying adapter data access logic, and it relies on the Oracle-supplied DBMS_PIPE built-in for all inter-process communication. In EBS 12.1.1 and 12.2.2 the package resides in the same location and serves the same architectural role, though the 12.2 online patching file system editioning model means the compiled body is maintained against the run edition of the APPS schema.

Key Procedures and Functions

The documented program units within the package body comprise six procedures and functions, each addressing a discrete stage of pipe lifecycle management:

  • GETUNIQUECHANNELNAME — Derives or retrieves a uniquely identifiable channel name so that concurrent adapter sessions do not collide when sharing the same database pipe namespace.
  • CONSTRUCTCHANNELNAME — Builds a channel name from its constituent parts according to the naming convention required by the adapter framework, providing the deterministic counterpart to the unique-name generator.
  • GETRETURNCHANNELNAME — Produces the name of the reply or return channel that an external process must use to send its response back to the EBS session that originated the request.
  • SENDPIPEDMESSAGE — Writes an outgoing adapter message onto the specified pipe, encapsulating the payload and handing it to DBMS_PIPE for delivery to the listening external process.
  • RECEIVEPIPEDMESSAGE — Reads an incoming message from a pipe, returning the payload to the calling adapter layer for parsing and further processing.
  • CLEANUPPIPE — Removes or purges a pipe once the exchange has completed, preventing orphaned pipes from consuming shared memory and avoiding stale identifiers being reused by later sessions.

Tables Accessed

The package references a small, focused set of objects. XDP_CHANNEL_S is the principal application table, an APPS-owned synonym over the channel definition table that supplies the channel identity and configuration data used by CONSTRUCTCHANNELNAME, GETUNIQUECHANNELNAME, and GETRETURNCHANNELNAME. This is the object most directly relevant to the search term xdp_channel_s, and it is the linkage point between the adapter metadata and the physical pipe names. DBMS_PIPE is the Oracle-supplied package invoked for the actual send, receive, and purge operations; it is a PL/SQL package rather than a table but appears in the dependency list as a referenced program unit. DUAL is used for single-row expression evaluation typical of name-generation logic. No other application tables are documented as dependencies, confirming that the package is a transport utility rather than a business-data repository.

Usage Notes

XDP_ADAPTER_CORE_PIPE is not intended for direct end-user invocation. It is called from within the adapter stack, most commonly by other XDP_ADAPTER_CORE packages and by adapter-specific handler code that needs to open a channel, dispatch a message, await a reply, and then release the pipe. Because the metadata records that the package is referenced by five other database objects but is itself not referenced by any further object, it sits near the bottom of the adapter call hierarchy and is best regarded as an internal service. Customizations should avoid calling the individual procedures out of sequence; the supported pattern is to obtain a channel name, send the message, receive the correlated response, and always invoke CLEANUPPIPE in exception handlers to guarantee resource release. During investigation of adapter communication failures, the pipe name returned by the name-generation functions is the key diagnostic value, and it can be correlated back to XDP_CHANNEL_S to verify that the expected channel was configured and enabled.