Overview of document processing

With WebSphere Partner Gateway, you exchange business documents with your community participants. The purpose of exchanging these documents is to communicate information, which typically involves processing data and returning a result. When you receive data from a community participant, processing of that data generally occurs in the back-end system of your enterprise. WebSphere Partner Gateway is the point within the hub community through which messages to and from the enterprise are routed.

The enterprise is accessed through a back-end system to which WebSphere Partner Gateway connects.

Figure 1 shows how documents flow through the WebSphere Partner Gateway Enterprise and Advanced Editions. A participant sends a document to WebSphere Partner Gateway (the hub). WebSphere Partner Gateway receives the document and performs any actions that have been predefined (such as validating or transforming the document). WebSphere Partner Gateway then sends the document to a back-end application, where the document is processed.

Note: As indicated in the illustration, communication flows in the opposite direction too. The back-end application can generate a document and send it to the hub, which processes it and sends it on to the participant.
Figure 1. End-to-end document flow
This figure shows how WebSphere Partner Gateway receives a document from a participant and routes it to the back-end system of the Community Manager, where it is processed by a back-end application. The document can also originate from the back-end application, in which case WebSphere Partner Gateway routes it to the participant.

This guide focuses on the integration between the hub and the back-end application (the shaded part of the illustration).

Note: The information in this document applies to the WebSphere Partner Gateway Enterprise and Advanced Editions. WebSphere Partner Gateway - Express, a light-weight, easy-to-use B2B connectivity tool, differs from WebSphere Partner Gateway Enterprise and Advanced Editions. It provides a community integration solution (versus a gateway hub solution that WebSphere Partner Gateway Enterprise and Advanced Editions provide for a Community Manager). For information about WebSphere Partner Gateway - Express, refer to its User Guide.

The roles in the hub community

WebSphere Partner Gateway Enterprise and Advanced Editions have three types of participants--the Community Operator, Community Manager, and participants. A Community Operator is created automatically when WebSphere Partner Gateway is installed. The Community Operator is in charge of setting up the hub and creating the participants that will interact with the hub.

The Community Manager, which is typically the owner of the hub, is actually considered to be one of the participants of the hub. The Community Operator creates a profile for the Community Manager, providing the information necessary to allow the Community Manager to send documents to and receive documents from participants. (Note that only one Community Manager can be created.) When the hub sends documents to the back-end system, it uses the information (URL or JMS queue, for example) set up for the Community Manager. The Community Operator also creates profiles for participants, of which there can be many.

The hub configuration process

The hub administrator is the Community Operator user responsible for administering the hub. The hub administrator sets up the hub to send and receive business documents from the Community Manager and participants. To receive business documents from the Community Manager, the hub administrator creates the targets for the transports that the Community Manager will use to send documents. For example, if the Community Manager uses the file-directory and JMS transports, the Community Operator sets up a file-directory target and a JMS target for the Community Manager. Similarly, if participants will use the HTTP transport and the FTP transport, the Community Operator sets up an HTTP target and an FTP target for them.

Figure 2. Targets for the Community Manager and participants
This figure shows that two targets are set up to receive documents from the Community Manager back-end application--a JMS target and a file-directory target. Two targets are also set up to receive documents from participants--an HTTP target and an FTP target.

Gateways are created for the Community Manager and participants for each of the transports that they will use to receive business documents sent by hub.

Figure 3. Gateways to the Community Manager and participants
This figure shows that gateways are set up to send documents from the hub to the Community Manager back-end application as well as to participants.

As part of the hub configuration, the Community Operator establishes document flow definitions, which define characteristics of a document flow, such as:

When WebSphere Partner Gateway is installed, a set of document flow definitions is available for use. You can also add to the document flow definitions by creating your own definitions or by uploading definitions. For example, document flow definitions for a variety of RosettaNet PIPs are included as ZIP files on the installation medium. You can upload these files to make them available for use. If you are exchanging EDI files, you can import document flow definitions and associated maps from the Data Interchange Services client.

Consider the following example--a community participant sends an RNIF 2.0 message containing a RosettaNet PIP 3A4 purchase order document to the HTTP target of WebSphere Partner Gateway. The message is intended for the Community Manager. The Community Manager has a back-end system that processes purchase orders and expects to receive the purchase order, which essentially is the payload of the RNIF message sent by the participant. Before the participant connections in WebSphere Partner Gateway are set up, it is agreed that:

When Backend Integration packaging is used, WebSphere Partner Gateway-defined transport headers are added to the document to convey information helpful for the document exchange.

For the previous example, the Community Operator would upload the appropriate PIP package, which would set up the following document flow definitions for the exchange of RosettaNet PIP 3A4:

After the Community Operator establishes the document flow definitions, the Community Operator creates interactions for the document flow definitions. For example, the Community Operator might indicate that the RNIF/RosettaNet/3A4 document flow definition can come into the hub from a source.

The Community Operator (or the participants) select the appropriate B2B capabilities for the document exchange. In this example, the Community Manager would have the following B2B capability enabled:

The participant would have the following B2B capability enabled:

The Community Operator then creates connections between participants.

In the following illustration, the Community Operator has created profiles for the Community Manager and participant, has created targets for receiving documents and gateways for sending documents, has created the document flow definitions listed above, has set the B2B capabilities of the participant and Community Manager, and has created a connection between the two.

Figure 4. How a document flows to the back-end system
This figure shows how a RosettaNet document flows from a participant through the WebSphere Partner Gateway server and to the Community Manager back-end application.

For information on setting up the hub, refer to the Hub Configuration Guide.

Copyright IBM Corp. 2003, 2005