RabbitMQ Trigger

Discover more about the RabbitMQ Trigger and how to use it on the Digibee Integration Platform.

RabbitMQ Trigger is responsible for the consumption of messages from a RabbitMQ broker.


Take a look at the configuration options for the component. Parameters supported by Double Braces expressions are marked with (DB).

The RabbitMQ client doesn't allow limiting the size of messages. If too-large messages are sent, the infrastructure of triggers from Digibee Integration Platform can refuse them. We don't advise the dispatch of too-large messages through message buses.

This trigger has two messages acknowledge strategies (receivement confirmation):

  • Automatic acknowledge

The confirmation of each message received by the trigger is automatic and immediate upon its reception, and the broker understands that it has been delivered. On the one hand, automatic acknowledgment guarantees high performance, but on the other hand, it does not prevent the loss of messages if the associated pipeline does not process them or processes them incorrectly.

  • Manual acknowledge

Each message received by the trigger is held as "unchecked", a state of no confirmation, while it is processed by the pipeline. When manually acknowledging, the RabbitMQ broker assumes that the message is still pending. If there is a problem in the trigger infrastructure or the pipeline responds with an error, the message may be processed again. The number of configured consumers for the pipeline determines how many messages can be processed simultaneously. For this purpose, the prefetch size of RabbitMQ is configured with the same value as that of the pipeline consumers.


The configuration of consumers made in the deployment of a pipeline has a direct impact on the consumption throughput and the messages output when the RabbitMQ trigger is activated. If the auto acknowledge is deactivated, the number of consumers becomes even more important. This is because the number of messages processed simultaneously is equal to the number of consumers.

Queues, routing keys and exchanges declaration

RabbitMQ Trigger doesn't declare queues configuration parameters, routing keys and exchanges in the RabbitMQ broker. For the trigger to consume messages from queues, it's expected that every configuration is made.

Message format in the pipeline input

Pipelines associated with RabbitMQ Trigger receive the following message as input:

  "body": <STRING message content; if binary, then Base64>,
  "properties": {
    "appId": <STRING application id>,
    "classId": <STRING class id>,
    "clusterId": <STRING cluster id>,
    "contentEncoding": <STRING content encoding>,
    "contentType": <STRING message content type>,
    "correlationId": <STRING correlation id>,
    "deliveryMode": <INT delivery mode>,
    "expiration": <STRING message expiration in ms>,
    "messageId": <STRING message id>,
    "priority": <INT message priority>,
    "replyTo": <STRING reply to queue>,
    "type": <STRING message type>,
    "userId": <STRING user id>,
    "timestamp": <LONG message timestamp>
  "headers": {
    "header1": "value1", ...
  "envelope": {
    "deliveryTag": <LONG message delivery tag>
    "exchange": <STRING exchange that processed the message>
    "routingKey": <STRING routing key used to route message>

Last updated