Designer 10.7 | webMethods Service Development Help | Working with MQTT Triggers | Transient Error Handling for an MQTT Trigger | Handling Retry Failure | Overview of Stop Trigger
 
Overview of Stop Trigger
The Stop trigger retry failure option temporarily disables an MQTT trigger and prevents acknowledgment of the message to the MQTT server. This makes it possible for the MQTT server to redeliver the message when the trigger is re-enabled.
Redelivery of the message by the MQTT server hinges on three factors:
*The overall QoS of the message.
An MQTT trigger can only receive the message again if the overall QoS for the message is 1 or 2. If either the publishing QoS or subscribing QoS is 0, the MQTT server will not redeliver the message.
*Whether or not the MQTT trigger uses clean sessions for the subscriptions.
If the MQTT connection alias used by the trigger uses clean sessions for subscriptions, the message cannot be redelivered because subscriptions are not persisted. For an unacknowledged message to be redelivered to an MQTT trigger, the Use Clean Session for Subscriptions check box must not be selected for the MQTT connection alias.
*The Acknowledgement mode for the MQTT trigger is Client Acknowledgement.
If the MQTT trigger uses client acknowledgment, the MQTT trigger does not acknowledge the message before retry failure occurs. This makes it possible for the MQTT server to redeliver the message. If the MQTT trigger uses Auto Acknowledgement, the message is acknowledged upon receipt which is before retry failure occurs.
Note:
If the Integration Server becomes disconnected from the MQTT server, the MQTT trigger will not be able to acknowledge outstanding messages. Upon reconnection, the MQTT server should redeliver any persisted messages that the MQTT trigger received but did not acknowledge.
The following table provides an overview of how Integration Server handles retry failure for an MQTT trigger when the Stop trigger option is selected.
Step
Description
1
Integration Server makes the final retry attempt and the MQTT trigger service fails because of an ISRuntimeException.
2
Integration Server stops the MQTT trigger by temporarily disabling it. The MQTT trigger will not retrieve or process more messages. Integration Server clears the local trigger queue.
If the MQTT trigger is currently processing messages retrieved from the local trigger queue, Integration Server waits a short time for message processing to complete. The server configuration parameter watt.server.commonmessaging.trigger.stopRequestTimeOut determines the maximum time that Integration Server waits for processioning to complete. The default is 3 seconds.
Note:
The change to the trigger state is temporary. Message retrieval and processing will resume for the trigger if Integration Server restarts or the package containing the trigger reloads. You can also enable triggers manually using Integration Server Administrator.
3
If the MQTT trigger Acknowledgement mode property is set Client Acknowledgement, Integration Server does not acknowledge the message to the MQTT server. This allows the MQTT message to be redelivered when the trigger restarts.
Only a persisted message can be redelivered. A persisted message has an overall QoS of 1 or 2 where overall refers to the lower of the QoS levels assigned to the publishing of the message or the receiving of the message. If the QoS for message publishing or retrieval is 0, the message cannot be recovered. Additionally, the MQTT connection alias used by the trigger must not use clean sessions.
If the Acknowledgement mode property is set to Auto Acknowledgement, Integration Server will have already acknowledged the message. If this is the case, the MQTT server will not redeliver the message to the MQTT trigger. Consequently, the Stop trigger retry failure handling is better suited to triggers that use client acknowledgement.
4
Optionally, Integration Server schedules and executes a resource monitoring service. A resource monitoring service is a service that you create to determine whether the resources associated with a trigger service are available. A resource monitoring service returns a single output parameter named isAvailable.
Integration Server uses a resource monitoring service only if one is specified in the Resource monitoring service property.
5
If the resource monitoring service indicates that the resources are available (that is, the value of isAvailable is true), Integration Server enables the trigger. Message processing and message retrieval resume for the MQTT trigger.
If the resource monitoring service indicates that the resources are not available (that is, the value of isAvailable is false), Integration Server waits a short time interval (by default, 60 seconds) and then re-executes the resource monitoring service. Integration Server continues executing the resource monitoring service periodically until the service indicates the resources are available.
Tip:
You can change the frequency with which the resource monitoring service executes by modifying the value of the watt.server.commmonmessaging.trigger.monitoringInterval property.
6
The MQTT trigger receives the message and places it in the local trigger queue to await processing. At this point, the retry count is set to 0 (zero).
Note:
If the MQTT trigger does not have a resource monitoring service, you will need to manually enable the MQTT trigger using Integration Server Administrator. You can also start a stopped trigger by reloading the package containing the MQTT trigger.