Integration Server 10.3 | Publish-Subscribe Developer’s Guide | Working with webMethods Messaging Triggers | About Message Processing | Serial Processing | Serial Processing in a Cluster or Non-Clustered Group of Integration Servers | Serial Processing with the webMethods Broker in a Clustered or a Non-Clustered Group of Integration Servers
 
Serial Processing with the webMethods Broker in a Clustered or a Non-Clustered Group of Integration Servers
To ensure that a serial webMethods messaging trigger processes guaranteed documents from individual publishers in publication order, the webMethods Broker distributes documents from one publisher to a single server in a cluster or non-clustered group. The webMethods Broker continues distributing documents from the publisher to the same server as long as the server contains unacknowledged documents from that publisher in the trigger queue. Once the server acknowledges all of the documents from the publisher to the webMethods Broker, other servers in the cluster or non-clustered group can process future documents from the publisher.
For example, suppose that a cluster contains two servers: ServerX and ServerZ. Each of these servers contains the webMethods messaging trigger processCustomerInfo. The processCustomerInfo webMethods messaging trigger specifies serial document processing with a capacity of 2 and a refill level of 1. For each publisher, the cluster must process documents for this webMethods messaging trigger in the publication order. In this example, the processCustomerInfo trigger client queue on the webMethods Broker contains documents from PublisherA, PublisherB, and PublisherC. PublisherA published documents A1 and A2, PublisherB published documents B1, B2, and B3, and PublisherC published documents C1and C2.
The following illustration and explanation describe how serial document processing works in a clustered environment that uses webMethods Broker as the messaging provider.
Serial processing in a cluster of Integration Servers
Step
Description
1
ServerX retrieves the first two documents in the queue (documents A1 and B1) to fill its processCustomerInfo trigger queue to capacity. ServerX begins processing document A1.
2
ServerZ retrieves the documents C1 and C2 to fill its processCustomerInfo trigger queue to capacity. ServerZ begins processing the document C1.
Even though document B2 is the next document in the queue, the webMethods Broker does not distribute document B2 from PublisherB to ServerZ because ServerX contains unacknowledged documents from PublisherB.
3
ServerX finishes processing document A1 and acknowledges document A1 to the webMethods Broker.
4
ServerX requests 1 more document from the webMethods Broker. (The processCustomerInfo webMethods messaging trigger has refill level of 1.) The webMethods Broker distributes document B2 from PublisherB to ServerX.
5
ServerZ finishes processing document C1 and acknowledges document C1to the webMethods Broker
6
ServerZ requests 1 more document from the webMethods Broker. The webMethods Broker distributes document A2to ServerZ.
ServerZ can process a document from PublisherA because the other server in the cluster (ServerX) does not have any unacknowledged documents from PublisherA. Even though document B3 is the next document in the queue, the webMethods Broker does not distribute document B3to ServerZ because ServerX contains unacknowledged documents from PublisherB.
Notes:
*The webMethods Broker and Integration Servers in a cluster cannot ensure that serial webMethods messaging triggers process volatile documents from the same publisher in the order in which the documents were published.
*When documents are delivered to the default client in a cluster, the webMethods Broker and Integration Servers cannot ensure that documents from the same publisher are processed in publication order. This is because the Integration Server acknowledges documents delivered to the default client as soon as they are retrieved from the webMethods Broker.