RabbitMQ Provider

Publishes Drupal Service Queue tasks to RabbitMQ or Amazon MQ for RabbitMQ with Key-backed credentials, TLS, delayed delivery, and encrypted callback-token validation.

RabbitMQ Provider connects Drupal’s Service Queue to RabbitMQ and Amazon MQ for RabbitMQ. It is a transport bridge: Drupal publishes JSON tasks to a RabbitMQ exchange, and a separate worker consumes and processes them. This lets a Drupal site use a RabbitMQ broker instead of Azure Service Bus while continuing to use modules that already create Service Queue work, such as Triage.

If you are new to Drupal, the workflow is: install the module, configure a broker connection and queue in the admin UI, then run your worker outside Drupal. The module does not include a consumer or worker. It publishes messages, declares the exchange and delay queues it needs, and validates the encrypted bearer tokens workers send back to Drupal.

Features

• Adds RabbitMQ and Amazon MQ for RabbitMQ as Service Queue providers.
• Stores reusable broker connections as configuration entities.
• Supports credentials from Key as either a user name/password pair or a complete amqp:// or amqps:// URI.
• Supports TLS, including optional CA, client certificate, and client key paths.
• Supports three delayed-delivery strategies:
  • the RabbitMQ delayed message exchange plugin;
  • per-queue TTL with dead-lettering, suitable for Amazon MQ for RabbitMQ;
  • no delayed delivery.
• Rounds delayed delivery up to a safe time bucket so tasks do not run early.
• Validates encrypted callback bearer tokens with the shared service_queue token service.
• Declares the exchange and delay queues automatically. Your worker queue and binding remain your responsibility.
• Works with any module that publishes through Service Queue, including the Triage suite.

Use this module when Drupal needs to hand work to an external RabbitMQ consumer, when Azure Service Bus is not available or not preferred, or when the broker is Amazon MQ for RabbitMQ.

Post-Installation

1. Install and enable the module, for example:

   composer require drupal/rabbitmq_provider
   drush en rabbitmq_provider

2. Create the required Key entities:

   • a User/password Key for broker credentials; or
   • an Authentication Key containing a full amqp:// or amqps:// URI;
   • a Queue callback key used to sign worker callbacks.

3. Go to Configuration > Web services > RabbitMQ connections (/admin/config/rabbitmq-connections) and add a connection:

   • broker host, port, and virtual host;
   • exchange name and exchange type (direct or topic);
   • credential Key and callback Key;
   • TLS settings;
   • delayed-delivery strategy and maximum delay.

4. Go to Configuration > Web services > Queue connections (/admin/config/queue-connections) and create a queue connection:

   • provider: rabbitmq_provider:<connection id>;
   • queue/routing key: the value your worker queue is bound to.
5. Reference that queue connection from a Triage queue connection or from the module that publishes work.
6. Create the worker queue and bind it to the exchange outside Drupal. The module declares the exchange and its own delay queues, but it does not create the queue your worker consumes.
7. Run your worker. It receives the JSON task, processes it, and calls back into Drupal with an encrypted bearer token generated from the callback key.

Permissions:

• administer rabbitmq connections manages broker connections.
• Service Queue and Triage queue permissions are granted separately.

For Amazon MQ for RabbitMQ, use the AMQPS endpoint on port 5671 and choose Per-queue TTL with dead-lettering. Amazon MQ does not provide the delayed message exchange plugin. See docs/amazon-mq.md in the project repository for a full walkthrough.

Additional Requirements

• Drupal 11
• Key
• Service Queue
• Entity Name Uniqueness
• php-amqplib/php-amqplib 3.7 or later, installed through Composer
• RabbitMQ 3.13 or later, or Amazon MQ for RabbitMQ
• Optional: the rabbitmq_delayed_message_exchange plugin when using the delayed exchange strategy
• A separate worker/consumer process. The module publishes and authenticates callbacks; it does not process queue messages itself.

Recommended modules/libraries

• Triage, Triage Common, and Triage Mail for the complete queue-backed mail processing workflow.
• Key for credential storage. It is required, but other modules that manage keys may be useful in larger deployments.
• The RabbitMQ management plugin or Amazon CloudWatch for monitoring queues, connections, and dead-letter activity.
• A process supervisor such as systemd, Supervisor, or a container orchestrator to keep the external worker running.

Similar projects

Drupal’s core Queue API, Advanced Queue, and generic AMQP or RabbitMQ modules generally run queue workers inside Drupal. This module is different: it is a transport adapter for Service Queue that publishes to an external broker and leaves consumption to your worker. It also accounts for Amazon MQ constraints, including the absence of the delayed message exchange plugin, and provides the callback-token validation expected by Service Queue consumers.

Supporting this Module

Bug reports, feature requests, and documentation improvements are welcome in the project issue queue. There is currently no funding page; code review, testing, and issue-queue help are the best ways to support the module.

Community Documentation

• README.md in the project repository: installation, credential formats, delay strategies, and the worker callback contract.
• docs/amazon-mq.md: Amazon MQ for RabbitMQ setup, TLS, queues, and delayed delivery.
• The Drupal.org issue queue for support and feature requests.
• Amazon MQ for RabbitMQ documentation
• RabbitMQ TTL and dead-lettering documentation

Additional notes

• The module does not create or run the worker queue consumer. You must create the worker queue, bind it to the exchange, and run a worker that understands the Service Queue payload.
• Callback keys are secrets. Keep them in Key and never place them in exported configuration or source control.
• Delayed delivery is best-effort at the broker level. Bucket rounding means a task may run slightly later than requested, never earlier.