Configuring Transient Error Handling for a Non-Transacted JMS Trigger

The transient error handling and retry behavior that you specify for a non-transacted JMS trigger determines how Integration Server handles retry failure caused by transient errors during trigger service execution. The selected behavior also determines how Integration Server handles transient errors that occur during trigger preprocessing.

For more information about transient error handling for trigger preprocessing, see Transient Error Handling During Trigger Preprocessing.

Note:
If you do not configure service retry for a trigger, set the Max retry attempts property to 0. Because managing service retries creates extra overhead, setting this property to 0 can improve the performance of services invoked by the trigger.

2. In the Properties view, under Transient error handling, in the Max retry attempts field, specify the maximum number of times Integration Server should attempt to re-execute the trigger service. The default is 0 retries (the trigger service does not retry).

3. In the Retry interval property, specify the time period the Integration Server waits between retry attempts. The default is 10 seconds.

Select...	To...
Throw exception	Specify that Integration Server should throw a service exception when the last allowed retry attempt ends because of an ISRuntimeException. This is the default.
Suspend and retry later	Specify that Integration Server should recover the message back to the JMS provider and suspend the trigger when the last allowed retry attempt ends because of an ISRuntimeException. Note: If you want Integration Server to automatically enable the trigger when the trigger’s resources become available, you must provide a resource monitoring service that Integration Server can execute to determine when to resume the trigger.

5. If you selected Suspend and retry later, then in the Resource monitoring service property specify the service that Integration Server should execute to determine the availability of resources associated with the trigger service. Multiple triggers can use the same resource monitoring service. For information about building a resource monitoring service, see Using webMethods Integration Server to Build a Client for JMS.

Standard JMS triggers and services can both be configured to retry. When a trigger invokes a service (that is, the service functions as a trigger service), Integration Server uses the trigger retry properties instead of the service retry properties.

SOAP-JMS triggers and services used as operations in provider web service descriptors can both be configured to retry. When a web service operation processes a message received by a SOAP-JMS trigger, Integration Server uses the trigger retry properties instead of the service (operation) retry properties.

When Integration Server retries a trigger service and the trigger service is configured to generate audit data on error, Integration Server adds an entry to the audit log for each failed retry attempt. Each of these entries will have a status of “Retried” and an error message of “Null”. However, if Integration Server makes the maximum retry attempts and the trigger service still fails, the final audit log entry for the service will have a status of “Failed” and will display the actual error message. Integration Server makes the audit log entry regardless of which retry failure option the trigger uses.

You can invoke the pub.flow:getRetryCount service within a trigger service to determine the current number of retry attempts made by Integration Server and the maximum number of retry attempts allowed for the trigger service. For more information about the pub.flow:getRetryCount service, see the webMethods Integration Server Built-In Services Reference.