Introduction

WebSphere Data Interchange integrates electronic data interchange (EDI) into the WebSphere business process, messaging, and Internet-based B2B capabilities. You exchange documents and messages between WebSphere Partner Gateway and WebSphere Data Interchange through the JMS transport protocol. You must specify a packaging of None when sending a document to WebSphere Data Interchange.

Note: WebSphere Data Interchange provides other types of integration options, such as file-based integration. Refer to the WebSphere Data Interchange documentation for details on enabling the exchange of documents through file-based integration.

How documents are sent to WebSphere Data Interchange

For WebSphere Partner Gateway to send an EDI document to WebSphere Data Interchange, the following steps occur:

  1. A community participant sends an EDI document to WebSphere Partner Gateway. The document is sent with a specific packaging over a transport protocol (in this example, AS2 packaging over HTTP). WebSphere Partner Gateway strips off the AS2 packaging from the EDI document.
  2. WebSphere Partner Gateway places the EDI document on a queue.
    Note: WebSphere Partner Gateway determines the protocol used in the document by examining the first three characters of the EDI document. It then determines, from the protocol type, the sender and receiver information. See Overview of EDI routing for details.
  3. WebSphere Data Interchange reads the EDI document from the queue. It performs the tasks of unwrapping, validating, and translating the EDI document.
    Note: WebSphere Data Interchange must be configured with the necessary maps, trading partner profiles, and other information. See the WebSphere Data Interchange documentation for details.
  4. WebSphere Data Interchange distributes the document to a back-end system. If the back-end system is WebSphere InterChange Server, WebSphere Data Interchange sends the document to the WebSphere Business Integration Adapter for MQ to create a business object and invoke a collaboration within InterChange Server.
Figure 27. EDI document from WebSphere Partner Gateway
This figure shows a document, sent over AS2, arriving at WebSphere Partner Gateway and being sent, via a queue, to WebSphere Data Interchange.

In Figure 27, a community participant sends an EDI document in AS packaging to WebSphere Partner Gateway, which, in turn, sends it to the EDI_IN queue on the WebSphere Data Interchange side. Note that the remote queue, transmission queue, receiver queue (in the example, EDI_IN), and the sender and receiver channels must be set up so that the message sent to WebSphere Partner Gateway is transmitted to the EDI_IN queue. The WebSphere Data Interchange server picks up the EDI document, searches for the user profiles, mappings, and so on, converts the document to XML, and puts it in the XML_OUT queue.

How documents are received from WebSphere Data Interchange

For WebSphere Partner Gateway to receive an EDI document from WebSphere Data Interchange, the following steps occur:

  1. WebSphere Data Interchange places the EDI document on a queue.
  2. WebSphere Partner Gateway reads the message from the queue.
    Note: WebSphere Partner Gateway determines how to route the document as described in Overview of EDI routing.
  3. WebSphere Partner Gateway routes the document to the appropriate community participant.
Figure 28. Sending an EDI document to WebSphere Partner Gateway
This figure shows an XML  document received by WebSphere Data Interchange that is transformed into EDI and sent, via a queue, to WebSphere Partner Gateway, which delivers the document to a participant over AS2.

In Figure 28, an XML document is placed into the XML_IN queue for WebSphere Data Interchange to translate. It is assumed that the user profiles, mappings, and so on, are already performed. Upon receiving a valid XML document, WebSphere Data Interchange converts it into EDI format and places the output in the EDI_OUT queue (a remote queue). It is also assumed that the transmission queue, sender and receiver channels, and receiver queue on the WebSphere Partner Gateway side are set up. Upon receiving the document, WebSphere Partner Gateway routes it to the community participant.

Example scenario used in this chapter

Throughout this chapter, you will see the steps to set up the exchange of EDI documents between two trading partners. The EDI documents are sent over the internet, and AS2 (over HTTP) is used as the communication protocol.

In this sample, the trading partners are Partner One and Partner Two. Figure 29 illustrates the configurations of the two partners.

Figure 29. Configuration of two partners in example scenario
This figure shows that Partner One has two computers, one with WebSphere Partner Gateway installed and one with WebSphere Data Interchange installed, and that Partner Two has WebSphere Partner Gateway - Express installed.

The three computers have the following software installed:

Refer to the WebSphere Partner Gateway Installation Guide and to the WebSphere Data Interchange documentation for a complete list of software prerequisites.

In this example, partnerOne is operating two computers. Computer A has both WebSphere MQ and WebSphere Data Interchange Server installed. Computer B has WebSphere MQ as well as WebSphere Partner Gateway Enterprise Edition installed. Computer B supports the communications between the two trading partners.

WebSphere Data Interchange supports integration with WebSphere MQ, enabling interoperation with a wide range of enterprise applications and business process engines. WebSphere Partner Gateway employs WebSphere MQ as a JMS provider. As such, integration between WebSphere Data Interchange and WebSphere Partner Gateway is through MQ messages destined for JMS API clients.

WebSphere Partner Gateway is used to communicate EDI transactions over the Internet using the AS2 protocol.

Note that, in this example, partnerTwo is using WebSphere Partner Gateway - Express to accept transactions via AS2 and has its own WebSphere Data Interchange environment for handling translations and acknowledgments.

Throughout this chapter, you will see the details about configuring the computers used in this sample scenario. The flow of messages is bi-directional, and so both send and receive artifacts are included.

Copyright IBM Corp. 2003, 2005