Designer 10.7 | webMethods Service Development Help | Working with JMS Triggers | Building a Transacted JMS Trigger | Transient Error Handling for Transacted JMS Triggers
 
Transient Error Handling for Transacted JMS Triggers
 
Overview of Recover Only for Transaction Rollback
Overview of Suspend and Recover for Transaction Rollback
Configuring Transient Error Handling for Transacted JMS Triggers
When building a transacted JMS trigger, you can specify what action Integration Server takes when a transient error causes a trigger service or a web service operation to fail and the entire transaction is rolled back.
A transient error is an error that arises from a temporary condition that might be resolved or corrected quickly, such as the unavailability of a resource due to network issues or failure to connect to a database. A transient error is caused by a run-time exception. A run-time exception (specifically, an ISRuntimeException) occurs in the following situations.
*The trigger service catches and wraps a transient error and then re-throws it as an ISRuntimeException.
*The web service operation that processes the message received by a SOAP-JMS trigger catches and wraps a transient error and then re-throws it as an ISRuntimeException.
Note:
For a service handler invoked by a SOAP-JMS trigger, Integration Server treats all errors as fatal. Service handlers invoked by SOAP-JMS triggers cannot be retried.
*The pub.jms:send, pub.jms:sendAndWait, or pub.jms:reply service fails because a resource (such as the JNDI provider or JMS provider) is not available.
If the JMS provider is not available, and the settings for the pub.jms* service indicate that Integration Server should write messages to the client side queue, Integration Server does not throw an ISRuntimeException.
*A transient error occurs on the back-end resource for an adapter service. Adapter services built on Integration Server 6.0 or later, and based on the ART framework, detect and propagate exceptions that signal a retry automatically if a transient error is detected on their back-end resource.
Note:
A web service connector that sends a JMS message can throw an ISRUntimeException, such as when the JMS provider is not available. However, Integration Server automatically places the ISRuntimeException in the fault document returned by the web service connector. If you want the parent flow service to catch the transient error and re-throw it as an ISRuntimeException, you must code the parent flow service to check the fault document for an ISRuntimeException and then throw an ISRuntimeException explicitly.
You can specify one of the following transient error handling options for a transacted JMS trigger:
*Recover only. After a transaction is rolled back, Integration Server receives the message from the JMS provider almost immediately. This is the default.
*Suspend and recover. After a transaction is rolled back, Integration Server suspends the JMS trigger and receives the message from the JMS provider at a later time.
You can also configure Integration Server and/or a JMS trigger to handle transient errors that occur during trigger preprocessing. The trigger preprocessing phase encompasses the time from when a trigger first receives a message from it’s local queue on Integration Server b to the time the trigger service executes.
For more information about transient error handling for trigger preprocessing, see Transient Error Handling During Trigger Preprocessing.