Integration Server 10.3 | JMS Client Development Guide | Exactly-Once Processing for JMS Triggers | Summary of Duplicate Detection Process for JMS Triggers
 
Summary of Duplicate Detection Process for JMS Triggers
The following table summarizes the process Integration Server follows to determine a message’s status and the action the server takes for each duplicate detection method.
Step 1
Check Delivery Count
When a JMS trigger is configured to detect duplicates, Integration Server checks the message’s delivery count to determine if the JMS trigger processed the message previously. Specifically, Integration Server checks the value of the JMSXDeliveryCount property in the message.
Delivery Count
Action
1
If using document history, Integration Server proceeds to Step 2 to check the document history database.
If document history is not used, Integration Server considers the message to be New. Integration Server executes the trigger service.
>1
If using document history, Integration Server proceeds to Step 2 to check the document history database.
If document history is not used, Integration Server proceeds to Step 3 to execute the document resolver service.
If neither document history nor a document resolver service are used, Integration Server considers the message to be In Doubt.
-1 (Undefined)
If using document history, Integration Server proceeds to Step 2 to check the document history database.
If document history is not used, Integration Server proceeds to Step 3 to execute the document resolver service.
Otherwise, Integration Server considers the message to be New. Integration Server executes the trigger service.
Step 2
Check Document History
If a document history database is configured and the trigger uses it to maintain a record of processed messages, Integration Server checks for the message’s UUID in the document history database. If the message does not have a UUID, Integration Server uses the value of the JMSMessageID field from the message header.
UUID or JMSMessageID Exists?
Action
No
Message is New. Integration Server executes the trigger service.
Yes
Integration Server checks the processing status of the entry.
*If the processing status indicates that message processing completed, then Integration Server considers the message to be a Duplicate. Integration Server acknowledges the message but does not execute the trigger service.
*If the processing status indicates that processing started but did not complete, Integration Server considers the message to be In Doubt.
If provided, Integration Server proceeds to Step 3 to invoke the document resolver service. Otherwise, Integration Server considers the message to be In Doubt. Integration Server acknowledges the message but does not execute the trigger service.
Step 3
Execute Document Resolver Service
If a document resolver service is specified, Integration Server executes the document resolver service assigned to the trigger.
Returned Status
Action
NEW
Integration Server executes the trigger service and acknowledges the message.
DUPLICATE
Integration Server acknowledges the message but does not execute the trigger service.
IN_DOUBT
Integration Server acknowledges the message but does not execute the trigger service.
Notes:
*When a transacted JMS trigger fails because of a transient error and the document history database is configured and enabled, Integration Server considers the message to be New the next time it is received.
*When a transacted JMS trigger fails because of a fatal error and the document history database is configured and enabled, Integration Server rejects the message the next time it is received and generates a JMS retrieval failure event.
*When a transacted JMS trigger fails because of a fatal or transient error and the document history database is neither configured nor enabled, Integration Server does not send a JMS retrieval failure event the next time the message is received. Integration Server sends a JMS retrieval failure event if the maximum delivery count is eventually reached.