How EDI interchanges are processed

An EDI interchange received at the hub is typically de-enveloped, and the individual transactions are processed. Often, standard EDI transactions (such as the X12 850 or the EDIFACT ORDERS, which represents a purchase order) are transformed into a form that can be understood by a back-end application. In addition, a functional acknowledgment is often sent to the participant to indicate that the interchange was received. The exchange of EDI interchanges, therefore, requires multiple actions (such as EDI De-envelope and EDI Translate and EDI Validate). For example, if the interchange contains two transactions and no acknowledgments are required, WebSphere Partner Gateway performs the following actions:

  1. De-envelopes the interchange

    WebSphere Partner Gateway extracts information about the interchange from the envelope header and trailer segments at the interchange, group, and transaction levels. This information can include:

  2. Transforms the first transaction according to the map associated with it.
  3. Transforms the second transaction according to the map associated with it.
  4. Delivers the transformed documents to the back-end application.

Similarly, when the hub sends a document or documents that originated at the Community Manager back-end application, the documents are transformed into standard EDI transactions. The resulting EDI transactions are enveloped before being sent to the participant. As in the case of receiving an EDI interchange, multiple actions are required to create, envelope, and send an EDI interchange.

The individual transactions, groups, and interchanges are identified by control numbers. WebSphere Partner Gateway sets these numbers when an exchange takes place. You can customize the control numbers, however, as described in Control numbers.

The following illustration shows the overall picture of how an EDI interchange, packaged as AS, is sent from a participant, with the eventual goal of delivering two transformed XML documents to two different gateways on the Community Manager back-end system. In this example, the 850 transactions are transformed into purchase orders that a back-end application can process. The 890 transactions are transformed in warehouse shipping orders that the back-end application can process.

Figure 30. Overall flow from a participant to the Community Manager
This figure shows how an EDI interchange, sent from the participant with AS packaging, is transformed into XML documents and sent to two different gateways of the Community Manager

Instead of requiring one connection from participant to Community Manager, this exchange requires three connections:

You can use the Document Viewer to view the interchange and the individual transactions, which, in the terms of the Document Viewer, are the children of the interchange. Using the Document Viewer, you can display the children associated with a source or target interchange, and you can display the events associated with them. The Document Viewer is described in the "Viewing Events and Documents" section of the Administrator Guide.

If the sender requests acknowledgments, you need additional connections:

Copyright IBM Corp. 2003, 2005