Announcing the RabbitMQ extension for Azure Functions

We're excited to announce today the public preview of the RabbitMQ Extension for the Azure Functions runtime. With this new extension you can now have functions trigger in response to queue messages, or connect to RabbitMQ for an output binding. Currently the preview trigger is supported when publishing functions to the Functions Premium plan with runtime driven scale enabled, or a dedicated App Service Plan. You can also be able to use RabbitMQ with Azure Functions containers in Kubernetes alongside KEDA.

How to get started with the RabbitMQ Trigger

To get started with using the RabbitMQ trigger, you need to include the extension in your function project.

.NET Functions

For .NET functions, you can pull in the RabbitMQ NuGet extension.

Install-Package Microsoft.Azure.WebJobs.Extensions.RabbitMQ -Version 0.2.2029-beta

JavaScript, TypeScript, Python, Java, and PowerShell Functions

For other functions, you need to install the extension into your project using the Azure Functions core tools

func extensions install Microsoft.Azure.WebJobs.Extensions.RabbitMQ -v 0.2.2029-beta

You can then create a function that can activate and run whenever a message is dropped in a defined RabbitMQ queue.

Example C# Trigger and Output Binding

public static void Run(
    [RabbitMQTrigger("queue", ConnectionStringSetting = "RabbitMqConnection")] string inputMessage,
    [RabbitMQ(
        ConnectionStringSetting = "RabbitMQConnection",
        QueueName = "downstream")] out string outputMessage,
    ILogger logger)
{
    outputMessage = inputMessage;
    logger.LogInformation($"RabittMQ output binding function sent message: {outputMessage}");
}

Example function.json

{
"bindings": [
    {
      "type": "rabbitMQTrigger",
      "connectionStringSetting": "RabbitMqConnection",
      "queueName": "queue",
      "deadLetterExchangeName": "dtx",
      "name": "myQueueItem"
    }
  ]
}

The connectionStringSetting resolves to an application setting (local.settings.json when developing locally) that should follow a format like: amqp://user:PASSWORD@127.0.0.1:5672.

For instructions on how to use Azure Kubernetes Service to host a RabbitMQ endpoint for testing, you can follow this guide.

Redelivery and Deadletter

Like the other queue-based triggers for Azure Functions, the RabbitMQ trigger supports retries and deadletters. If an execution results in an exception, the message can be retried. Once the message has exceeded its redelivery count threshold, we will route it to the dead letter exchange defined, where messages can end up in a poison queue. The extension will automatically append "-poison" to the original queue name when the DLX option is filled.

You can learn more about how to configure deadletter and poison queues here.

Open and Evolving

This is just the initial public preview release. Like all Azure Functions extensions, this extension is completely open source. If you have any issues, feedback, or requests - please file issues on the GitHub repository. We also welcome any contributions and additions from the community.

We're excited with this announcement and look forward to even more event sources being compatible with Azure Functions everywhere.