Service Requirements for Retrying a Trigger Service

Building Your Event-Driven Architecture : Using Integration Server to Build a Client for JMS : Working with JMS Triggers : Transient Error Handling for Non-Transacted JMS Triggers : Service Requirements for Retrying a Trigger Service

To be eligible for retry, the trigger service or web service operation must do one of the following to catch a transient error and re-throw it as an ISRuntimeException:

If the trigger service or web service operation is a flow service, the trigger service must invoke pub.flow:throwExceptionForRetry. For more information about the pub.flow:throwExceptionForRetry, see the webMethods Integration Server Built-In Services Reference.

If the trigger service or web service operation is written in Java, the service can use com.wm.app.b2b.server.ISRuntimeException(). For more information about constructing ISRuntimeExceptions in Java services, see the webMethods Integration Server Java API Reference for the com.wm.app.b2b.server.ISRuntimeException class.

When a service invokes a pub.jms* service that sends a JMS message and the service fails because a resource needed by the pub.jms* service is not available, Integration Server automatically detects and propagates an ISRuntimeException.

Adapter services built on Integration Server 6.0 or later, and based on the ART framework, detect and propagate exceptions that signal a retry if a transient error is detected on their back-end resource. This behavior allows for the automatic retry when the service functions as a trigger service.

Note:

Integration Server does not retry a trigger service that fails because a ServiceException occurred. A ServiceException indicates that there is something functionally wrong with the service. A service can throw a ServiceException using the EXIT step.

Contact Support | Community | Feedback