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 Non-Transacted SOAP-JMS Trigger
 
Transient Error Handling for an Operation Invoked by a Non-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.
*A non-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 non-transacted SOAP-JMS trigger.
*The Pre-8.2 compatibility mode property is set to false for the web service descriptor.
Keep in mind the following information about transient error handling for web services invoked via 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.
*Integration Server ignores any transient error handling properties configured for the service handlers. That is, Integration Server does not perform any transient error handling for handler services. The handler services need to be coded to handle any errors or exceptions that may occur and return the appropriate status code. For more information about handler services and status codes, see About Handlers and Handler Services.
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 request handler services assigned to the provider web service descriptor.
One of the following occurs:
*If the request handlers execute successfully (all handlers return a status of 0), Integration Server proceeds to step 4.
*If a request handler ends in failure and returns a status of 1, 2, or 3, Integration Server suspends execution of the handler chain. The status code returned by the handler service determines what action Integration Server takes next. However, Integration Server considers web service execution to be complete at this point.
*If Integration Server throws an exception that is not caught or handled by the request handler service, Integration Server proceeds as if the request handler returned a status code of 2. Integration Server considers web service execution to be complete at this point.
For more information about request handlers and status codes, see About Request Handler Services.
4
Integration Server executes the service that corresponds to the operation.
*If the service executes successfully, Integration Server does one of the following based on the operation MEP:
*For an In-Only operation, Integration Server considers web service execution to be complete.
*For a Robust-In-Only operation, Integration Server considers web service execution to be complete.
*For an In-Out operation, Integration Server executes the response handlers and sends a SOAP response to the web service client. Integration Server considers web service execution to be complete.
*If the service fails because of a ServiceException, Integration Server logs the ServiceException to the error log. Integration Server does one of the following based on the operation MEP:
*For an In-Only operation, Integration Server considers web service execution to be complete.
*For an Robust-In-Only operation, Integration Server logs the ServiceException to the error log. Integration Server creates a SOAP response that contains the SOAP fault which, in turn, contains the ServiceException. Integration Server executes the response handlers and sends a SOAP response to the web service client. Integration Server considers web service execution to be complete.
For more information about response handlers, see About Response Handler Services.
*For an In-Out operation, Integration Server logs the ServiceException to the error log. Integration Server creates a SOAP response that contains the SOAP fault which, in turn, contains the ServiceException. Integration Server executes the response handlers and sends a SOAP response to the web service client. Integration Server considers web service execution to be complete.
For more information about response handlers, see About Response Handler Services.
*If the service fails because of an ISRuntimeException and the SOAP-JMS trigger has a Max retry attempts set to 1 or greater, Integration Server re-executes the service. Integration Server continues to re-execute the service until the service executes to completion or Integration Server makes the maximum retry attempts.
5
If Integration Server makes the final retry attempt and the service fails because of an ISRuntimeException, retry failure occurs. The action Integration Server takes depends on the On retry failure property for the SOAP-JMS trigger used to retrieve the request message.
*If the On retry failure property is set to Throw exception, proceed to step 6.
*If the On retry failure property is set to Suspend and retry later, proceed to step 7.
6
When retry failure occurs and the On retry failure property is set to Throw exception, Integration Server does the following:
*Treats the last service failure as a ServiceException
*Writes the ServiceException to the error log.
*Rejects the message. If the message is persistent, Integration Server returns an acknowledgement to the JMS provider.
*Generates a JMS retrieval failure event if the watt.server.jms.trigger.raiseEventOnRetryFailure property is set to true (the default).
*If the SOAP-JMS trigger is configured to suspend on error when a fatal error occurs, Integration Server suspends the SOAP-JMS trigger. Otherwise, Integration Server processes the next message for the JMS trigger.
*Integration Server does one of the following based on the operation MEP.
*For an In-Only operation, Integration Server considers web service execution to be complete.
*For a Robust-In-Only operation, Integration Server creates a SOAP response that contains the SOAP fault which, in turn, contains the ServiceException. Integration Server executes the response handlers and sends the SOAP response to the web service client. For more information about response handlers, see About Response Handler Services. Integration Server considers web service execution to be complete.
*For an In-Out operation, Integration Server creates a SOAP response that contains the SOAP fault which, in turn, contains the ServiceException. Integration Server executes the response handlers and sends the SOAP response to the web service client. For more information about response handlers, see About Response Handler Services. Integration Server considers web service execution to be complete.
7
When retry failure occurs and the On retry failure property is set to Suspend and retry later, Integration Server does the following:
*For a Robust-In-Only operation, Integration Server creates a SOAP response that contains the SOAP fault which, in turn, contains the ServiceException. Integration Server executes the response handlers. Integration Server then suppresses the SOAP response so that the retry processing can occur. Integration Server does not send the SOAP response to the web service client.
*For an In-Out operation, Integration Server creates a SOAP response that contains the SOAP fault which, in turn, contains the ServiceException. Integration Server executes the response handlers. Integration Server then suppresses the SOAP response so that the retry processing can occur. Integration Server does not send the SOAP response to the web service client.
For all operations, regardless of MEP, Integration Server does the following:
*Suspends the SOAP-JMS trigger.
*Recovers the message back to the JMS provider.
*Optionally, schedules and executes a resource monitoring service.
*When the resource monitoring service indicates that the resources are available, Integration Server enables the trigger.
*Repeats the entire process beginning with step 1 (retrieving the original message from the JMS provider).
If the maximum delivery count has been met, Integration Server rejects the message. Integration Server does not generate a fault, execute response handlers, or return a response to the web service client. This is true even for a Robust-In-Only operation or an In-Out operation.
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.
Integration Server considers web service execution to be complete when the maximum delivery count is met.