Search Results xdp_adapter_core




Overview
Explore in AI Chat

Overview

The APPS.XDP_ADAPTER_CORE package body is a core component of the Oracle E-Business Suite EDI/XML Gateway messaging infrastructure. Its principal role is to manage the runtime communication between Oracle EBS and external adapter processes — typically transmission adapters that handle the wire-level exchange of business documents with trading partners. Rather than performing business-document transformation or envelope validation (handled by sibling packages), this package focuses on the transport handshake: opening a conversation with an adapter, dispatching outbound messages, waiting for replies, correlating acknowledgements, and notifying the adapter layer when a session must be suspended or terminated.

The package carries a documented API classification of OTHER, indicating it is not part of a published customer-facing API surface intended for direct call. In ETRM 12.2.2 it exposes fifteen procedures and functions. It is referenced by seven other database objects, confirming its position as a shared internal service rather than an entry point.

Key Procedures and Functions

  • SENDSYNC — Performs a synchronous send to the adapter, transmitting an outbound payload and blocking until the adapter responds.
  • SENDRESPONSE — Sends a response message back to the adapter, commonly used to complete a bidirectional exchange.
  • SENDACK — Dispatches an acknowledgement to the adapter for a previously received inbound message.
  • SENDCONTROLCOMMAND — Transmits a control instruction to the adapter, used to manage adapter state independently of document traffic.
  • PROCESSCONTROLCOMMAND — Interprets and acts upon a control command received from the adapter side.
  • TALKTOADAPTER — The underlying conversation routine that handles the interaction session with the adapter process.
  • SENDAPPLICATIONMESSAGE — Delivers an application-level message (as opposed to a control command) to the adapter for onward transmission.
  • RECEIVEACK — Receives and processes an acknowledgement returned by the adapter, confirming receipt of an outbound message.
  • SENDMESSAGE — General-purpose outbound message dispatch routine.
  • WAITFORMESSAGE — Blocks pending the arrival of a message from the adapter, used where a reply is expected.
  • VERIFYADAPTEROPERATION — Checks that the adapter is operating correctly before proceeding with a transaction.
  • SHOULDADAPTERCONNECT — Determines whether a connection to the adapter should be initiated, typically reflecting configuration or runtime state.
  • NOTIFYADAPTERTERMINATEFAILURE — Raises notification when an attempt to terminate the adapter fails.
  • NOTIFYADAPTERSYSDEACTIVATION — Notifies the adapter layer of system deactivation so that connections can be closed cleanly.

One additional entry appears in the count of fifteen; the enumerated list above represents the procedures and functions named in the ETRM metadata.

Tables Accessed

The available metadata does not enumerate any base tables directly referenced by XDP_ADAPTER_CORE. Its documented dependency list instead points to PL/SQL objects: APPS.WF_NOTIFICATION, XDP_ADAPTER, XDP_ADAPTER_CORE_DB, XDP_ADAPTER_CORE_PIPE, XDP_ADAPTER_CORE_XML, and XDP_UTILITIES, plus the SYS STANDARD package. Notably, WF_NOTIFICATION is present, which indicates the package raises Oracle Workflow notifications — consistent with the two notification procedures listed above. The _PIPE and _XML siblings suggest that the persistent message queue and XML payload handling are delegated to companion packages rather than to base tables accessed directly from this body.

Usage Notes

Because XDP_ADAPTER_CORE is classified as OTHER and is referenced by seven other packages but referenced by no external object, it is an internal service layer. It is not designed to be invoked directly from Oracle Forms, concurrent program definitions, or customer extensions. Instead, higher-level EDI/XML Gateway packages — the seven dependents — call into it to orchestrate adapter communications during outbound document transmission and inbound receipt.

Administrators and developers should treat this package as diagnostic context: the ETRM dependency report and its VALID status are used to confirm installation integrity and to trace which packages depend on adapter communication. Direct invocation is not recommended, since the control-command and acknowledgement sequencing assumes a surrounding session managed by the caller.