Azure Cosmos DB trigger for Azure Functions 2.x and higher
The Azure Cosmos DB Trigger uses the Azure Cosmos DB change feed to listen for inserts and updates across partitions. The change feed publishes new and updated items, not including updates from deletions.
For information on setup and configuration details, see the overview.
Cosmos DB scaling decisions for the Consumption and Premium plans are done via target-based scaling. For more information, see Target-based scaling.
Important
This article uses tabs to support multiple versions of the Node.js programming model. The v4 model is generally available and is designed to have a more flexible and intuitive experience for JavaScript and TypeScript developers. For more details about how the v4 model works, refer to the Azure Functions Node.js developer guide. To learn more about the differences between v3 and v4, refer to the migration guide.
Azure Functions supports two programming models for Python. The way that you define your bindings depends on your chosen programming model.
The Python v2 programming model lets you define bindings using decorators directly in your Python function code. For more information, see the Python developer guide.
This article supports both programming models.
Example
The usage of the trigger depends on the extension package version and the C# modality used in your function app, which can be one of the following:
An isolated worker process class library compiled C# function runs in a process isolated from the runtime.
The following examples depend on the extension version for the given C# mode.
This example refers to a simple ToDoItem
type:
public class ToDoItem
{
public string? Id { get; set; }
public string? Description { get; set; }
}
The following function is invoked when there are inserts or updates in the specified database and collection.
[Function("CosmosTrigger")]
public void Run([CosmosDBTrigger(
databaseName: "ToDoItems",
containerName:"TriggerItems",
Connection = "CosmosDBConnection",
LeaseContainerName = "leases",
CreateLeaseContainerIfNotExists = true)] IReadOnlyList<ToDoItem> todoItems,
FunctionContext context)
{
if (todoItems is not null && todoItems.Any())
{
foreach (var doc in todoItems)
{
_logger.LogInformation("ToDoItem: {desc}", doc.Description);
}
}
}
This function is invoked when there are inserts or updates in the specified database and container.
Because of schema changes in the Azure Cosmos DB SDK, version 4.x of the Azure Cosmos DB extension requires azure-functions-java-library V3.0.0 for Java functions.
@FunctionName("CosmosDBTriggerFunction")
public void run(
@CosmosDBTrigger(
name = "items",
databaseName = "ToDoList",
containerName = "Items",
leaseContainerName="leases",
connection = "AzureCosmosDBConnection",
createLeaseContainerIfNotExists = true
)
Object inputItem,
final ExecutionContext context
) {
context.getLogger().info("Items modified: " + inputItems.size());
}
In the Java functions runtime library, use the @CosmosDBTrigger
annotation on parameters whose value would come from Azure Cosmos DB. This annotation can be used with native Java types, POJOs, or nullable values using Optional<T>
.
The following example shows an Azure Cosmos DB trigger TypeScript function. The function writes log messages when Azure Cosmos DB records are added or modified.
import { app, InvocationContext } from '@azure/functions';
export async function cosmosDBTrigger1(documents: unknown[], context: InvocationContext): Promise<void> {
context.log(`Cosmos DB function processed ${documents.length} documents`);
}
app.cosmosDB('cosmosDBTrigger1', {
connection: '<connection-app-setting>',
databaseName: 'Tasks',
containerName: 'Items',
createLeaseContainerIfNotExists: true,
handler: cosmosDBTrigger1,
});
The following example shows an Azure Cosmos DB trigger JavaScript function. The function writes log messages when Azure Cosmos DB records are added or modified.
const { app } = require('@azure/functions');
app.cosmosDB('cosmosDBTrigger1', {
connection: '<connection-app-setting>',
databaseName: 'Tasks',
containerName: 'Items',
createLeaseContainerIfNotExists: true,
handler: (documents, context) => {
context.log(`Cosmos DB function processed ${documents.length} documents`);
},
});
The following example shows how to run a function as data changes in Azure Cosmos DB.
{
"type": "cosmosDBTrigger",
"name": "documents",
"direction": "in",
"leaseCollectionName": "leases",
"connectionStringSetting": "<connection-app-setting>",
"databaseName": "Tasks",
"collectionName": "Items",
"createLeaseCollectionIfNotExists": true
}
Note that some of the binding attribute names changed in version 4.x of the Azure Cosmos DB extension.
In the run.ps1 file, you have access to the document that triggers the function via the $Documents
parameter.
param($Documents, $TriggerMetadata)
Write-Host "First document Id modified : $($Documents[0].id)"
The following example shows an Azure Cosmos DB trigger binding. The example depends on whether you use the v1 or v2 Python programming model.
import logging
import azure.functions as func
app = func.FunctionApp()
@app.function_name(name="CosmosDBTrigger")
@app.cosmos_db_trigger(name="documents",
connection="CONNECTION_SETTING",
database_name="DB_NAME",
container_name="CONTAINER_NAME",
lease_container_name="leases",
create_lease_container_if_not_exists="true")
def test_function(documents: func.DocumentList) -> str:
if documents:
logging.info('Document id: %s', documents[0]['id'])
Attributes
Both in-process and isolated process C# libraries use the CosmosDBTriggerAttribute to define the function. C# script instead uses a function.json configuration file as described in the C# scripting guide.
Attribute property | Description |
---|---|
Connection | The name of an app setting or setting collection that specifies how to connect to the Azure Cosmos DB account being monitored. For more information, see Connections. |
DatabaseName | The name of the Azure Cosmos DB database with the container being monitored. |
ContainerName | The name of the container being monitored. |
LeaseConnection | (Optional) The name of an app setting or setting collection that specifies how to connect to the Azure Cosmos DB account that holds the lease container. When not set, the Connection value is used. This parameter is automatically set when the binding is created in the portal. The connection string for the leases container must have write permissions. |
LeaseDatabaseName | (Optional) The name of the database that holds the container used to store leases. When not set, the value of the databaseName setting is used. |
LeaseContainerName | (Optional) The name of the container used to store leases. When not set, the value leases is used. |
CreateLeaseContainerIfNotExists | (Optional) When set to true , the leases container is automatically created when it doesn't already exist. The default value is false . When using Microsoft Entra identities if you set the value to true , creating containers is not an allowed operation and your Function won't be able to start. |
LeasesContainerThroughput | (Optional) Defines the number of Request Units to assign when the leases container is created. This setting is only used when CreateLeaseContainerIfNotExists is set to true . This parameter is automatically set when the binding is created using the portal. |
LeaseContainerPrefix | (Optional) When set, the value is added as a prefix to the leases created in the Lease container for this function. Using a prefix allows two separate Azure Functions to share the same Lease container by using different prefixes. |
FeedPollDelay | (Optional) The time (in milliseconds) for the delay between polling a partition for new changes on the feed, after all current changes are drained. Default is 5,000 milliseconds, or 5 seconds. |
LeaseAcquireInterval | (Optional) When set, it defines, in milliseconds, the interval to kick off a task to compute if partitions are distributed evenly among known host instances. Default is 13000 (13 seconds). |
LeaseExpirationInterval | (Optional) When set, it defines, in milliseconds, the interval for which the lease is taken on a lease representing a partition. If the lease is not renewed within this interval, it will cause it to expire and ownership of the partition will move to another instance. Default is 60000 (60 seconds). |
LeaseRenewInterval | (Optional) When set, it defines, in milliseconds, the renew interval for all leases for partitions currently held by an instance. Default is 17000 (17 seconds). |
MaxItemsPerInvocation | (Optional) When set, this property sets the maximum number of items received per Function call. If operations in the monitored container are performed through stored procedures, transaction scope is preserved when reading items from the change feed. As a result, the number of items received could be higher than the specified value so that the items changed by the same transaction are returned as part of one atomic batch. |
StartFromBeginning | (Optional) This option tells the Trigger to read changes from the beginning of the container's change history instead of starting at the current time. Reading from the beginning only works the first time the trigger starts, as in subsequent runs, the checkpoints are already stored. Setting this option to true when there are leases already created has no effect. |
StartFromTime | (Optional) Gets or sets the date and time from which to initialize the change feed read operation. The recommended format is ISO 8601 with the UTC designator, such as 2021-02-16T14:19:29Z . This is only used to set the initial trigger state. After the trigger has a lease state, changing this value has no effect. |
PreferredLocations | (Optional) Defines preferred locations (regions) for geo-replicated database accounts in the Azure Cosmos DB service. Values should be comma-separated. For example, "East US,South Central US,North Europe". |
Decorators
Applies only to the Python v2 programming model.
For Python v2 functions defined using a decorator, the following properties on the cosmos_db_trigger
:
Property | Description |
---|---|
arg_name |
The variable name used in function code that represents the list of documents with changes. |
database_name |
The name of the Azure Cosmos DB database with the collection being monitored. |
collection_name |
The name of the Azure Cosmos DB collection being monitored. |
connection |
The connection string of the Azure Cosmos DB being monitored. |
For Python functions defined by using function.json, see the Configuration section.
Annotations
Because of schema changes in the Azure Cosmos DB SDK, version 4.x of the Azure Cosmos DB extension requires azure-functions-java-library V3.0.0 for Java functions.
Use the @CosmosDBTrigger
annotation on parameters that read data from Azure Cosmos DB. The annotation supports the following properties:
Attribute property | Description |
---|---|
connection | The name of an app setting or setting collection that specifies how to connect to the Azure Cosmos DB account being monitored. For more information, see Connections. |
name | The name of the function. |
databaseName | The name of the Azure Cosmos DB database with the container being monitored. |
containerName | The name of the container being monitored. |
leaseConnectionStringSetting | (Optional) The name of an app setting or setting collection that specifies how to connect to the Azure Cosmos DB account that holds the lease container. When not set, the Connection value is used. This parameter is automatically set when the binding is created in the portal. The connection string for the leases container must have write permissions. |
leaseDatabaseName | (Optional) The name of the database that holds the container used to store leases. When not set, the value of the databaseName setting is used. |
leaseContainerName | (Optional) The name of the container used to store leases. When not set, the value leases is used. |
createLeaseContainerIfNotExists | (Optional) When set to true , the leases container is automatically created when it doesn't already exist. The default value is false . When using Microsoft Entra identities if you set the value to true , creating containers isn't an allowed operation and your Function won't start. |
leasesContainerThroughput | (Optional) Defines the number of Request Units to assign when the leases container is created. This setting is only used when CreateLeaseContainerIfNotExists is set to true . This parameter is automatically set when the binding is created using the portal. |
leaseContainerPrefix | (Optional) When set, the value is added as a prefix to the leases created in the Lease container for this function. Using a prefix allows two separate Azure Functions to share the same Lease container by using different prefixes. |
feedPollDelay | (Optional) The time (in milliseconds) for the delay between polling a partition for new changes on the feed, after all current changes are drained. Default is 5,000 milliseconds, or 5 seconds. |
leaseAcquireInterval | (Optional) When set, it defines, in milliseconds, the interval to kick off a task to compute if partitions are distributed evenly among known host instances. Default is 13000 (13 seconds). |
leaseExpirationInterval | (Optional) When set, it defines, in milliseconds, the interval for which the lease is taken on a lease representing a partition. If the lease isn't renewed within this interval, it will expire and ownership of the partition moves to another instance. Default is 60000 (60 seconds). |
leaseRenewInterval | (Optional) When set, it defines, in milliseconds, the renew interval for all leases for partitions currently held by an instance. Default is 17000 (17 seconds). |
maxItemsPerInvocation | (Optional) When set, this property sets the maximum number of items received per Function call. If operations in the monitored container are performed through stored procedures, transaction scope is preserved when reading items from the change feed. As a result, the number of items received could be higher than the specified value so that the items changed by the same transaction are returned as part of one atomic batch. |
startFromBeginning | (Optional) This option tells the Trigger to read changes from the beginning of the container's change history instead of starting at the current time. Reading from the beginning only works the first time the trigger starts, as in subsequent runs, the checkpoints are already stored. Setting this option to true when there are leases already created has no effect. |
preferredLocations | (Optional) Defines preferred locations (regions) for geo-replicated database accounts in the Azure Cosmos DB service. Values should be comma-separated. For example, "East US,South Central US,North Europe". |
Configuration
Applies only to the Python v1 programming model.
The following table explains the binding configuration properties that you set in the function.json file, where properties differ by extension version:
function.json property | Description |
---|---|
type | Must be set to cosmosDBTrigger . |
direction | Must be set to in . This parameter is set automatically when you create the trigger in the Azure portal. |
name | The variable name used in function code that represents the list of documents with changes. |
connection | The name of an app setting or setting collection that specifies how to connect to the Azure Cosmos DB account being monitored. For more information, see Connections. |
databaseName | The name of the Azure Cosmos DB database with the container being monitored. |
containerName | The name of the container being monitored. |
leaseConnection | (Optional) The name of an app setting or setting container that specifies how to connect to the Azure Cosmos DB account that holds the lease container. When not set, the connection value is used. This parameter is automatically set when the binding is created in the portal. The connection string for the leases container must have write permissions. |
leaseDatabaseName | (Optional) The name of the database that holds the container used to store leases. When not set, the value of the databaseName setting is used. |
leaseContainerName | (Optional) The name of the container used to store leases. When not set, the value leases is used. |
createLeaseContainerIfNotExists | (Optional) When set to true , the leases container is automatically created when it doesn't already exist. The default value is false . When using Microsoft Entra identities if you set the value to true , creating containers is not an allowed operation and your Function won't be able to start. |
leasesContainerThroughput | (Optional) Defines the number of Request Units to assign when the leases container is created. This setting is only used when createLeaseContainerIfNotExists is set to true . This parameter is automatically set when the binding is created using the portal. |
leaseContainerPrefix | (Optional) When set, the value is added as a prefix to the leases created in the Lease container for this function. Using a prefix allows two separate Azure Functions to share the same Lease container by using different prefixes. |
feedPollDelay | (Optional) The time (in milliseconds) for the delay between polling a partition for new changes on the feed, after all current changes are drained. Default is 5,000 milliseconds, or 5 seconds. |
leaseAcquireInterval | (Optional) When set, it defines, in milliseconds, the interval to kick off a task to compute if partitions are distributed evenly among known host instances. Default is 13000 (13 seconds). |
leaseExpirationInterval | (Optional) When set, it defines, in milliseconds, the interval for which the lease is taken on a lease representing a partition. If the lease is not renewed within this interval, it will cause it to expire and ownership of the partition will move to another instance. Default is 60000 (60 seconds). |
leaseRenewInterval | (Optional) When set, it defines, in milliseconds, the renew interval for all leases for partitions currently held by an instance. Default is 17000 (17 seconds). |
maxItemsPerInvocation | (Optional) When set, this property sets the maximum number of items received per Function call. If operations in the monitored container are performed through stored procedures, transaction scope is preserved when reading items from the change feed. As a result, the number of items received could be higher than the specified value so that the items changed by the same transaction are returned as part of one atomic batch. |
startFromBeginning | (Optional) This option tells the Trigger to read changes from the beginning of the container's change history instead of starting at the current time. Reading from the beginning only works the first time the trigger starts, as in subsequent runs, the checkpoints are already stored. Setting this option to true when there are leases already created has no effect. |
startFromTime | (Optional) Gets or sets the date and time from which to initialize the change feed read operation. The recommended format is ISO 8601 with the UTC designator, such as 2021-02-16T14:19:29Z . This is only used to set the initial trigger state. After the trigger has a lease state, changing this value has no effect. |
preferredLocations | (Optional) Defines preferred locations (regions) for geo-replicated database accounts in the Azure Cosmos DB service. Values should be comma-separated. For example, "East US,South Central US,North Europe". |
See the Example section for complete examples.
Usage
The trigger requires a second collection that it uses to store leases over the partitions. Both the collection being monitored and the collection that contains the leases must be available for the trigger to work.
Important
If multiple functions are configured to use an Azure Cosmos DB trigger for the same collection, each of the functions should use a dedicated lease collection or specify a different LeaseCollectionPrefix
for each function. Otherwise, only one of the functions is triggered. For information about the prefix, see the Attributes section.
Important
If multiple functions are configured to use an Azure Cosmos DB trigger for the same collection, each of the functions should use a dedicated lease collection or specify a different leaseCollectionPrefix
for each function. Otherwise, only one of the functions is triggered. For information about the prefix, see the Annotations section.
Important
If multiple functions are configured to use an Azure Cosmos DB trigger for the same collection, each of the functions should use a dedicated lease collection or specify a different leaseCollectionPrefix
for each function. Otherwise, only one of the functions will be triggered. For information about the prefix, see the Configuration section.
The trigger doesn't indicate whether a document was updated or inserted, it just provides the document itself. If you need to handle updates and inserts differently, you could do that by implementing timestamp fields for insertion or update.
The parameter type supported by the Azure Cosmos DB trigger depends on the Functions runtime version, the extension package version, and the C# modality used.
When you want the function to process a single document, the Cosmos DB trigger can bind to the following types:
Type | Description |
---|---|
JSON serializable types | Functions tries to deserialize the JSON data of the document from the Cosmos DB change feed into a plain-old CLR object (POCO) type. |
When you want the function to process a batch of documents, the Cosmos DB trigger can bind to the following types:
Type | Description |
---|---|
IEnumerable<T> where T is a JSON serializable type |
An enumeration of entities included in the batch. Each entry represents one document from the Cosmos DB change feed. |
Connections
The connectionStringSetting
/connection
and leaseConnectionStringSetting
/leaseConnection
properties are references to environment configuration which specifies how the app should connect to Azure Cosmos DB. They may specify:
- The name of an application setting containing a connection string
- The name of a shared prefix for multiple application settings, together defining an identity-based connection. This option is only available for the
connection
andleaseConnection
versions from version 4.x or higher of the extension.
If the configured value is both an exact match for a single setting and a prefix match for other settings, the exact match is used.
Connection string
The connection string for your database account should be stored in an application setting with a name matching the value specified by the connection property of the binding configuration.
Identity-based connections
If you are using version 4.x or higher of the extension, instead of using a connection string with a secret, you can have the app use an Microsoft Entra identity. To do this, you would define settings under a common prefix which maps to the connection property in the trigger and binding configuration.
In this mode, the extension requires the following properties:
Property | Environment variable template | Description | Example value |
---|---|---|---|
Account Endpoint | <CONNECTION_NAME_PREFIX>__accountEndpoint |
The Azure Cosmos DB account endpoint URI. | https://<database_account_name>.documents.azure.com:443/ |
Additional properties may be set to customize the connection. See Common properties for identity-based connections.
When hosted in the Azure Functions service, identity-based connections use a managed identity. The system-assigned identity is used by default, although a user-assigned identity can be specified with the credential
and clientID
properties. Note that configuring a user-assigned identity with a resource ID is not supported. When run in other contexts, such as local development, your developer identity is used instead, although this can be customized. See Local development with identity-based connections.
Grant permission to the identity
Whatever identity is being used must have permissions to perform the intended actions. For most Azure services, this means you need to assign a role in Azure RBAC, using either built-in or custom roles which provide those permissions.
Important
Some permissions might be exposed by the target service that are not necessary for all contexts. Where possible, adhere to the principle of least privilege, granting the identity only required privileges. For example, if the app only needs to be able to read from a data source, use a role that only has permission to read. It would be inappropriate to assign a role that also allows writing to that service, as this would be excessive permission for a read operation. Similarly, you would want to ensure the role assignment is scoped only over the resources that need to be read.
Cosmos DB does not use Azure RBAC for data operations. Instead, it uses a Cosmos DB built-in RBAC system which is built on similar concepts. You will need to create a role assignment that provides access to your database account at runtime. Azure RBAC Management roles like Owner are not sufficient. The following table shows built-in roles that are recommended when using the Azure Cosmos DB extension in normal operation. Your application may require additional permissions based on the code you write.
Binding type | Example built-in roles1 |
---|---|
Trigger2 | Cosmos DB Built-in Data Contributor |
Input binding | Cosmos DB Built-in Data Reader |
Output binding | Cosmos DB Built-in Data Contributor |
1 These roles cannot be used in an Azure RBAC role assignment. See the Cosmos DB built-in RBAC system documentation for details on how to assign these roles.
2 When using identity, Cosmos DB treats container creation as a management operation. It is not available as a data-plane operation for the trigger. You will need to ensure that you create the containers needed by the trigger (including the lease container) before setting up your function.