Search Results xdp_interfaces




Overview
Explore in AI Chat

Overview

The APPS.XDP_INTERFACES package body is a core integration and orchestration component of Oracle E-Business Suite's Supply Chain Execution and Distributed Order Orchestration (DOO) functionality. In the EBS 12.1.1 and 12.2.2 architectures, the XDP schema objects support the order fulfillment engine, which coordinates the life cycle of an order from capture through fulfillment, shipment, and closure across heterogeneous fulfillment systems. XDP_INTERFACES acts as the public API layer through which external callers — including Oracle Order Management, the Order Fulfillment engine, workflow components, and custom extensions — submit orders, query order and line status, manipulate fulfillment status flags, and retrieve order parameters. Because it is documented as validated and classified as "OTHER" (an API-style package rather than a pure internal library), it is intended for direct invocation by integration code rather than being reserved exclusively for internal engine use. The package body depends heavily on peer XDP packages (XDP_ENGINE, XDP_ORDER, XDP_ORDER_HEADERS, XDP_TYPES, XDP_OA_UTIL, and XDP_WORKITEMS), on Oracle Workflow components (WF_ENGINE, WF_ITEMS_V, and XNP_EVENT, XNP_MSGS, XNP_TIMER_CORE), and on the FND API, message, logging, profile, and lookup infrastructure, reflecting its dual role as both a business API and an event-driven integration point.

Key Procedures and Functions

The package exposes twenty-one documented procedures and functions. Order submission is handled by PROCESS_ORDER, which drives a standard sales order through the fulfillment interface, and PROCESS_DRC_ORDER, which processes orders submitted in a distributed order orchestration context. CANCEL_ORDER provides the counterpart operation, cancelling an order previously submitted through the interface. Status retrieval is served by a family of getters: GET_ORDER_STATUS and GET_LINE_STATUS return current processing state for an order or an individual line, while GET_ORD_FULFILLMENT_STATUS and GET_LINE_FULFILLMENT_STATUS report the fulfillment-specific status separately from general order state. These are complemented by SET_ORD_FULFILLMENT_STATUS and SET_LINE_FULFILLMENT_STATUS, which allow callers to advance or correct fulfillment state programmatically. Parameter handling is supported by GET_ORDER_PARAM_VALUE, GET_ORDER_PARAM_LIST, GET_LINE_PARAM_VALUE, and the related SET operations, enabling attribute exchange between the calling application and the fulfillment engine. GET_ORDER_DETAILS returns a consolidated view of order information for downstream consumption. All procedures are invoked against the APPS schema and are intended to be called within a properly initialized EBS session.

Tables Accessed

Through APPS synonyms the package touches the core XDP order tables: XDP_ORDER_HEADERS and its shadow table XDP_ORDER_HEADERS_S, XDP_ORDER_LINE_ITEMS, XDP_ORDER_LINEITEM_DETS, XDP_ORDER_PARAMETERS, and XDP_ORDER_RELATIONSHIPS. Work management tables XDP_WORKITEMS, XDP_FULFILL_WORKLIST, XDP_FA_RUNTIME_LIST, and XDP_ADAPTER_JOB_QUEUE store and queue the fulfillment tasks the package creates or inspects. Messaging and event infrastructure is accessed through XNP_MSGS, and DBMS_AQ is used for advanced queueing operations. Reference data lookups include FND_LOOKUP_VALUES for flexfield and lookup validation, HZ_CUST_ACCOUNTS for customer account context, and MTL_PARAMETERS for inventory organization defaults.

Usage Notes

XDP_INTERFACES is typically invoked from Oracle Workflow business event subscriptions, from concurrent programs that poll the adapter job queue, and from custom PL/SQL integration code that submits or queries fulfillment orders. Because it is referenced by four other packages, it also functions as a shared service layer. Callers should initialize the FND global context (application, responsibility, user) before invocation, as the package relies on FND_GLOBAL and FND_PROFILE for session attributes, and should observe standard FND_API exception handling and message retrieval conventions. The package is not referenced by any database object in the dependency graph, meaning it is a top-level entry point rather than a subordinate module, reinforcing its role as the sanctioned integration surface for XDP order processing.