IBM FileNet P8, Version 5.2.1            

About Web Services-ReliableMessaging

While most uses of web services find the standard messaging mode adequate for their purposes, some applications require a mechanism to ensure that a request for a web service reached its intended target, or that a response from a web service reached the original requesting application.

PO standard messaging

The illustration above shows the standard messaging mode for most web service requests. For a one-way request, the client sends a single message to the destination web service. For a request with an expected response, there is one message to invoke the web service, and a reply message from the web service to the client. FileNet® processes created using P8 version 3.x use this standard messaging mode.

WS-ReliableMessaging specification provides a protocol to ensure that messages are received by the destination according to some criteria—at least once, at most once, exactly once, or in order. To achieve the reliability, a request message is sent repeatedly until the destination acknowledges receipt of the message or a timeout expires.

Web Services-ReliableMessaging

In the illustration above, the Invoke system function sends a request specified for WS-ReliableMessaging. The Reliable Messaging Source and Reliable Messaging Destination manage the messages between the client and destination, sending each message until the intended recipient replies with the appropriate acknowledgement message. For a successful one-way request, a minimum of five messages are exchanged; for a request with an expected response, ten messages are exchanged.

Notes® for using WS-ReliableMessaging

A goal of reliable messaging is to enable delivery of messages between a client and a web service even in the event of hardware and software failures on either side. The current implementation utilizes memory queues to store the Reliable Messaging messages. Therefore, in the event of a server failure, the information is lost.

Manage problems in reliable messaging requests

With a successful web service request, the end user does not notice the difference between a request sent with standard messaging and one sent with reliable messaging..

When using WS-ReliableMessaging, most problems ultimately result in a timeout. IBM recommends using the fault handling functionality in the Invoke system function to specify a string data field to catch any fault messages. If a non-application fault occurs, regardless of the cause of the fault, the reliable messaging status information is appended to the fault message, and the work item goes to a predefined submap for appropriate processing.

The specific fault that is related to the Reliable Messaging inactivity timeout is  orgorg.apache.axis.AxisFault with this message -       Inactivity Timeout Reached, No Response from the Server

For a list of the states and a description of the fault messages see WS-ReliableMessaging states.

Timeout for messages and requests

In the case of standard messaging, only one message is sent for each request. The inactivity timeout for standard messaging is set to five minutes.

For each reliable messaging request, each message is sent repeatedly until the expected acknowledgement message arrives or the inactivity timeout expires. Each message is subject to the inactivity timeout.

There are two types of inactivity timeouts that can occur during a web service message sequence:

Even if the request timeout is set to 25 minutes; it does not mean that the request waits until the time is up before it times out. The request times out if any of the messages reaches the message inactivity timeout. For example, if the first message sent, the Create Sequence Request message, reaches the message inactivity timeout, then a fault is generated and the request times out as well. Another example: the request successfully reaches the web service and it is waiting for the synchronous response. If the response never arrives, the request times out when the request timeout expires.

The user can set the message inactivity timeout to a much longer time period to achieve the purpose of "guaranteed delivery." Since each outgoing message is sent multiple times until the corresponding message it is waiting for arrives or until the inactivity timeout time expires, a longer inactivity message timeout can allow the destination web service a chance to recover from failure, receive messages, and respond back.

The inactivity timeout for messages can be configured in Process Task Manager under Component Manager, Web Services on the Reliable Messaging Settings tab. The WS-ReliableMessaging inactivity timeout value has no effect on the standard messaging timeout value.

Retransmission

When an outgoing message is sent repeatedly, it is re-sent at a specified retransmission interval. The base retransmission interval is set to three seconds (default), and the interval is increased each time the message is retransmitted. That is, the same outgoing message is sent less and less frequently.

The retransmission interval can be configured in Process Task Manager under Component Manager, Web Services on the Reliable Messaging Settings tab.

User-defined timeout for Invoke

In addition to the message and request timeout limits, the workflow author can specify a timeout (workflow system timeout) in the Invoke step. This timeout value can be longer or shorter than the request inactivity timeout. If the workflow system timeout is reached before the request times out, the work item goes to the user specified timeout map. If the request times out before the workflow system timeout is reached, a fault is generated. If the Invoke is designed to catch the fault, then the fault message will be stored in a user specified string data field and the work item moves to the map specified for the fault.



Last updated: March 2016
bpfdh010.htm

© Copyright IBM Corporation 2016.