Azure Cosmos DB + Functions Cookbook — multi trigger
In this next Azure Cosmos DB + Azure Functions recipe, we’ll see how to create an event-driven Functions architecture with multiple Functions that indepently track changes on an Azure Cosmos DB collection.
Scenario
You need to perform multiple, independent processes when a change occurs in your Azure Cosmos DB collection and you want to implement each process as a separate Azure Function.
Ingredients
Like we used in the live migration recipe, we’ll use the Azure Cosmos DB Trigger to act as starting point for each Azure Function. Following the trigger’s documentation, we know that we need one Lease collection when using the Trigger to store the checkpoints for each Function; and while it might seem initially that you need one Lease collection for each Function monitoring your collection, you can certainly share one single Lease collection for all of them for a more cost-effective approach.
NOTE: When sharing a single Lease collection among multiple Functions, keep in mind that the provisioned RU for that Lease collection might need to get increased as you share with more and more Functions. Always check the Metrics for the Lease collection to make sure you are not incurring throttled requests.
Recipe
To share a single Lease collection among multiple Functions we’ll assign a Lease Prefix to each function. This can be achieved through the function.json file of each Function or, if you are using pre-compiled Functions, through the attributes in the CosmosDBTrigger decorator.
Let’s say you have Trigger1 and Trigger2, both with different logic, but both should receive the changes that happen in your Cosmos DB collection.
When working with the Azure Functions Portal, create two separate Functions with a Cosmos DB Trigger and edit the function.json file for each, and add an attribute called leaseCollectionPrefix with a different value for each Trigger, for example:
For the first Trigger and:
For the second one. Notice how we assigned trigger1 and trigger2 for that attribute. If you later go to your Cosmos DB account where the Lease collection is stored, you’ll see that there will be multiple leases, but the id attributes will differ because one set of leases will have the trigger1 prefix and another set, the trigger2:
If you are working with pre-compiled Functions, the way to achieve this is using the LeaseCollectionPrefix attribute in the CosmosDBTrigger , like so:
NOTE: Make sure you update your Azure Functions SDK packages (Microsoft.Azure.WebJobs.Extensions.DocumentDB in particular) in your project in case the LeaseCollectionPrefix is not available.
With this recipe, you are now able to reuse the same Lease collection for multiple independent Functions triggered by changes in your Cosmos DB collection!
Stay tuned for more recipes!
Other posts in this series:
- Azure Cosmos DB + Functions Cookbook — static client
- Azure Cosmos DB + Functions Cookbook — HTTP querying
- Azure Cosmos DB + Functions Cookbook — output collector
- Azure Cosmos DB + Functions Cookbook — live migration
- Azure Cosmos DB + Functions Cookbook — search indexing
- Azure Cosmos DB + Functions Cookbook — secure client
- Azure Cosmos DB + Functions Cookbook — Connection modes
- Azure Cosmos DB + Functions Cookbook — Multi master & preferred region
- Azure Cosmos DB + Functions Cookbook — Shared throughput and new health logs
