Azure Functions Queue Storage Bindings

This article explains how to use Queue Storage bindings with Azure Functions. Queue Storage bindings enable you to write Azure Functions that react to messages in an Azure Queue Storage queue. You can also configure functions to send messages to a queue.

Input and Output Bindings

Azure Functions supports two types of Queue Storage bindings:

Input Binding: Reads a message from a queue and passes it as a parameter to your function.
Output Binding: Writes a message to a queue as a result of your function execution.

Queue Input Binding

An input binding for Queue Storage allows your function to be triggered by a message appearing in a specified queue. The message content is then passed to your function as input.

Example (C#):


using Microsoft.Azure.WebJobs;
using Microsoft.Extensions.Logging;

public static class QueueTriggerFunction
{
    [FunctionName("QueueTriggerCSharp")]
    public static void Run(
        [QueueTrigger("myqueue-items", Connection = "AzureWebJobsStorage")] string myQueueItem,
        ILogger log)
    {
        log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
    }
}

Example (JavaScript):


module.exports = async function (context, myQueueItem) {
    context.log('JavaScript queue trigger function processed work item', myQueueItem);
};

Attributes and Configuration

The core of the input binding is defined by attributes (in .NET) or configuration (in JavaScript, Python, etc.). Key properties include:

queueName: The name of the queue to monitor.
Connection: The name of an app setting that contains the connection string for the storage account. If omitted, the default AzureWebJobsStorage connection is used.

Queue Output Binding

An output binding for Queue Storage allows your function to send messages to a queue. This is useful for scenarios where a function performs some processing and then needs to queue further work for another function or service.

Example (C#):


using Microsoft.Azure.WebJobs;
using Microsoft.Extensions.Logging;

public static class QueueOutputFunction
{
    [FunctionName("QueueOutputCSharp")]
    public static void Run(
        [TimerTrigger("0 */5 * * * *")] TimerInfo myTimer,
        [Queue("output-queue", Connection = "AzureWebJobsStorage")] out string outputQueueItem,
        ILogger log)
    {
        log.LogInformation("Timer trigger function executed at: " + myTimer.ScheduleStatus.Next);

        outputQueueItem = $"New queue message generated at: {DateTime.Now}";
        log.LogInformation($"Queue message sent: {outputQueueItem}");
    }
}

Example (JavaScript):


module.exports = async function (context) {
    context.log('JavaScript queue function processing a request.');
    const message = `New queue message generated at: ${new Date().toISOString()}`;
    context.bindings.outputQueueItem = message;
    context.log(`Queue message sent: ${message}`);
};

Attributes and Configuration

Similar to input bindings, output bindings are configured. The output binding is often represented by an out parameter in .NET or by assigning a value to a binding name in other languages.

queueName: The name of the queue to which the message will be sent.
Connection: The name of an app setting for the connection string.

Binding Details

Feature	Description
`queueName`	Specifies the name of the queue.
`Connection`	Name of the app setting containing the Azure Storage connection string.
`DeleteMessage` (Input)	Determines if the message should be deleted from the queue after successful processing. Defaults to `true`.
`PopReceipt` (Input)	Used internally to manage message deletion.
`MessageId` (Input)	Used internally to manage message deletion.
`NextVisibleTime` (Input)	Used internally to manage message visibility.

Important Considerations

When using queue triggers, ensure your Connection setting points to a valid Azure Storage account. If no connection is specified, the default AzureWebJobsStorage connection is used.

For output bindings, the default behavior is to create the queue if it doesn't exist.

Advanced Scenarios

You can also use POCOs (Plain Old CLR Objects) for messages, handle JSON payloads, and configure advanced error handling and retries.

Microsoft Docs