Integration Server 10.3 | Web Services Developer’s Guide | Transient Error Handling for Provider Web Service Descriptors | Transient Error Handling for an Operation Invoked by a Transacted SOAP-JMS Trigger
 
Transient Error Handling for an Operation Invoked by a Transacted SOAP-JMS Trigger
The following table describes how Integration Server handles transient errors for an operation in a provider web service descriptor when the following items are true:
*The service used as the operation contains logic to catch and wrap a transient error and re-throw it as an ISRuntimeException.
*The web service is invoked via SOAP over JMS.
*The message exchange pattern (MEP) of the operation must be In-Only. Integration Server does not support Robust-In-Only or In-Out operations when using a transaction.
*A transacted SOAP-JMS trigger listens for messages for the web service descriptor. That is, the web service endpoint alias assigned to the JMS binder uses a transacted SOAP-JMS trigger.
*The Pre-8.2 compatibility mode property is set to false for the web service descriptor.
Keep the following points in mind about transient error handling web services invoked via transacted SOAP-JMS triggers:
*The transient error handling for the SOAP-JMS trigger overrides any transient error handling configured for the service used as the operation.
*Do not use service handlers with web service descriptors for which a transacted SOAP-JMS trigger functions as the listener. A SOAP-JMS trigger is considered to be transacted when the JMS connection alias that the trigger uses to retrieve messages has a transaction type of XA TRANSACTION or LOCAL TRANSACTION.
Step
Description
1
The SOAP-JMS trigger receives the message from the JMS provider.
2
Integration Server uses information from the JMS message header and the SOAP message to route the message to the correct provider web service descriptor and operation.
3
Integration Server executes the service that corresponds to the operation.
4
If the service executes successfully, Integration Server considers web service execution to be complete.
5
If the service fails because of a ServiceException, Integration Server rolls back the entire transaction. Integration Server considers web service execution to be complete.
Rolling back the transaction causes the message to be recovered back to the JMS provider. The JMS provider marks the message as redelivered and may increment the delivery count (JMSXDeliveryCount) in the JMS message. At this point, the JMS provider typically makes the message available for immediate redelivery. The JMS provider continues to deliver the message to the SOAP-JMS trigger until the watt.server.jms.trigger.maxDeliveryCount is reached or the message is acknowledged.
If the SOAP-JMS trigger uses a document history database for exactly-once processing, Integration Server assigns the message a status of “completed” in the document history database. The next time the SOAP-JMS trigger receives the message, Integration Server acknowledges the message, discards it, and writes a journal log entry indicating that a Duplicate message was received. For more information about exactly-once processing for JMS triggers, see Using webMethods Integration Server to Build a Client for JMS.
Note:
Transacted triggers that encounter an exception must be rolled back to ensure that all the resources enlisted in the transaction are notified of the exception. With JMS triggers, rolling back the transaction results in the message being recovered back to the JMS provider, where it can be redelivered multiple times. To avoid the performance impact caused by redelivery of a message that cannot be processed due to a ServiceException, Software AG recommends configuring the SOAP-JMS trigger for exactly-once processing in which a document history database is used to perform duplicate detection. If the document history database is not used, Software AG recommends using another solution to prevent continuous redelivery.
6
If the service fails because of an ISRuntimeException, Integration Server does the following:
*Rolls back the entire transaction. Rolling back the transaction causes the message to be recovered back to the JMS provider. The JMS provider marks the message as redelivered and may increment the delivery count (JMSXDeliveryCount) in the JMS message. At this point, the JMS provider typically makes the message available for immediate redelivery.
*Takes one of the following actions depending on the value of the On transaction rollback property for the SOAP-JMS trigger.
*If the On transaction rollback property is set to Recover only, see step 7.
*If the On transaction rollback property is set to Suspend and recover, see step 8.
7
When a transient error occurs and the On transaction rollback property is set to Recover only, Integration Server repeats the entire process beginning with step 1.
Because it is possible that Integration Server receives the message almost immediately after transaction rollback, it is also possible that the temporary condition that caused the ISRuntimeException has not resolved and the web service will end with a transient error again.
If the maximum delivery count has been met, Integration Server rejects the message. Integration Server considers web service execution to be complete when the maximum delivery count is met.
Integration Server does not generate a fault or return a response to the web service client. This is true even for Robust-In-Only operations or In-Out operations.
Note:
The maximum delivery count, which is controlled by the watt.server.jms.trigger.maxDeliveryCount property, determines the maximum number of times the JMS provider can deliver the message to the SOAP-JMS trigger.
If the watt.server.jms.trigger.raiseEventOnRetryFailure property is set to true (the default), Integration Server generates a JMS retrieval failure event.
8
When a transient error occurs and the On transaction rollback property is set to Suspend and recover, Integration Server does the following:
*Suspends the SOAP-JMS trigger temporarily.
The SOAP-JMS trigger is suspended on this Integration Server only. If the Integration Server is part of a cluster, other servers in the cluster can retriever and process messages for the trigger.
Keep in mind that when a SOAP-JMS trigger is suspended any web service descriptor that uses the SOAP-JMS trigger as a listener will not receive any messages.
*Optionally schedules and executes a resource monitoring service.
*When the resource monitoring service indicates that the resources are available, Integration Server enables the SOAP-JMS trigger.
*Repeats the entire process beginning with step 1 (retrieving the original message form the JMS provider.
If the maximum delivery count has been met, Integration Server rejects the message. Integration Server considers web service execution to be complete when the maximum delivery count is met.
Integration Server does not generate a fault or return a response to the web service client. This is true even for Robust-In-Only and In-Out operations.
Note:
The maximum delivery count, which is controlled by the watt.server.jms.trigger.maxDeliveryCount property, determines the maximum number of times the JMS provider can deliver the message to the SOAP-JMS trigger.
If the watt.server.jms.trigger.raiseEventOnRetryFailure property is set to true (the default), Integration Server generates a JMS retrieval failure event.