Trading Networks 10.3 | Administering and Monitoring B2B Transactions | Service Development Help | Working with JMS Triggers | Transient Error Handling for Non-Transacted JMS Triggers
 
Transient Error Handling for Non-Transacted JMS Triggers
 
About Retry Behavior for Trigger Services
Service Requirements for Retrying a Trigger Service
Handling Retry Failure
Configuring Transient Error Handling for a Non-Transacted JMS Trigger
When building a JMS 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. 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. Because the condition that caused the trigger service to fail is temporary, the trigger service might execute successfully if Integration Server waits and then re-executes the service.
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.
*A 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 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 to the time the trigger service executes.