RabbitMQ Trigger

Available since version 5.5

RabbitMQ triggers enable triggering Processes on messages received from RabbitMQ queue. The RabbitMQ trigger consumes the message from the queue whenever there is a new message available. The contents of the consumed message are then available in the Process for further processing.

Configuring RabbitMQ Triggers

• Queue (required)

  Name of the queue to listen to

• Connection string (required)

  AMQP 0-9-1 URI, e.g. amqp://guest:guest@localhost:5672/

• Max concurrent messages

  Limit on how many messages will be processed at a time. Essentially will limit the number of Processes running at the same time on a single Agent. An empty value, or a value of 0 is treated as infinite.

• Retry message processing if exception is thrown
  If set, and the first Process execution fails in an exception, the Process is executed a second time

• Reply
  If set, the result of a successful Process execution will be sent to a response queue. The response queue is set to the ReplyTo property of the request. If the ReplyTo property is not set, the response queue is set to Default reply queue

• Reply errors

  If set, the result of a failed Process execution will be sent to a response queue

• Default reply queue

  The queue to which responses will be sent if the ReplyTo property is not set

Trigger data for the Process

The trigger will pass the message content serialized as a UTF-8 string to the Process. It can be accessed via the #trigger.data.body reference.

Message properties can be accessed under #trigger.data.BasicProperties, e.g. #trigger.data.BasicProperties.CorrelationId. Some routing details are also available, e.g. #trigger.data.RoutingKey. More information on properties and routing details is available in RabbitMQ's Publisher documentation.

Reply messages

Sometimes you need to get a reply back to the sender of the request, e.g. when the caller needs to wait for the triggered Process to finish, or needs the results. In this case, you can turn on replies on the RabbitMQ trigger. This will then return the result of the Process in a message that is put to the given reply queue.

The request-reply process usually goes as follows:

• The caller decides on a queue for receiving the reply, and start listening to it. A message is sent to the queue listened by the trigger, with the ReplyTo property set to the reply queue. The correlationId property may also be set to help correlate requests and responses.

• The trigger will receive the request and start a new Process instance, passing the message body and properties as trigger properties to the Process.

• The Process finishes. In two cases, the flow ends here:

  • If the Process succeeded, and Reply is not selected.

  • If the Process failed, and Reply Errors is not selected.

• Otherwise, a response is created, which can happen in one of three ways:

  • If the Process succeeded, and the Process result is a RabbitMQ message (i.e, an object containing a Body and BasicProperties), the message is used as a response. This allows developers to customize the response to their exact needs.

  • If the Process succeeded, and the Process result is not a RabbitMQ message, the response is set to the Process result.

  • If the Process failed, the response is set to the message of the exception.

  In the last two cases, the properties are set by the Agent. The CorrelationId property is set to the CorrelationId value from the request, and some other common properties set to sensible values.

• The response is then sent to the queue given in the ReplyTo property, or if the request did not define one, in the Default reply queue.

• The caller will receive the reply message and process it as desired.