Trading Networks 10.3 | Administering and Monitoring B2B Transactions | Service Development Help | Working with JMS Triggers | Building a Transacted JMS Trigger | Fatal Error Handling for Transacted JMS Triggers
 
Fatal Error Handling for Transacted JMS Triggers
 
Configuring Fatal Error Handling for Transacted JMS Triggers
You can specify that Integration Server suspend a transacted JMS trigger automatically if a fatal error occurs during trigger service execution. For a standard JMS trigger, a fatal error occurs when the trigger service ends because of a ServiceException. For a SOAP-JMS trigger, a fatal error occurs when the web service operation ends because of a ServiceException.
When a transacted JMS trigger is configured to suspend when a fatal error occurs, Integration Server does the following when the trigger service or web service operation ends with a ServiceException:
Step
Description
1
The trigger service for a transacted JMS trigger fails because of a ServiceException. Or, a web service operation invoked via a transacted SOAP-JMS trigger fails because of a ServiceException.
2
Integration Server rolls back the entire transaction and Integration Server recovers the message back to the JMS provider. The JMS provider marks the message as redelivered and increments the value of the JMSXDeliveryCount property in the JMS message.
3
If the JMS trigger is configured to use a document history database for exactly-once processing, Integration Server adds an entry with a status of “completed” for the message to the document history database.
Because Integration Server does not acknowledge the message when it is rolled back, the JMS provider makes the message available for redelivery to the JMS trigger. However, a message that causes a trigger service to end because of a Service Exception typically does not process successfully upon redelivery. Integration Server adds the “completed” entry so that the message is treated as a duplicate when it is received from the JMS provider. The message is rejected after it is resent.
If the JMS trigger does not use a document history database, Integration Server continues to receive and attempt message processing until the message processes successfully or the maximum delivery count has been met. The maximum delivery count determines the maximum number of time the JMS provider can deliver the message to the JMS trigger. It is controlled by the watt.server.jms.trigger.maxDeliveryCount property.
4
Integration Server suspends the JMS trigger.
Important:
If you disable or suspend a SOAP-JMS trigger that acts as a listener for one or more provider web service descriptors, Integration Server will not retrieve any messages for those web service descriptors until the trigger is enabled.
5
The JMS trigger remains suspended until one of the following occurs:
*You enable the trigger using the pub.trigger:enableJMSTriggers service.
*You enable the trigger using Integration Server Administrator.
*Integration Server restarts or the package containing the trigger reloads. (When Integration Server suspends a trigger because of a fatal error, Integration Server considers the change to be temporary. For more information about temporary vs. permanent state changes for triggers, see webMethods Integration Server Administrator’s Guide.)
You can handle the exception that causes the fatal error by configuring Integration Server to generate JMS retrieval failure events for fatal errors and by creating an event handler that subscribes to JMS retrieval failure events. Integration Server passes the contents of the JMS message and exception information to the event handler.