Overview for creating handlers in fixed inbound workflow

Before incoming messages can be dealt with, all packaging and protocol specific information with which they are bundled must be extracted and processed. The first two steps in the fixed inbound workflow are designed to accomplish these tasks. WBI-C ships with code to handle RNIF, AS2, MIME, EAI, and NONE packaging and XML, RosettaNet, and EDI protocols. To add new packaging types or to support new protocols, users can write their own handlers, using an API, the BusinessProcessHandlerInterface, provided with this release. These new handlers must be configured using the Community Console and integrated into the processing flow in the normal way. For more on the configuration process, see the Hub Configuration Guide. This section provides a functional overview of the two user customizable steps in the fixed inbound workflow process. It covers:

Protocol unpackaging handlers

Received messages in the BPE are wrapped in an object that implements the BusinessDocumentInterface. This wrapper object, often simply called the business document, contains both the received message, including the transport level and WBI-C defined headers added during the Receiver process, and a variety of metadata associated with the message. BPE uses this metadata in its processing. The first step in fixed processing consists of un-packaging or de-enveloping the business document. This may include any or all of the following steps:

Decryption
If the message is encrypted

Decompression
If the message is compressed

Signature verification
If the message is signed

Routing information extraction

User authentication
If the packaging provides user information

Business document parts extraction
If the packaging specifies location of various message parts such as payload, attachments, and so forth.

Note: To support decryption and signature verification in user-defined handlers, there are security service utility classes available through the API.

When it is complete, this step produces the un-packaged message. In addition, the handler must update the meta information in the business document in the following ways:

Protocol processing handlers

After business documents are processed by any un-packaging handlers, they are handed off to the second fixed step, the protocol processing handler. This handler is responsible for parsing the business document to determine:

Routing information
Sender ID and Destination ID

Protocol information
The business protocol and version associated with this business document. Example: Rosettanet version V02.02

Document flow/process information
The document flow and version associated with this business document. Example: 3A4 version V02.02.

Once this information is determined, the handler must update the meta information in the business document in the following ways:

Copyright IBM Corp. 2003, 2004