Software AG Products 10.7 | Integrating On-Premises and Cloud Applications | Service Development | Working with webMethods Messaging Triggers | About Transient Error Handling for a webMethods Messaging Trigger | Configuring Transient Error Handling for a webMethods Messaging Trigger
 
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.
For more information about transient error handling for trigger preprocessing, see Transient Error Handling During Trigger Preprocessing.
*To configure transient error handling for a webMethods messaging trigger
1. In the Package Navigator view of Designer, open the webMethods messaging trigger for which you want to configure retry behavior.
2. In the Properties view, under Transient error handling, select one of the following for Retry until property:
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.
3. In the Retry interval property, specify the time period the Integration Server waits between retry attempts. The default is 10 seconds.
4. Set the On retry failure property to one of the following:
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.
6. Click File > Save.
Notes:
*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.
*Integration Server generates the following journal log message between retry attempts:
[ISS.0014.0031D] Service serviceName failed with ISRuntimeException. Retry x of y will begin in retryInterval milliseconds.
*If you do not configure service retry for a webMethods messaging trigger, set the Max retry attempts property to 0. This can improve the performance of services invoked by the webMethods messaging trigger.
*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.