Designer 10.7 | webMethods Service Development Help | Working with webMethods Messaging Triggers | Exactly-Once Processing for webMethods Messaging Triggers | Configuring Exactly-Once Processing for a webMethods Messaging Trigger
 
Configuring Exactly-Once Processing for a webMethods Messaging Trigger
Configure exactly-once processing for a webMethods messaging trigger when you want the webMethods messaging trigger to process guaranteed documents once and only once. If it is acceptable for a trigger service to process duplicates of a document, you should not configure exactly-once processing for the webMethods messaging trigger.
Keep the following points in mind when configuring exactly-once processing:
*Integration Server can perform exactly-once processing for guaranteed documents only.
*You do not need to configure all three methods of duplicate detection. However, if you want to ensure exactly-once processing, you must use a document history database or implement a custom solution using the document resolver service.
A document history database offers a simpler approach than building a custom solution and will typically catch all duplicate messages. There may be exceptions depending on your implementation. For more information about these exceptions, see Publish-Subscribe Developer’s Guide. To minimize these exceptions, it is recommended that you use a history database and a document resolver service.
*If Integration Server connects to an 6.0 or 6.0.1 version of the webMethods Broker, you must use a document history database and/or a document resolver service to perform duplicate detection. Earlier versions of the webMethods Broker do not maintain a redelivery count. Integration Server will assign documents received from these webMethods Brokers a redelivery count of -1. If you do not enable another method of duplicate detection, Integration Server assigns the document a New status and executes the trigger service.
*Stand-alone Integration Servers cannot share a document history database. Only a cluster or a non-clustered group of Integration Servers can share a document history database.
*Make sure the duplicate detection window set by the History time to live property is long enough to catch duplicate documents but does not cause the document history database to consume too many server resources. If external applications reliably publish documents once, you might use a smaller duplicate detection window. If the external applications are prone to publishing duplicate documents, consider setting a longer duplicate detection window.
*If you intend to use a document history database as part of duplicate detection, you must first install the document history database component and associate it with a JDBC connection pool. For instructions, see Installing Software AG Products.
*To configure exactly-once processing for a webMethods messaging trigger
1. In the Package Navigator view of Designer, open the webMethods messaging trigger for which you want to configure exactly-once processing.
2. In the Properties view, under Exactly Once, set the Detect duplicates property to True.
3. To use a document history database as part of duplicate detection, do the following:
a. Set the Use history property to True.
b. In the History time to live property, specify how long the document history database maintains an entry for a message processed by this webMethods messaging trigger. This value determines the length of the duplicate detection window.
4. To use a service that you create to resolve the status of In Doubt messages, specify that service in the Document resolver service property.
5. Click File > Save.