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.
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.
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.
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.
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).
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:
SOAP and cXML messages must use None packaging.
When HTTP or HTTPS messages are sent between WebSphere Partner Gateway and an application for asynchronous exchanges, the following steps occur:
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.
To send a message to WebSphere Partner Gateway using the HTTP protocol, a back-end system takes the following steps:
The Content-Type attribute in the transport-level header gives the encoding used for the message.
For Backend Integration packaging, the back-end system adds the protocol header attributes that WebSphere Partner Gateway requires.
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.
To receive a message from WebSphere Partner Gateway using the HTTP protocol, a back-end system takes the following steps:
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.
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.
To set up your JMS environment, the following providers are required.
A JMS provider provides the implementation of JMS API support for messaging. WebSphere MQ is an example of a JMS provider and is the one used in the procedures described in this and other WebSphere Partner Gateway documentation. While it is possible to use other JMS providers, note that WebSphere Partner Gateway has been tested only with WebSphere MQ. Note also that WebSphere Partner Gateway does not support the WebSphere 6.0 default messaging provider.
WebSphere MQ provides the JMSAdmin program, which lets you construct the objects required by JMS--the JMS connection factory and JMS queue objects. When these objects are constructed, references to them are stored in JNDI.
The JNDI provider supplies the implementation of JNDI, which is used to store references to JMS objects.
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.
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.
To send a message to WebSphere Partner Gateway using the JMS protocol, a back-end system takes the following steps:
For Backend Integration packaging, the application adds the required JMS header attributes.
To receive a message from WebSphere Partner Gateway using the JMS protocol, a back-end system takes the following steps:
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.
To send a message to WebSphere Partner Gateway using the file-system protocol, an application should take the following steps:
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.
To receive messages using the file system protocol, an application should do the following:
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.