Overview of creating document flows and setting attributes

A document flow definition is made up of, at minimum, a package, a protocol, and a document flow. The document flow definitions specify the types of documents 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. The sections also describe the points at which you can set attributes.

Step 1: Make sure the document flow definition is available

Before you can send or receive a document, a document flow definition must be defined for the document. WebSphere Partner Gateway provides several default document flow definitions, including ones that represent functional acknowledgments. When you import transformation maps for EDI transactions or XML or ROD documents, the associated document flow definitions appear on the Document Flow Definitions page. Similarly, if you import a functional acknowledgment map that is not already defined, the document flow definition for the acknowledgment appears on the Document Flow Definitions page. You can also create your own document flow definitions.

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 have different attributes from RosettaNet document flow definitions.

For example, if you specify a value for Allow a TA1 request at the ISA document flow level, the setting applies to all ISA documents. If you later set the Allow a TA1 attribute at the B2B capabilities level for a participant or the Community Manager, that setting overrides the one set at the document flow definition level.

For attributes that can be set at multiple 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. For example, if you specify an envelope profile at the &X44TA1 protocol level but specify a different envelope profile at the TA1 document flow level, the envelope profile you specify at the TA1 document flow level is used.

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

Step 2: Create interactions

You next set up interactions, which are templates for creating participant connections. Interactions convey how the document comes in, what processing is performed on the document, and how the document is sent from the hub.

For some protocols, 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 de-enveloped into individual transactions or in which acknowledgments are required, you will actually create multiple interactions. For example, if you are receiving an EDI interchange at the hub, you will have an interaction that describes how the interchange is sent to the hub and how it is processed at the hub. You will also have an interaction for each transaction within the hub that describes how the transaction is processed. For EDI interchanges leaving the hub, you will have an interaction that describes how the interchange envelope is sent to the recipient.

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

Next, you create participant profiles for the Community Manager and for community participants. You define gateways (which determine where documents will be sent) and B2B capabilities, which specify the documents the Community Manager or a participant is 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 Allow a TA1 request to No at the document flow definition level for ISA documents but then set it to Yes at the B2B capabilities level, the value of Yes is used. Setting an attribute at the B2B level lets you tailor the attribute to a specific participant.

If you set the envelope profile at the protocol or document flow level (on the Manage Document Flow definitions page) and then set it to a different value on the B2B Capabilities page, the latter value is used.

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

Finally, you activate connections between the Community Manager and participants. The connections that are available are based on the B2B capabilities of the participants and 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 Allow a TA1 Request to Yes at the B2B capabilities level but then set it to No at the connection level, the value of No 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.

Copyright IBM Corp. 2003, 2005