Building Your Event-Driven Architecture : Service Development Help : Properties : JMS Trigger Properties : Exactly Once Processing Properties
Exactly Once Processing Properties
You can configure exactly-once processing for a JMS trigger. Exactly-once processing ensures that a trigger processes a persistent message once and only once.
Integration Server provides exactly-once processing by determining whether a message is a copy of one previously processed by the trigger. Designer provides three duplicate detection methods: redelivery count, document history, and a document resolver service.
In the Properties view, under Exactly once, you configure exactly-once processing for a JMS trigger.
Property
Description
Detect duplicate
Enables exactly-once processing for the JMS trigger and instructs the server to check a message’s redelivery count to determine whether the trigger has received the message before.
Select...
To...
True
Specifies that exactly-once processing is provided for messages received by this trigger and instructs the server to check a document’s redelivery count to determine whether the trigger received the document previously.
The redelivery count indicates the number of times the routing resource has redelivered a document to the trigger.
False
Specifies that exactly-once processing is not provided for messages received by this trigger.
Note:  
Integration Server provides exactly-once processing for guaranteed messages only.
Use history
Indicates whether a document history database will be maintained and used to determine whether a message is a duplicate.
Select...
To...
True
Indicates that Integration Server maintains a history of messages processed by the trigger. When the trigger receives a message, the Integration Server compares the message’s universally unique identifier (UUID) to the UUIDs of messages processed by the trigger. If there is a match, the Integration Server either determines the second message is a duplicate and discards it or, if the first message has not finished processing, marks the second message’s status as In Doubt.
False
Indicates Integration Server does not maintain a document history database. The Integration Server will not use document history to determine whether a message is a duplicate of one already processed by the trigger.
Note:  
To perform duplicate detection using a document history database, the audit subsystem must be stored in a relational database and the Integration Server Administrator must define a JDBC connection pool for the Integration Server to use to connect to the document history database.
History time to live
Specifies the length of time the document history database maintains an entry for a message processed by the JMS trigger. During this time period, the Integration Server discards any messages with the same universally unique identifier (UUID) as an existing document history entry for the trigger. When a document history entry expires, the Integration Server removes it from the document history database. If the trigger subsequently receives a message with same UUID as the expired and removed entry, the server considers the copy to be new because the entry for the previous message has been removed from the database.
Document resolver service
Specifies the service that you created to determine whether message’s status is New, Duplicate, or In Doubt. Click to select a service from a list.
The document resolver service must use the pub.publish:documentResolverSpec to define the service signature.
Copyright © 2016 - 2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback