Overview

A document flow definition is made up of, at minimum, a package, a protocol, and a document flow. For some protocols, an activity, action, and signal can be specified. The document flow definitions specify the types of document that will be processed by WebSphere Partner Gateway.

Packaging refers to the logic that is required to package a document according to a specification, such as AS2. A protocol flow is the logic that is required to process a document that adheres to a certain protocol, such as EDI-X12. A document flow describes what the document will look like.

The following sections briefly describe the overall steps for setting up a document flow between the Community Manager and a participant.

Step 1: Make sure the document flow definition is available

Check to see whether a document flow definition exists (from the ones that are predefined with the system). If the flow does not already exist, you create it by uploading the necessary files, or by manually creating a custom definition.

As part of establishing the document flow definition, you can modify certain attributes. Attributes are used to perform various document-processing and routing functions, such as validation, checking for encryption, and retry count. The attributes you set at the document flow definition level provide a global setting for the associated package, protocol, or document flow. The attributes that are available vary, depending on the document flow definition. Attributes for EDI document flow definitions, for example, have different attributes from RosettaNet document flow definitions.

For example, if you specify a value for Time to Acknowledge on the AS package, it applies to all documents packaged with AS. (Time to Acknowledge specifies the amount of time to wait for an MDN (message disposition notification) acknowledgment before resending the original request.) If you later set the Time to Acknowledge attribute at the B2B capabilities level, that setting overrides the one set at the document flow definition level.

For attributes that can be set at all levels of the document flow definition, the values set at the document flow level take precedence over those set at the protocol level, and the attributes set at the protocol level take precedence over the package level.

You must have the document flow listed on the Manage Document Flow Definitions page before you can create interactions.

Step 2: Create interactions

Create interactions for the document flows that have been defined. The interaction tells WebSphere Partner Gateway which actions to perform on a document. For some exchanges, you need only two flows, one to describe the document that is received into the hub (from the participant or Community Manager) and one that describes the document that is sent from the hub (to the participant or Community Manager). However, if the hub is sending or receiving an EDI interchange that will be split into individual transactions or in which acknowledgments are required, you will actually create multiple interactions to perform the exchange.

Step 3: Create participant profiles, gateways, and B2B capabilities

Create participant profiles for the Community Manager and for community participants. Define gateways (which determine where documents will be sent) and B2B capabilities, which specify the documents the Community Manager and participants are capable of sending and receiving. The B2B capabilities page lists all the document flows that have been defined.

You can set attributes at the B2B capabilities level. Any attributes you set at this level override those set at the document flow definition level. For example, if you set Time to Acknowledge to 30 at the document flow definition level for AS package but then set it to 60 at the B2B capabilities level, the value of 60 is used. Setting an attribute at the B2B level lets you tailor the attribute to a specific participant.

You must have the profiles and B2B capabilities of the Community Manager and participants defined before you can create connections between them.

Step 4: Activate connections

Activate connections between the Community Manager and participants. The connections that are available are based on the B2B capabilities of the participants. The B2B capabilities are based on the interactions you created. The interactions depend on the document flow definitions being available.

For some exchanges, only one connection is required. For example, if a participant is sending a binary document to a Community Manager back-end application, only one connection is needed. For the exchange of EDI interchanges in which the interchange is de-enveloped and the individual transactions are transformed, however, multiple connections are set up.

Note: For EDI interchanges that are being passed through as is, only one connection is required.

You can set attributes at the connection level. Any attributes you set at this level override those set at the B2B attributes level. For example, if you set Time to Acknowledge to 60 for the AS2 package at the B2B capabilities level but then set it to 120, the value of 120 is used. Setting a value for an attribute at the connection level lets you further tailor the attribute, depending on the routing requirements of the participants and applications involved.

An example flow

By default, several packaging methods are enabled. To illustrate the overall procedure for establishing document flow definitions, consider the case in which you have an agreement with a community participant to receive an EDI interchange that adheres to the EDI-X12 standard. The participant will send the document in AS2 packaging. You will specify that the interchange be sent as is (without transformation) to a back-end application with no packaging.

  1. At the Manage Document Flow Definitions page, verify that the document flow definition (which describes the type of document that will flow into the hub from the community participant) is enabled.
    1. Click Hub Admin > Hub Configuration > Document Flow Definition.
    2. Click the Expand icon next to Package: AS. Notice that EDI-X12 is already listed.
    3. Click the Expand icon next to Protocol: EDI-X12. Notice that Document Flow: ISA is already listed.
  2. With the Manage Document Flow Definition page still displayed, verify the second document flow definition (which describes the type of document that will flow to the back-end application) is enabled.
    1. Click the Expand icon next to Package: None. Notice that EDI-X12 is already listed.
    2. Click the Expand icon next to Protocol: EDI-X12. Notice that Document Flow: ISA is already listed.
  3. Create an interaction that describes whether the document flow will be a source flow or a target flow.
    1. With the Manage Document Flow Definition page still displayed, click Manage Interactions.
    2. Click Create Interaction.
    3. In the Source column, expand Package: AS, Protocol: EDI-X12 (ALL), and then click Document Flow: ISA.
    4. In the Target column, expand Package: None, Protocol: EDI-X12 (ALL), and then click Document Flow: ISA.
    5. In this example, no transformation is occurring. Therefore, do not select anything from the Transformation Map list.
    6. From the Action list, select Pass Through.
    7. Click Save.

At this point, you have specified that the hub is capable of accepting EDI-X12 interchanges (ISA standard) packaged as AS. You have also specified that the hub is capable of sending EDI-X12 interchanges (ISA standard) with no packaging. Further, you have specified that no transformation is to occur with the interchange; it is simply passed through to the back-end application (after the AS headers are removed).

You have not yet specified which community participant is capable of sending this type of interchange to the hub. You define that when you set up the participant profile and the participant's B2B capabilities. (You also define a profile and B2B capabilities for the Community Manager back-end system.) After you perform these tasks, you then create a connection between the community participant and the back-end application. Figure 20 shows the connection between the participant and the Community Manager back-end application for this example.

Figure 20. A one-way connection from a participant to the Community Manager
This figure shows that one connection is required to send this document from the participant to the Community Manager back-end system

You verify that a connection exists using the Manage Connections page (Account Admin > Participant Connections). On the Manage Connections page, you select the participant from the Source list, Community Manager from the Target list, and click Search. The one available connection is listed. If necessary, you can modify attributes and actions, as will be described in subsequent sections.

There are three types of document flow definitions--ones supplied with the system that you can select from the console, ones that are already defined but not yet on the Community Console (you upload these definitions either from the WebSphere Partner Gateway installation medium or from another location), and those that you create yourself. For each type of document flow definition, you can (or sometimes must) specify attributes or upload maps that further define the document flow.

Copyright IBM Corp. 2003, 2005