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.
Top comments (4)
There's isn't a hosted RabbitMQ service in Azure in there?
any way to specify durability property for queue in the trigger??
I am really excited about it. Going through source, looking forward to contribute.
sad, dont work here :(