--- schema_version: "1" id: b5f577785d44028fb77d947f62752031bc56c81a4c63d3e7a8a03387e83dbf26 title: XOMAsyncSystemInterface collection: admin version: current locale: en-us portal_url: https://docs.salesforce.com/admin/current/en-us/ind/264-0-0/comms_t_xomasyncsysteminterface_235423.md canonical_url: https://help.salesforce.com/s/articleView?id=ind.comms_t_xomasyncsysteminterface_235423.htm&release=264.0.0&type=5 source_site: help.salesforce.com content_type: documentation content_hash: b9d2eda22e5a68c024aca6182f805877027b9028c9f843358f405a57d9754498 description: The XOMAsyncSystemInterface adapter works with an orchestration item (a callout) to communicate asynchronously with an external system. That is, the callout doesn't expect an immediate response from the external system. products: - Industry Solutions - Cross Cloud release: "264" --- # XOMAsyncSystemInterface The XOMAsyncSystemInterface adapter works with an orchestration item (a callout) to communicate asynchronously with an external system. That is, the callout doesn't expect an immediate response from the external system. ## Overview of Capabilities Capabilities include: - In the JSON, includes the hierarchy of the order item or FRL. That is, it notes the parents and children of the item. - Can accept DataRaptors to change the default JSON payload. - Sends POST requests. - Processes the response and updates Salesforce records. - Is extendable. - Understands standard HTTP response codes: - Success codes: 200, 201, 202, 203, 204, 205, 206, 302, 304 - Error codes: 408, 426, 500, 502, 503, 504, 440, 444, 520, 522, 523, 524, 525 ## Sample Payload By default, **XOMAsyncSystemInterface** adapter prepares the following JSON payload, which is logged to the **Request** field of the orchestration item record. ``` { "order_items": [ { "order_item_id": "a1f3i000000UcNUAA0", "action": "Add", "specified_by": { "specification_name": "Mobile Billing specification", "specification_id": "01t3i000001NCngAAG" }, "described_by": [ { "value": "VLO_MOB_PLAN", "characteristic": "Billing code" } ], "order_items": [ { "described_by": [ { "value": "VLO_SIM", "characteristic": "Billing code" } ], "specified_by": { "specification_name": "Billing item", "specification_id": "01t3i000005LAQKAA4" }, "action": "Add", "order_item_id": "a1f3i000000UcNVAA0" }, ... ] } ], "account_id": "0013i00000OXjoVAAT", "order_id": "a1g3i000000t1RhAAI", "responseUri": "/services/apexrest/vlocity_cmt/asyncCallback/a2L3i000000DWUyEAO" } ``` ![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-ind-order_management-264-0-0-production-enus/c2040b01-aade-4ba7-8a7d-d7cd745d5c8c/images/icon_note.png) Note A callout can be linked to either a fulfillment request line (FRL) or an order item. For details about why that's the case, see [Orchestration Item Associations to Fulfillment Request Lines and Order Items](https://help.salesforce.com/s/articleView?id=ind.comms_t_orchestration_item_associations_to_fulfillment_request_lines_and_orderitems_231900.htm&release=264.0.0&type=5 "If an orchestration plan definition is associated with a technical product, its orchestration items are associated with a fulfillment request line. If an orchestration plan definition is associated with a commercial product, its orchestration items are associated with an order line item."). The payload uses the following parameters: - Each node within the `order_items` array represents a corresponding fulfillment request line (FRL) or order item. - `order_item_id` : the Salesforce record ID of the corresponding FR Line or Order Item. - `action` : The Action field for the corresponding FRL or order item. - `specified_by` : - `specification_name` : The name of the corresponding product specification. - `specification_id` : The record ID of the corresponding product specification. - `described_by` : Attribute values for the corresponding FRL or order item, with the following name-value pairs: - `characteristic` : attribute name - `value` : attribute value. Empty values aren't included in the payload. ![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-ind-order_management-264-0-0-production-enus/c2040b01-aade-4ba7-8a7d-d7cd745d5c8c/images/icon_note.png) Note The **Callout Parameters** field on the orchestration item, which configures the callout to send empty values, is ignored by **XOMAsyncSystemInterface**. That field is only respected by the synchronous adapters. - `order_items` : An array of child FRLs or order items. - `account_id` : The account record ID of the order. - `order_id` : Contains the ID of the corresponding fulfillment request (for callouts that link to FRLs), or the ID of the order (for callouts that link to order items). - responseURI : A predefined callback URL where the last part (ID) represents the orchestration item ID. ## Response Processing Acknowledgment Although **XOMAsyncSystemInterface** is designed to wait for a response, it expects the external system to send an HTTP code as an acknowledgment that it has received a request. - If the acknowledgment is one of the expected success codes (200, 201, 202, 203, 204, 205, 206, 302, or 30): The callout remains in the Running state. - If the acknowledgment is one of the expected error codes (408, 426, 500, 502, 503, 504, 440, 444, 520, 522, 523, 524, or 525): The callout moves to the Failed state, and is retried according to the retry policy. For information about retry policies, see: [Set Up Retry Policies for Failed Callouts](https://help.salesforce.com/s/articleView?id=ind.comms_t_set_up_retry_policies_for_failed_callouts_236868.htm&release=264.0.0&type=5 "You can create policies that control how Order Management retries failed callouts to fulfillment systems. You can design callout so that if it fails to connect to an external system, it retries that connection based on the policy that you set up.") - If the acknowledgment is any unexpected code: The callout moves to the Fatally Failed state and isn't retried again, regardless of the retry policy. Response Payload By default, responses are logged in the **Response** field of the FRL or order item. Then the adapter analyzes the response HTTP code, and completes or fails the callout accordingly. You can change where, or if, responses are stored (see [OM Standard: Configure Request and Response Storage in Custom Settings](https://help.salesforce.com/s/articleView?id=ind.comms_t_om_standardconfigure_request_and_response_storage_in_custom_settings_240602.htm&release=264.0.0&type=5 "The OrchestrationItemLog custom setting sets whether and where orchestration item requests and responses are stored. To reduce load on the database, you can set the custom setting to \"BigObject\" or \"Off\", or set a different value to store the information somewhere else.")). The response is validated against the following rules. If any of these conditions fail, then the callout fails: - The incoming ID points to the callout that made the request. - The callout is in the **Running** state. - The response doesn't contain the `errorCode` message. - The `order_id` name-value pair is present, and matches the Order Id associated with the callout. Failure - Callback Sample ``` PayloadJSON { "order_id": "801xx000003Gh2JAAS", "errorCode": "500", "errorMsg": "Downstream Failure" } ``` If an asynchronous callout fails, the fulfillment step transitions immediately to the Fatally Failed state because asynchronous callouts do not support automatic retries. The system populates the error message in the `ExecutionLog__c` field. Success - Callback Sample ``` PayloadJSON { "order_id": "801xx000003Gh2JAAS" } ``` When the callback is successful, the fulfillment step transitions to the Completed state.