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 extensionThe extension NuGet package you install depends on the C# mode you're using in your function app:
The functionality of the extension varies depending on the extension version:
This section describes using a class library. For C# scripting, you would need to instead install the extension bundle, version 4.x.
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.
This extension is available by installing the Microsoft.Azure.WebJobs.Extensions.Storage.Queues NuGet package, version 5.x.
Using the .NET CLI:
dotnet add package Microsoft.Azure.WebJobs.Extensions.Storage.Queues
Note
Azure Blobs, Azure Queues, and Azure Tables now use separate extensions and are referenced individually. For example, to use the triggers and bindings for all three services in your .NET in-process app, you should add the following packages to your project:
Previously, the extensions shipped together as Microsoft.Azure.WebJobs.Extensions.Storage, version 4.x. This same package also has a 5.x version, which references the split packages for blobs and queues only. When upgrading your package references from older versions, you may therefore need to additionally reference the new Microsoft.Azure.WebJobs.Extensions.Tables NuGet package. Also, when referencing these newer split packages, make sure you are not referencing an older version of the combined storage package, as this will result in conflicts from two definitions of the same bindings.
This section describes using a class library. For C# scripting, you would need to instead install the extension bundle, version 2.x.
Working with the trigger and bindings requires that you reference the appropriate NuGet package. Install the NuGet package, version 3.x or 4.x.
Functions 1.x apps automatically have a reference the Microsoft.Azure.WebJobs NuGet package, version 2.x.
In Functions 1.x, the Storage triggers and bindings use version 7.2.1 of the Azure Storage SDK (WindowsAzure.Storage NuGet package). If you reference a different version of the Storage SDK, and you bind to a Storage SDK type in your function signature, the Functions runtime may report that it can't bind to that type. The solution is to make sure your project references WindowsAzure.Storage 7.2.1.
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.
This version supports configuration of triggers and bindings through .NET Aspire integration.
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
Note
Azure Blobs, Azure Queues, and Azure Tables now use separate extensions and are referenced individually. For example, to use the triggers and bindings for all three services in your .NET isolated-process app, you should add the following packages to your project:
Previously, the extensions shipped together as Microsoft.Azure.Functions.Worker.Extensions.Storage, version 4.x. This same package also has a 5.x version, which references the split packages for blobs and queues only. When upgrading your package references from older versions, you may therefore need to additionally reference the new Microsoft.Azure.Functions.Worker.Extensions.Tables NuGet package. Also, when referencing these newer split packages, make sure you are not referencing an older version of the combined storage package, as this will result in conflicts from two definitions of the same bindings.
Add the extension to your project by installing the NuGet package, version 4.x.
Functions version 1.x doesn't support the isolated worker process.
Install bundleThe 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.
Binding typesThe 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.
An in-process class library is a compiled C# function runs in the same process as the Functions runtime.
Choose a version to see binding type details for the mode and version.
The Azure Queues extension supports parameter types according to the table below.
Binding scenario Parameter types Queue trigger QueueMessagestring
byte[]
string
byte[]
ICollector<T> or IAsyncCollector<T> where T is one of the single message types
1 Messages containing JSON data can be deserialized into known plain-old CLR object (POCO) types.
Earlier versions of the extension exposed types from the now deprecated Microsoft.Azure.Storage.Queues namespace. Newer types from Azure.Storage.Queues are exclusive to Extension 5.x+.
This version of the extension supports parameter types according to the table below.
1 Messages containing JSON data can be deserialized into known plain-old CLR object (POCO) types.
Functions 1.x exposed types from the deprecated Microsoft.WindowsAzure.Storage namespace. Newer types from Azure.Storage.Queues are exclusive to the Extension 5.x+. To use these, you will need to upgrade your application to Functions 4.x.
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 Descriptionstring 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. QueueMessage1 The message. BinaryData1 The bytes of the message.
1 To use these types, you need to reference Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues 5.2.0 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 Descriptionstring 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 DescriptionT[] 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 a QueueClient with other types from Azure.Storage.Queues directly. See Register Azure clients for an example of using dependency injection to create a client type from the Azure SDK.
Earlier versions of extensions in the isolated worker process only support binding to string types. Additional options are available to the Extension 5.x.
Functions version 1.x doesn't support the isolated worker process. To use the isolated worker model, upgrade your application to Functions 4.x.
host.json settingsThis section describes the configuration settings available for this binding in version 2.x and later. Settings in the host.json file apply to all functions in a function app instance. For more information about function app configuration settings, see host.json reference for Azure Functions.
{
"version": "2.0",
"extensions": {
"queues": {
"maxPollingInterval": "00:00:02",
"visibilityTimeout" : "00:00:30",
"batchSize": 16,
"maxDequeueCount": 5,
"newBatchThreshold": 8,
"messageEncoding": "base64"
}
}
}
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.
N represents the number of vCPUs available when running on App Service or Premium Plans. Its value is 1 for the Consumption Plan.
base64 and none. Next steps
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4