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:
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:
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.
Instead of requiring one connection from participant to Community Manager, this exchange requires three connections:
For the transactions, the source packaging is not applicable because the transactions came in the original interchange that was de-enveloped by the system. Therefore, the source side of the transactions should have Packaging: N/A specified in the participant connection.
For the transaction that is transformed into XML and that will flow to the back-end application over JMS, the target gateway on the participant connection of this transaction should be specified as the JMS gateway of the Community Manager. For the transaction that was transformed into XML and that will flow to the back-end application over HTTP, the target gateway on the participant connection of this transaction should be specified as the HTTP gateway.
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: