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.

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.
   2. Enter a name (for this example, EDI-Generate is added). Click Continue.
   3. Select Outbound as the direction and Translate as the operation. Click Continue.
   4. In the Select Data Formats page, select a document definition from the drop-down list for this backend Integration to handle. Click Continue 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.

   5. In the Summary Page, review your selections and then click Finish.
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.

   • 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.
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.
   2. Add a route, called Translation Succeeded, and configure the following expression:

      translation-status = "Success" or 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 .
   3. Click Continue several times, and then click Finish.
   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 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.

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.
   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.