Configuring Transient Error Handling for a webMethods Messaging Trigger

The transient error handling behavior that you specify for a webMethods messaging trigger determines how Integration Server handles transient errors that occur during trigger service execution. The selected behavior also determines how Integration Server handles transient errors that occur during trigger preprocessing.

Select...

To...

Max attempts reached

Specify that Integration Server retries the trigger service a limited number of times.

In the Max retry attempts property, enter the maximum number of times Integration Server should attempt to re-execute the trigger service. The default is 0 retries.

Successful

Specify that the Integration Server retries the trigger service until the service executes to completion.

Note:

If a webMethods messaging trigger is configured to retry until successful and a transient error condition is never remedied, a trigger service enters into an infinite retry situation in which it continually re-executes the service at the specified retry interval. Because you cannot disable a webMethods messaging trigger during trigger service execution and you cannot shut down the server during trigger service execution, an infinite retry situation can cause the Integration Server to become unresponsive to a shutdown request. For information about escaping an infinite retry loop, see About Retrying Trigger Services and Shutdown Requests.

Select...

To...

Throw exception

Indicate that Integration Server throws a service exception when the last allowed retry attempt ends because of an ISRuntimeException.

This is the default.

For more information about the Throw exception option, see Overview of Throw Exception for Retry Failure.

Suspend and retry later

Indicate that Integration Server suspends the webMethods messaging trigger when the last allowed retry attempt ends because of an ISRuntimeException. Integration Server retries the trigger service at a later time. For more information about the Suspend and retry later option, see Overview of Suspend and Retry Later for Retry Failure.

Note:

If you want Integration Server to suspend the webMethods messaging trigger and retry it later, you must provide a resource monitoring service that Integration Server can execute to determine when to resume the webMethods messaging trigger. For more information about building a resource monitoring service, see Publish-Subscribe Developer’s Guide.

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 webMethods messaging triggers can use the same resource monitoring service.

webMethods messaging triggers and services can both be configured to retry. When a webMethods messaging trigger invokes a service (that is, the service functions as a trigger service), the Integration Server uses the webMethods messaging trigger retry properties instead of the service 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 service 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 service log entry for the service will have a status of “Failed” and will display the actual error message. This occurs regardless of which retry failure option the webMethods messaging trigger uses.

You can invoke the pub.flow:getRetryCount service within a trigger service to determine the current number of retry attempts made by the 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.