Azure Queue storage trigger and bindings for Azure Functions overview
Azure Functions can run as new Azure Queue storage messages are created and can write queue messages within a function.
Action | Type |
---|---|
Run a function as queue storage data changes | Trigger |
Write queue storage messages | Output binding |
Install extension
The extension NuGet package you install depends on the C# mode you're using in your function app:
Functions execute in an isolated C# worker process. To learn more, see Guide for running C# Azure Functions in an isolated worker process.
The functionality of the extension varies depending on the extension version:
This version introduces the ability to connect using an identity instead of a secret. For a tutorial on configuring your function apps with managed identities, see the creating a function app with identity-based connections tutorial.
This version allows you to bind to types from Azure.Storage.Queues.
Add the extension to your project by installing the NuGet package, version 5.x.
Using the .NET CLI:
dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues --version 5.0.0
Note
Blob Storage, Queue Storage, and Table Storage now use separate extensions and are referenced individually. For example, to use both Blob Storage and Queue Storage triggers and bindings in your .NET isolated-process app, you should add the following packages to your project:
- Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs
- Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
The Azure Cosmos DB for Table extension doesn't currently support isolated process. If your app needs to use Azure Tables, you must use Microsoft.Azure.Functions.Worker.Extensions.Storage, version 4.x. This same package also has a 5.x version, which references the packages for Blob Storage and Queue Storage only. When referencing these newer split packages, make sure you aren't also referencing an older version of the combined storage package, which would cause conflicts between the two definitions of the same bindings.
Install bundle
The Blob storage binding is part of an extension bundle, which is specified in your host.json project file. You may need to modify this bundle to change the version of the binding, or if bundles aren't already installed. To learn more, see extension bundle.
This version introduces the ability to connect using an identity instead of a secret. For a tutorial on configuring your function apps with managed identities, see the creating a function app with identity-based connections tutorial.
You can add this version of the extension from the preview extension bundle v3 by adding or replacing the following code in your host.json
file:
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[3.3.0, 4.0.0)"
}
}
To learn more, see Update your extensions.
Binding types
The binding types supported for .NET depend on both the extension version and C# execution mode, which can be one of the following:
An isolated worker process class library compiled C# function runs in a process isolated from the runtime.
Choose a version to see binding type details for the mode and version.
The isolated worker process supports parameter types according to the tables below. Support for binding to types from Azure.Storage.Queues is in preview.
Queue trigger
The queue trigger can bind to the following types:
Type | Description |
---|---|
string |
The message content as a string. Use when the message is simple text.. |
byte[] |
The bytes of the message. |
JSON serializable types | When a queue message contains JSON data, Functions tries to deserialize the JSON data into a plain-old CLR object (POCO) type. |
QueueMessage | (Preview1) The message. |
BinaryData | (Preview1) The bytes of the message. |
1 To use these types, you need to reference Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues 5.1.3-preview1 or later and the common dependencies for SDK type bindings.
Queue output binding
When you want the function to write a single message, the queue output binding can bind to the following types:
Type | Description |
---|---|
string |
The message content as a string. Use when the message is simple text. |
byte[] |
The bytes of the message. |
JSON serializable types | An object representing the content of a JSON message. Functions tries to serialize a plain-old CLR object (POCO) type into JSON data. |
When you want the function to write multiple messages, the queue output binding can bind to the following types:
Type | Description |
---|---|
T[] where T is one of the single message types |
An array containing content for multiple messages. Each entry represents one message. |
For other output scenarios, create and use types from Azure.Storage.Queues directly.
host.json settings
This section describes the configuration settings available for this binding in versions 2.x and higher. Settings in the host.json file apply to all functions in a function app instance. The example host.json file below contains only the version 2.x+ settings for this binding. For more information about function app configuration settings in versions 2.x and later versions, see host.json reference for Azure Functions.
Note
For a reference of host.json in Functions 1.x, see host.json reference for Azure Functions 1.x.
{
"version": "2.0",
"extensions": {
"queues": {
"maxPollingInterval": "00:00:02",
"visibilityTimeout" : "00:00:30",
"batchSize": 16,
"maxDequeueCount": 5,
"newBatchThreshold": 8,
"messageEncoding": "base64"
}
}
}
Property | Default | Description |
---|---|---|
maxPollingInterval | 00:01:00 | The maximum interval between queue polls. The minimum interval is 00:00:00.100 (100 ms). Intervals increment up to maxPollingInterval . The default value of maxPollingInterval is 00:01:00 (1 min). maxPollingInterval must not be less than 00:00:00.100 (100 ms). In Functions 2.x and later, the data type is a TimeSpan . In Functions 1.x, it is in milliseconds. |
visibilityTimeout | 00:00:00 | The time interval between retries when processing of a message fails. |
batchSize | 16 | The number of queue messages that the Functions runtime retrieves simultaneously and processes in parallel. When the number being processed gets down to the newBatchThreshold , the runtime gets another batch and starts processing those messages. So the maximum number of concurrent messages being processed per function is batchSize plus newBatchThreshold . This limit applies separately to each queue-triggered function. If you want to avoid parallel execution for messages received on one queue, you can set batchSize to 1. However, this setting eliminates concurrency as long as your function app runs only on a single virtual machine (VM). If the function app scales out to multiple VMs, each VM could run one instance of each queue-triggered function.The maximum batchSize is 32. |
maxDequeueCount | 5 | The number of times to try processing a message before moving it to the poison queue. |
newBatchThreshold | N*batchSize/2 | Whenever the number of messages being processed concurrently gets down to this number, the runtime retrieves another batch.N represents the number of vCPUs available when running on App Service or Premium Plans. Its value is 1 for the Consumption Plan. |
messageEncoding | base64 | This setting is only available in extension bundle version 5.0.0 and higher. It represents the encoding format for messages. Valid values are base64 and none . |