Configuring Transient Error Handling for an MQTT Trigger

The transient error handling properties that you specify for an MQTT trigger determines the number of times Integration Server retries a trigger service when a transient error occurs during trigger service execution. The properties also determine how Integration Server proceeds when retry failure occurs.

Note:
Unlike JMS triggers and webMethods messaging trigger, the transient error handling configuration for an MQTT trigger does not affect how Integration Server handles any transient errors that occur during trigger preprocessing.

1. In the Package Navigator view of Designer, open the MQTT trigger for which you want to configure transient error handling.

2. In the Properties view, under Transient error handling, in the Max retry attempts field, specify the maximum number of times Integration Server should attempt to re-execute the trigger service. The default is 0 retries (the trigger service does not retry).

3. In the Retry interval property, specify the time period the Integration Server waits between retry attempts. The default is 10 seconds.

Select...	To...
Throw exception	Specify that Integration Server throws a ServiceException when the last allowed retry attempt ends because of an ISRuntimeException. This is the default.
Stop trigger	Specify that Integration Server temporarily disables the MQTT trigger when the last allowed retry attempt ends because of an ISRuntimeException. Message retrieval and processing stops until the trigger is re-enabled.

5. If you selected Stop trigger, in the Resource monitoring service property specify the service that Integration Server executes to determine the availability of resources associated with the trigger service. Multiple triggers can use the same resource monitoring service. For information about building a resource monitoring service, see Building a Resource Monitoring Service for an MQTT Trigger.

If you select the Stop trigger retry failure option but do not specify a resource monitoring service, the MQTT trigger will need to be re-enabled manually when it is temporarily disabled because of retry failure.

If you do not configure service retry for a trigger, set the Max retry attempts property to 0. Because managing service retries creates extra overhead, setting this property to 0 can improve the performance of services invoked by the trigger.

MQTT triggers and services can both be configured to retry. When a MQTT trigger invokes a service (that is, the service functions as a trigger service), Integration Server uses the trigger retry properties instead of the service retry properties.

When Integration Server retries a trigger service and the trigger service is configured to generate audit data on error, Integration Server adds an entry to the audit log for each failed retry attempt. Each of these entries will have a status of “Retried” and an error message of “Null”. However, if Integration Server makes the maximum retry attempts and the trigger service still fails, the final audit log entry for the service will have a status of “Failed” and will display the actual error message. Integration Server makes the audit log entry regardless of which retry failure option the trigger uses.

Integration Server generates the following journal log message between retry attempts:

You can invoke the pub.flow:getRetryCount service within a trigger service to determine the current number of retry attempts made by Integration Server and the maximum number of retry attempts allowed for the trigger service. For more information about the pub.flow:getRetryCount service, see the webMethods Integration Server Built-In Services Reference.