webMethods 10.2 | Service Development Help | Working with webMethods Messaging Triggers | About Transient Error Handling for a webMethods Messaging Trigger | Handling Retry Failure | Overview of Suspend and Retry Later for Retry Failure
 
Overview of Suspend and Retry Later for Retry Failure
Suspending a webMethods messaging trigger and retrying the trigger service later when retry failure occurs provides a way to resubmit the document programmatically. It also prevents the webMethods messaging trigger from retrieving and processing other documents until the cause of the transient error condition has been remedied. This preserves the publishing order, which can be especially important for serial webMethods messaging triggers.
The following table provides more information about how the Suspend and retry later option works.
Step
Description
1
Integration Server makes the final retry attempt and the trigger service fails because of an ISRuntimeException.
2
Integration Server suspends document processing and document retrieval for the webMethods messaging trigger temporarily.
The webMethods messaging trigger is suspended on this Integration Server only. If the Integration Server is part of a cluster, other servers in the cluster can retrieve and process documents for the webMethods messaging trigger.
Note: The change to the webMethods messaging trigger state is temporary. Document retrieval and document processing will resume for the webMethods messaging trigger if Integration Server restarts, the webMethods messaging trigger is enabled or disabled, or the package containing the webMethods messaging trigger reloads. You can also resume document retrieval and document processing manually using Integration Server Administrator or by invoking the pub.trigger:resumeRetrieval and pub.trigger:resumeProcessing public services.
3
Integration Server rolls back the document to the webMethods messaging trigger document store. This indicates that the required resources are not ready to process the document and makes the document available for processing at a later time. For serial webMethods messaging triggers, it also ensures that the document maintains its position at the top of webMethods messaging trigger queue.
Note: When the watt.server.dispatcher.messageStore.redeliverOriginalMessage parameter is set to true,Integration Server stores and resubmits the original message after retry failure. If the parameter is set to false, Integration Server stores the message as it is at that point in trigger service execution. If the trigger service modified the message, Integration Server stores the modified message and uses that as input for subsequent trigger service execution. The default value of the watt.server.dispatcher.messageStore.redeliverOriginalMessage parameter is false.
4
Optionally, Integration Server schedules and executes a resource monitoring service. A resource monitoring service is a service that you create to determine whether the resources associated with a trigger service are available. A resource monitoring service returns a single output parameter named isAvailable.
5
If the resource monitoring service indicates that the resources are available (that is, the value of isAvailable is true), Integration Server resumes document retrieval and document processing for the webMethods messaging trigger.
If the resource monitoring service indicates that the resources are not available (that is, the value of isAvailable is false), Integration Server waits a short time interval (by default, 60 seconds) and then re-executes the resource monitoring service. Integration Server continues executing the resource monitoring service periodically until the service indicates the resources are available.
Tip: You can change the frequency at which the resource monitoring service executes by modifying the value of the watt.server.trigger.monitoringInterval property.
6
After Integration Server resumes the webMethods messaging trigger, Integration Server passes the document to the webMethods messaging trigger. The webMethods messaging trigger and trigger service process the document just as they would any document in the trigger queue.
Note: At this point, the retry count is set to 0 (zero).
Overview of Throw Exception for Retry Failure
Configuring Transient Error Handling for a webMethods Messaging Trigger
Copyright © 2017-2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
Innovation Release