Building Your Event-Driven Architecture : Service Development Help : Properties : JMS Trigger Properties : Transient Error Handling with a Non-Transacted JMS Trigger
Transient Error Handling with a Non-Transacted JMS Trigger
When building a trigger, you can specify what action Integration Server takes when the trigger service fails because of a transient error caused by a run-time exception. That is, you can specify whether or not Integration Server should retry the trigger.
In the Properties view, under Transient error handling, you specify whether or not Integration Server should retry the trigger.
Property
Description
Max retry attempts
Specifies the maximum number of times Integration Server should re-execute the trigger service when the trigger service ends because of a transient error that causes an ISRuntimeException. The default is 0 attempts (indicating the trigger service does not retry).
Retry interval
Specifies the length of time Integration Server waits between retry attempts. The default is 10 seconds.
On retry failure
Indicates how Integration Server handles a retry failure for a JMS trigger. A retry failure occurs when Integration Server reaches the maximum number of retry attempts and the trigger service still fails because of an ISRuntimeException.
This property also determines how Integration Server handles a transient error that occurs during trigger preprocessing.
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.
Suspend and retry later
Indicate that Integration Server suspends the trigger when the last allowed retry attempt ends because of an ISRuntimeException. Integration Server retries the trigger service at a later time when the resources needed by the trigger service become available.
When On Retry failure is set to Suspend and retry later, a transient error that occurs during trigger preprocessing causes Integration Server to suspend the trigger and resume it when the resources, specifically the document history database, are available.
On transaction rollback
Indicates how Integration Server handles a transient error that occurs during service execution, resulting in the entire transaction being rolled back.
Select...
To...
Recover only
Indicate Integration Server recovers the message back to the JMS provider. Integration Server receives the message again almost immediately.
This is the default.
Suspend and recover
Indicate that Integration Server suspends the JMS trigger and then recovers the message back to the JMS provider. Integration Server executes the trigger service at a later time when the resources needed by the trigger service become available.
Resource monitoring service
Specifies the service that Integration Server executes to determine whether the resources needed by the JMS trigger are available and if the trigger can be resumed. Integration Server schedules a system task to execute the resource monitoring service when one of the following occurs:
*The trigger service ends because of a retry failure and the On retry failure property is set to Suspend and retry later.
*The trigger service is part of a transacted JMS trigger and the On transaction rollback property is set to Suspend and recover.
*The document resolver service used for exactly-once processing ends because of a run-time exception and the watt.server.trigger.preprocess.suspendAndRetryOnError is set to true.
Note:  
A resource monitoring service must use the pub.trigger:resourceMonitoringSpec as the service signature.
Copyright © 2016 - 2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback