Which message transport will you use?

When the back-end system and WebSphere Partner Gateway send messages to one another, each must use the same message-transport protocol. The message transport protocol defines the communication protocol in which the messages are sent.

WebSphere Partner Gateway communicates with a back-end system through its Backend Integration interface. Table 11 lists the transport protocols that this Backend Integration interface supports.

Table 11. Transport protocols supported by Backend Integration
Transport protocol For more information
HTTP or HTTPS HTTP transport protocol
File-system files File-system protocol
JMS JMS protocol

Table 12 shows which transport protocols are supported for the packaging types and business protocols when the hub is sending documents to the back-end system.

Table 12. Supported transport protocols from WebSphere Partner Gateway to back-end system
Packaging type Business protocol HTTP or HTTPS? JMS? File system?
Backend Integration RosettaNet (RNSC) Yes Yes No
Binary Yes Yes No
EDI (see Table 14 for information on EDI)
XML Yes Yes No
ROD Yes Yes No
None EDI (see Table 14 for information on EDI)
cXML only Yes No No
SOAP only Yes No No
Binary Yes Yes Yes
XML Yes Yes Yes
ROD Yes Yes Yes

Table 13 shows which transport protocols are supported for the packaging types and business protocols when the back-end system is sending documents to the hub.

Table 13. Supported transport protocols from back-end system to WebSphere Partner Gateway
Packaging type Business protocol HTTP or HTTPS? JMS? File system?
Backend Integration RosettaNet (RNSC) Yes Yes No
XML Yes Yes No
Binary Yes Yes No
ROD Yes Yes No
None XML only Yes Yes Yes
EDI (See Table 14 for information on EDI.
cXML only Yes No No
SOAP only Yes No No
Binary only No No No
ROD only Yes Yes Yes

Table 14 shows which transport protocols and packaging types are supported for various EDI, XML, and record-oriented data (ROD) documents.

Table 14. Supported transport protocols between WebSphere Partner Gateway and the back-end system for EDI
Packaging type Document HTTP or HTTPS JMS File system
Backend Integration Single interchange containing single transaction (such as an X12 850 transaction within an envelope) Yes Yes No
Single interchange containing multiple transactions (such as an X12 850 transaction and an X12 890 transaction within the same envelope) Yes Yes No
Multiple interchanges containing single transaction (such as two X12 envelopes within the same file, each of which contains a single transaction) Yes Yes No
Multiple interchanges containing multiple transactions (such as two X12 envelopes within the same file, each of which contains two or more transactions) Yes Yes No
EDI transaction (for example, an X12 850 transaction), which cannot be delivered by itself because a transaction must be within an EDI interchange No No No
Document (for example, XML) that is later transformed into an EDI transaction. Yes Yes No
None Single interchange containing single transaction Yes Yes Yes
Single interchange containing multiple transactions Yes Yes Yes
Multiple interchange containing single transaction Yes Yes Yes
Multiple interchanges containing multiple transactions Yes Yes Yes
EDI transaction (not supported; must have interchange envelope) No No No
Document (for example, XML) that is later transformed into an EDI transaction Yes Yes Yes

The previous tables list the transport protocols that are valid between the hub and the back-end system. The hub can use additional transport protocols to send documents to or receive documents from participants. For example, the hub can send a document to a remote FTP server by using the FTP Scripting transport. It can also receive documents using the FTP Scripting transport. The FTP Scripting transport, which is described in the Hub Configuration Guide, can be used to send and receive documents over the Internet but it must be used to send and receive documents from Value Added Networks (VANs).

HTTP transport protocol

To send messages using an HTTP protocol, WebSphere Partner Gateway uses HTTP/S 1.1. To receive messages from back-end systems, WebSphere Partner Gateway supports both HTTP/S version 1.0 and 1.1.

The HTTP message can include the integration packaging attributes. Whether these attributes are included depends on the packaging type associated with the participant connection, as follows:

Process

When HTTP or HTTPS messages are sent between WebSphere Partner Gateway and an application for asynchronous exchanges, the following steps occur:

  1. The source system (WebSphere Partner Gateway or the back-end system) posts an HTTP message to the target system using a specific URL.
  2. The target system receives the message and sends the protocol-level acknowledgment, HTTP 200 or 202, to signify the change in ownership. The source system ignores the body of this acknowledgment message. If an error occurs during this processing, the target system sends an HTTP 500 message back to the source system.
  3. If WebSphere Partner Gateway is the target system (that is, when WebSphere Partner Gateway receives a message), it then persists the message and releases the connection to the source system.
  4. The target system can then process the message asynchronously.

When the exchange is synchronous (for example, for a SOAP or cXML document), a response is returned along with the HTTP 200 message in the same HTTP connection.

Sending messages from the back-end system using the HTTP protocol

To send a message to WebSphere Partner Gateway using the HTTP protocol, a back-end system takes the following steps:

  1. Creates the message.

    The Content-Type attribute in the transport-level header gives the encoding used for the message.

  2. Packages the message according to the packaging type set for the connection.

    For Backend Integration packaging, the back-end system adds the protocol header attributes that WebSphere Partner Gateway requires.

  3. Posts the message to the URL that WebSphere Partner Gateway uses to receive these messages.
  4. If the exchange is synchronous, the back-end system waits to receive a response in the same connection that was used for the request.

To enable HTTP message exchange in this direction, use the Target Details page of the Community Console to set up a target at the hub for inbound documents. This target specifies a URL. The back-end system needs to know this address to send documents to the hub.

Receiving messages at the back-end system using the HTTP protocol

To receive a message from WebSphere Partner Gateway using the HTTP protocol, a back-end system takes the following steps:

  1. Listens for a message at a particular URL.
  2. When a message is received, processes the message:
  3. If the exchange is synchronous, the back-end system returns a response in the same connection used for the request.

To enable HTTP message exchange in this direction, use the Gateway page of the Community Console to set up a gateway that specifies where documents should be delivered to the back-end system.

JMS protocol

The JMS protocol is based on the Java(TM) Message Service (JMS) and transfers messages through transactional, persistent JMS queues provided by, for example, IBM WebSphere MQ. The JMS protocol supports the following JMS message types:

In the JMS protocol, one system sends a JMS message to another. After the second system receives the message, it removes it from the queue. From this point forward, the receiving system can process the message asynchronously.

The JMS message can include integration packaging attributes. Whether these attributes are included depends on the packaging type associated with the participant connection, as follows:

With the exception of binary messages, WebSphere Partner Gateway supports sending and receiving JMS messages with either type of packaging. Binary messages received from an application must have the Backend Integration packaging. The reverse is not true because WebSphere Partner Gateway supports sending binary messages to the application using either type of packaging.

Setting up the JMS environment using WebSphere MQ

To set up your JMS environment, the following providers are required.

For a back-end application to send business documents to WebSphere Partner Gateway using the JMS protocol, a JMS target must be configured. The JMS target receives messages from a JMS queue, and the documents are introduced into the WebSphere Partner Gateway workflow. The JMS target configuration includes the required parameters for accessing the JNDI as well as the names of JMS objects. For integration with the back-end system, the queue configured in the JMS target is the queue from which the back-end system is sending the JMS message.

Similarly, a JMS gateway is used by WebSphere Partner Gateway to send business documents to a queue where participants expect to receive them. Therefore, for sending messages to the back-end system, make sure a JMS gateway is configured in the profile of the Community Manager. The gateway should be configured to send to the queue on which the back-end system is receiving. The JMS gateway configuration includes the required parameters to access the JNDI as well as the names of JMS objects.

Overview of using WebSphere MQ to set up the JMS environment

To communicate over the JMS transport protocol, WebSphere Partner Gateway and the back-end system require a JMS queue for each direction of the communication. Therefore, you must take the following steps to supply the appropriate JMS queues:

The JMS queue manager can exist on any computer, including the following:

In addition, you can have a queue manager on both the computer where the back-end system resides and the computer where WebSphere Partner Gateway resides. In this case, use setup channels to tie the two queue managers together. Using this method, neither side needs to make client connections over the network.

Instructions for configuring a JMS transport-protocol mechanism using WebSphere MQ version 5.3 are provided in the Hub Configuration Guide.

Sending messages from the back-end system using the JMS protocol

To send a message to WebSphere Partner Gateway using the JMS protocol, a back-end system takes the following steps:

  1. Creates the message.
  2. Packages the message according to the packaging type set for the connection.

    For Backend Integration packaging, the application adds the required JMS header attributes.

  3. Sends the message to the JMS queue that the back-end system uses to send messages to WebSphere Partner Gateway.

Receiving messages at the back-end system using the JMS protocol

To receive a message from WebSphere Partner Gateway using the JMS protocol, a back-end system takes the following steps:

  1. Listens for a message on the JMS queue.
  2. When a message is received, processes the message:

File-system protocol

The File System protocol enables WebSphere Partner Gateway to send messages by placing them in a defined directory structure. WebSphere Partner Gateway receives messages by reading them from the directory structure. The file-system protocol supports only the None packaging type.

Sending messages from the back-end system using the file-system protocol

To send a message to WebSphere Partner Gateway using the file-system protocol, an application should take the following steps:

  1. Create the message file in a temporary directory.
  2. Once the file is ready, move the file to the directory that WebSphere Partner Gateway polls.

To enable file-system message exchange in this direction, use the Target Details page of the Community Console to set up a target for inbound documents. The target of the message determines the directory that WebSphere Partner Gateway polls. When you create a target, WebSphere Partner Gateway creates a Documents directory and its subdirectories for the target, as follows:

<doc_root>
    Documents
        Production
        Test
      <other destination types>

WebSphere Partner Gateway polls the Documents directories and their subdirectories regularly to detect message files. If it finds a message, WebSphere Partner Gateway persists the message and then deletes the message from the directory. WebSphere Partner Gateway then processes the message normally. See the Hub Configuration Guide for information on how to create a target.

Receiving messages at the back-end system using the file-system protocol

To receive messages using the file system protocol, an application should do the following:

  1. Poll the appropriate directory for message files.
  2. When there is a message, persist it.
  3. Delete the message from the directory.
  4. Process the message.

To enable file-system message exchange in this direction, use the Gateway page of the Community Console to set up a gateway that specifies where documents should be delivered. WebSphere Partner Gateway places the message file in the Documents directory, which the gateway defines. By defining the destination directory according to the gateway, each participant connection can have a different directory. For information on gateways, see the Hub Configuration Guide.

Copyright IBM Corp. 2003, 2005