1. Using B2B for Oracle Integration Generation 2
  2. Use B2B for Oracle Integration in Trading Partner Mode
  3. Outbound Message Processing

Outbound Message Processing

This section describes the high-level steps involved in processing an outbound B2B message.

The high-level steps involved in processing an outbound B2B message are as follows.
This diagram is described in the table below.

Step Description
1 Your backend application has a requirement to send a business transaction to an external trading partner. It triggers your outbound backend integration by sending it a notification message.
2 Your backend integration instance receives the notification that includes the application message in the backend application message format.
3 Using a mapper, the backend application message is transformed into a B2B canonical XML format.
4 The canonical XML message is provided to a B2B action for outbound translation (the action named EDI-Generate above). A trading partner is specified as an input to the B2B action. The B2B action translates the canonical XML message to a native EDI format (X12 or EDIFACT) and persists it in the Oracle Integration persistence store. A unique ID is assigned to it.
5 Based on the target trading partner, the current document type, and the outbound agreements defined for the trading partner, an appropriate B2B integration for sending messages is triggered. The message ID is handed to it.
6 The B2B integration for sending messages instance starts and receives the message ID at its REST Adapter trigger endpoint.
7 The B2B integration for sending messages instance uses an adapter (AS2 or FTP) to pack the message and then transmit it to the external trading partner through the AS2 or FTP protocol.

Design an Outbound Backend Integration

An outbound backend integration is triggered by a backend application. For sending a message to an external trading partner, this integration must know exactly which trading partner the message must go to. This is specified either directly or indirectly by the backend application in either of two ways:

  1. The trading partner's identifier is specified. It is the same identifier you entered when you created a new trading partner in B2B, displayed in the Primary Information page.

    or

  2. An application partner ID is specified. This is a type of B2B identifier you can add to a trading partner.

The idea behind the Application Partner ID is the following: the backend application and the B2B system both model the concept of a trading partner. A backend application may treat such a business entity in a specific role, such as a supplier, vendor, purchaser, and so on. The business entity is assigned a unique identification in the backend application. However, in B2B, you again register this entity as a B2B trading partner for message exchange purposes. Your suppliers, vendors, purchases are all treated the same: as B2B trading partners. At the hand-off point between the backend application and B2B, one of these systems must map between the backend application's entity ID and the B2B system's trading partner ID. The application partner ID is exactly for this purpose; it allows you to add the backend application's entity ID into the B2B system.

For this to work, add the Application Partner ID as a B2B identifier type to all of your trading partners. The value is the unique identification defined in your backend application. Once you define these, the B2B system knows how to look up a trading partner, given the value for Application Partner ID.

Step 3 specifies how you map the application partner ID element in the TranslateInput schema.

  1. Create the integration and configure the trigger connection.

    Depending on how you want a notification from the backend application to arrive, configure a trigger connection using an appropriate application adapter or a technology adapter.

    In our example, a simple REST Adapter trigger is used. Replace it with Oracle ERP Cloud Adapter, Oracle NetSuite Adapter, or another one.

  2. Place a B2B action with an outbound translate operation.
    1. Add a B2B action into the integration. The B2B action can be seen in the palette under Actions > Data.
    2. Enter a name (for this example, EDI-Generate is added). Click Next.
    3. Select Outbound as the direction and Translate as the operation. Click Next.
      The Select Operation page of the Configure B2B Action is shown. In the upper right corner, the Help, Back, Next, Cancel, and Done buttons are displayed. On the page, the Outbound message direction and Translate operation are selected.

    4. In the Select Data Formats page, select a document definition from the drop-down list for this backend Integration to handle. Click Next after you make the selection.

      Existing B2B documents are displayed in the drop-down list for selection. Alternately, click Search to select a B2B document by document standard, version, and type.The Select Data Formats page of the Configure B2B Action is shown. In the upper right corner, the Help, Back, Next, Cancel, and Done buttons are displayed. On the page, the Advance Ship Notice option is selected in the Document Definition list. To the right is the Search button. Below are details about the selected document definition.

    5. In the Summary Page, review your selections and then click Done.

      Your integration looks as follows.
      The integration shows a REST Adapter, a mapper, a B2B action, and a return icon.

  3. Configure the mapper to convert the application message to B2B canonical format.
    This mapping can be complex. Let us break it down into two parts.
    • In the first part, map an element to either B2B Trading Partner ID or Application Partner ID. These elements are used to specify the trading partner to which to send. This concept was explained earlier. In the example shown, only the B2B Trading Partner ID has been mapped.

      Also, optionally map Application Message ID. This is a message ID assigned by the backend application, if any. If this is mapped, the value is displayed in Monitoring > B2B Tracking > Business Messages in the details panel for any outbound message. Its value is not used during processing, but is stored and is displayed for your reference only.
      This image shows the source tradingPartnerId mapped to the target B2B Trading Partner ID.

    • The second part of the map is for edi-xml-document, which is the B2B canonical XML format for an EDI document, shown on the right-hand side of the map. On the left-hand side is your backend application schema for the business document. Because that schema is very specific to your backend application, the mappings from the backend application schema to the B2B canonical XML cannot be generalized.

      The following example maps a custom structure, an AcmePurchaseOrder to the edi-xml-document, which represents the canonical format for an EDI X12, 850, Purchase Order.
      The source AcmePurchaseOrder element's subelements are mapped to the target edi-xml-document's subelements.

  4. Add a check for successful EDI translation.
    1. Place a switch action after the B2B translate (that is, EDI-Generate) action. This action is for checking translation status to find if the EDI translation succeeded or failed.
      This image shows a REST Adapter trigger, a mapper, a B2B action, and a switch action with If and Otherwise branches.

    2. Add a route, called Translation Succeeded, and configure the following expression:
      translation-status = "Success" or translation-status = "Warning"

      The switch action shows the Inputs section on the left side. The View, Filter, and Detach elements are displayed. Below this is the Find field and Source icon. Below this is the Source section. The translation-status element has been selected. On the right is the Expression Name field, with a value of Translation Succeeded. Below this is the Match list with a value of Any of selected. Below this are entries for translation-status = "Success" and translation-status = "Warning."

  5. If translation is successful, prepare to deliver the document to the trading partner.
    1. Add a local integration invoke (that is, call an integration) action in the Translation Succeeded route.
    2. On the Select Integration page, select any available B2B Integration for sending messages (the exact name of such an integration varies, but the name always ends with AS2 Send or FTP Send). In the following example, the selected integration, Ext TP FTP Send (1.0) is a B2B integration for sending messages. While the selection must be a B2B integration for sending messages because of a specific API contract, it does not matter which specific trading partner it is, since this selection is overridden from the mapper as explained in Step c .
      The Select Integration tab of the Configure Local Integration Invocation wizard is shown. The fields shown are Integration (for selecting the integration to invoke), Identifier, and Description.

    3. Click Next several times, and then click Done. The Translation Succeeded route now looks as follows:
      The integration shows the B2B, a switch action with an IF branch, a mapper, and a notification action.

    4. Configure the mapper before the local integration invoke (that is, map to Send-To-Partner) as follows:
      • Map source TranslateOutput > B2B Message Reference to target components.schemas.request-wrapper > messages > b2b-message-reference.
      • Map source TranslateOutput > Trading Partner Name to target components.schemas.request-wrapper > trading-partner.
      • Map source TranslateOutput > connectivity-properties-code to target ConnectivityProperties > LocalIntegration > code.
      • Map source TranslateOutput > connectivity-properties-version to target ConnectivityProperties > LocalIntegration > version.
        The Source tree, Mapping Canvas, and Target tree of the mapper are shown. The source connectivity-properties-code element is mapped to the target code element.

      The mappings for ConnectivityProperties > LocalIntegration > code and version override the selection of an integration in Step 5(b)).

      Here's how the routing works:
      • The B2B action checks the trading partner's outbound agreements and finds one that matches the B2B document selected in step 2(d).
      • The transport linked to the outbound agreement is found.
      • Once the transport is known, the B2B integration for sending messages linked to the transport is also known. That's the integration to call for delivering the document to the trading partner. The B2B action populates the connectivity-properties-code and connectivity-properties-version with that integration's identifier and version.
      • If you have mapped the fields correctly, the local integration invoke (that is, calls an integration) action honors the mapper override and calls the integration specified in the connectivity-properties-code and connectivity-properties-version, instead of the one selected in Step 5(b).
  6. Add a return action for success and a fault for an error.
    1. Add a return action for the integration to return a successful response for the Translation Succeeded route and a fault return for the Otherwise route.

      This step is specific to the example selected with the REST Adapter trigger. Your case may vary. Depending on your backend application, there may or not be a mechanism to relay the outcome of a successful or a failed translation back into the backend application.

      The completed outbound integration looks as follows.
      This integration shows a REST Adapter trigger, a mapper, a B2B action, and a switch with branches for If and Otherwise. The If branch is taken if translation succeeds. The Otherwise branch is taken if translation fails. A return icon is at the far right side.

  7. Add B2B business identifiers for integration tracking.
    1. Select fields from the input schema for integration tracking to complete the integration. This is largely specific to your backend application schema. The tracking configuration for this example integration is as follows, but your integration can look different.
      The Business Identifiers For Tracking dialog is shown. In the upper left are the View, Filter, and Detach elements. Below this is the Source section, the Find field, and the Search icon. The orderNumber identifier is selected. On the right side is a table with columns for Primary, Tracking Field, Tracking Name, Tracking Variable, and Help Text. The orderNumber identifier is the only identifier listed.

    2. Save, and then activate the backend integration.

Design a Backend Integration to Handle Multiple Types of Documents

The detailed steps assume you create one backend integration for each document definition you want to handle. You may clone the integration for other document types because the basic pattern is identical.

Similar to an inbound backend integration, you may design a single integration that handles multiple document types by adding a switch action in your integration and specific routes for each document definition or trading partner and their own map and B2B translate action.