Message handling

This section describes how Business Integration Connect handles the following situations that impact the delivery of messages:

Queued delivery

Business Integration Connect posts information on all documents that it wants to send to a particular gateway into a queue. The Delivery Manager system processes these messages in the order the queue receives them (FIFO) and uses a thread for each message to send them. Note that if the gateway (for example, URL if the transport protocol is HTTP or JMS destination if the transport protocol is JMS) has been configured to be offline (see Communication error handling), the messages remain in the queue until the gateway is enabled (online). If the Delivery Manager receives an error in a thread, it stops other threads from attempting to deliver their messages. The Delivery Manager places these messages back into the queue until it is able to deliver the message that caused the error.

If the number of failed attempts exceeds the maximum number of attempts, the Document Manager places the message in a failed directory and then attempts to deliver the next message in the queue unless the gateway is offline.

Communication error handling

When Business Integration Connect is the sender and the application returns an error (for example, an HTTP Response message that is not a 200 or 202 message when using the HTTP protocol), Business Integration Connect may then retry to send the message again depending on how it has been configured for this particular gateway. Each gateway (URL in the case of HTTP) has the following options that affect the number of retries and how the messages are sent:

Table 12. Gateway configuration options

Configuration options Description
Retry Count How many document retries to attempt if an error is received
Retry Interval Time interval between retry attempts
Online/Offline Starts and stops delivery attempts
Number of Threads Number of posting threads that will process messages per gateway

If Business Integration Connect is not configured to retry sending the message or if all delivery attempts fail, Business Integration Connect signals the problem by doing any or all of the following actions:

See "Managing gateway configurations" in the Administrator Guide for more information.

Duplicate messages

All messages sent to or received from Business Integration Connect must have a Global Unique Identifier (GUID). Business Integration Connect uses the GUID to detect duplicate messages. When Backend Integration packaging is used, each message carries its GUID in the transport-level header. For the HTTP protocol, for example, the GUID is carried in the x-aux-system-msg-id field (see Transport-level header content). The sender of the message generates the GUID. The file system protocol does not support checking for duplicate messages.

If the attempt to send a message results in an error, Business Integration Connect reuses the message's GUID in each retry. If Business Integration Connect receives a message that contains a duplicate GUID, it returns a positive acknowledgment (for example, HTTP 200) but does not process the duplicate message.

Note:
Business Integration Connect checks for duplicate messages at the RosettaNet process level if RosettaNet is being used. It also checks for duplicate messages if XML is being used.

Copyright IBM Corp. 2003, 2004