Search Results start_adapter

Overview

XDP_ADAPTER is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that provides the programmatic interface for managing and controlling the adapter layer used by Oracle's e-commerce and integration framework. Adapters serve as the concrete communication clients that connect outbound or inbound business messages to external systems, and XDP_ADAPTER encapsulates the lifecycle operations required to define, configure, start, stop, and monitor those adapters. The package is classified as OTHER in the ETRM metadata, indicating that it is an internal infrastructure API rather than a public, customer-facing business interface. In Oracle EBS 12.1.1 and 12.2.2 it operates in support of the XML Gateway / e-commerce transaction infrastructure, coordinating adapter registrations maintained in the XDP adapter registration tables. Because adapters can run unattended, the package also exposes request and administrative operations that let scheduled or monitored processes create, update, delete, and query the state of an adapter's administrative request. Recovery and control packages such as XDP_RECOVERY, XDP_PROC_CTL, and XDP_CRON_UTIL depend on it directly, confirming that XDP_ADAPTER is a low-level component of the adapter runtime. It relies only on SYS.STANDARD at the database level, so its external behavior is defined entirely by the APPS tables it manipulates.

Key Procedures and Functions

The ETRM metadata documents twenty-five procedures and functions, summarized here by purpose:

• Adapter definition: CREATE_ADAPTER, UPDATE_ADAPTER, and DELETE_ADAPTER manage the lifecycle of an adapter registration; DELETE_ALL_FOR_FE removes every adapter associated with a given front end.
• Adapter validation and operation: VERIFY_ADAPTER checks that an adapter is correctly configured, IS_ADAPTER_CONFIGURED returns whether configuration exists, and GENERIC_OPERATION provides a general entry point for adapter operations.
• Administrative requests: CREATE_ADMIN_REQUEST, UPDATE_ADMIN_REQUEST, and DELETE_ADMIN_REQUEST maintain the administrative request records that drive asynchronous adapter activity.
• Runtime state control: START_ADAPTER, STOP_ADAPTER, SUSPEND_ADAPTER, RESUME_ADAPTER, CONNECT_ADAPTER, DISCONNECT_ADAPTER, and TERMINATE_ADAPTER change the operational state of a running or idle adapter.
• Monitoring and diagnostics: GET_ADAPTER_EXIT_CODE returns the last exit status, VERIFY_RUNNING_ADAPTERS checks the health of active adapters, and GET_ADAPTER_LOG_FILE_URL returns the location of an adapter's log file for troubleshooting.

Tables Accessed

The package touches four application tables through APPS synonyms. XDP_ADAPTER_REG holds the adapter registration rows that record each configured adapter; most definition and state procedures read and write it. XDP_ADAPTER_TYPES_B stores the seeded adapter type definitions that constrain what an adapter may be, and is consulted when validating or creating adapters. XDP_FES records the front-end applications or transactions that adapters serve, which is why DELETE_ALL_FOR_FE is scoped by front end. FND_FILE_TEMP is the standard Oracle Applications temporary file table used to stage output such as generated log content or diagnostic text produced by the monitoring routines.

Usage Notes

XDP_ADAPTER is not intended for direct end-user invocation. It is called from the XML Gateway and e-commerce setup and administration forms, from concurrent programs that launch and supervise adapters, and from other framework packages. The dependency listing shows it is referenced by XDPCORE, XDPCORE_FA, XDP_CONTROLLER_CORE, XDP_MACROS, XDP_ORDER_SYNC, XDP_PROC_CTL, XDP_RECOVERY, XDP_CRON_UTIL, XDP_APPLICATION, XNP_ADAPTER, and the XDP_ADAPTER_CORE and XDP_ADAPTER_CORE_DB subprogram units. The search term "xdp_adapter_core_db" corresponds to XDP_ADAPTER_CORE_DB, the database-side core unit that both references and is referenced by XDP_ADAPTER, indicating that calls made through XDP_ADAPTER ultimately execute the core database procedures. Customizations should avoid modifying this package; supported extension points should be used instead, since changes can break adapter startup, recovery, and order synchronization logic across the EBS instance.