Duplicate Detection Methods for JMS Triggers

Integration Server ensures exactly-once processing by performing duplicate detection and by providing the ability to retry trigger services. Duplicate detection determines whether the current message is a copy of one previously processed by the trigger.

Duplicate messages can be introduced in to the webMethods system in the following situations:

The sending client sends the same message more than once.

When receiving persistent messages from the JMS provider, Integration Server and the JMS provider lose connectivity before the JMS trigger processes and acknowledges the message. The JMS trigger will receive the message again when the connection is restored.

Integration Server uses duplicate detection to determine the message’s status. The message status can be one of the following:

New. The message is new and has not been processed by the trigger.

Duplicate. The message is a copy of one already processed the trigger.

In Doubt. Integration Server cannot determine the status of the message. The trigger may or may not have processed the message before.

To resolve the message status, Integration Server evaluates, in order, one or more of the following:

Delivery count indicates how many times the JMS provider has delivered the message to the JMS trigger.

Document history database maintains a record of all persistent message IDs processed by JMS triggers that have an acknowledgment mode of CLIENT_ACKNOWLEDGE and for which exactly-once processing is configured.

Document resolver service is a service created by a user to determine the message status. The document resolver service can be used instead of or in addition to the document history database.

The steps that Integration Server takes to determine a message’s status depend on the exactly-once properties configured for the JMS trigger.

Note: For detailed information about exactly-once processing for messages received by JMS triggers, see Using webMethods Integration Server to Build a Client for JMS.