Overview for creating new senders

Senders are transport specific. WBI-C ships with senders for FTP/S, JMS, File, SMTP, and HTTP/S transports. To add a new capability to the WBI-C system, such as adding a WAP transport, users can write their own senders, using an API provided with the 4.2.2 release. These new senders can be associated with transports using the Community Console and integrated into the processing flow in the normal way. This section describes the process of developing a new sender. It covers:

The Sender/Sender Framework flow

The nature of processing flow on the sender side of WBI-C is in part dictated by the needs of the particular situation and transport, but there are basic tasks that must always be done. This section describes those tasks in a high level, general way.

1. Receive document
The business document to be processed is placed in the gateway input directory

2. Do pre-processing
The Sender Framework, a WBI-C internal component, is invoked, and its send method called. The Framework moves in order through its Console configured list of handlers until one, either Connect-delivered or user-defined, that can process the document is located. The document is processed.

3. Initialize the sender
The Framework calls the sender's init method.

4. Send the document
The Framework calls the sender's send method.
The sender creates a SenderResult object to store transmission and status information and sends the message, using the destination specified in the gateway, or, by preference, in the message itself, should it contain that information.

4A. Store response document
In the case of a synchronous request, the sender writes the response document to a file and sets the File object in the SenderResult object.

5. Do post-processing
The Framework moves through its Console configured list of handlers until an appropriate one, either Connect-supplied or user-defined, is located. The SenderResult object is processed.

8. Complete processing
The request document is removed from the gateway queue. In the case of a synchronous request, the response document is placed in a directory to be picked up for response processing.

Sender architecture

Sender development is based on two major parts: the sender itself, represented in the API by the SenderInterface interface and the Sender Framework, a Connect-supplied class that is responsible for managing the sender. The sender is responsible for actually sending the message to the destination, and for creating and initially populating the SenderResult object. In the case of a synchronous request, the sender also writes the response document to a file, and places a reference to the File object in the SenderResult object. The Framework is responsible for taking care of pre- and post-processing of documents and for instantiating and utilizing the sender.

Copyright IBM Corp. 2003, 2004