Azure Cosmos DB + Functions Cookbook — output collector

Published in

Microsoft Azure

3 min readJan 30, 2018

This new post in this series of quick and easy recipes you can use with Azure Cosmos DB and Azure Functions is dedicated to collecting and persisting data.

Scenario

You want to persist data that comes from an event source (Messages in a queue, notifications in an Event Grid, an HTTP payload, a Service Bus message, and a long etc..) into your Azure Cosmos DB account in a simple, scalable and efficient way.

Ingredients

Since this scenario is about persisting the data, there are multiple inputs we could pick, so I’ll go with the simplest one that will let me show you all the scenarios, the HTTP Trigger, and we’ll use the Azure Cosmos DB Output Binding to work the saving magic. And when I say magic, I am referring to the first post in the series where we learnt about the performance benefits of keeping a static client, because the Output Binding will do this for you and you won’t have to worry about it!

IMPORTANT NOTE: The Cosmos DB Output Binding uses the SQL API to persist information, please do not use it with Mongo API enabled accounts. While it is technically possible to use with Graph and Table API accounts, it is your responsibility to maintain the correct Graph (edges and vertexes) and Table (rows) schema.

Recipe

I will use the HTTP Trigger to send a custom JSON payload to my Azure Function, but like I said, the input could be anything that resembles a group of data items. Given the NoSQL nature of Azure Cosmos DB, there is no schema that you need to maintain.

To store the data, I’m going to use a not-so-well documented jewel in the Azure Functions Output bindings called the IAsyncCollector. There are plenty of documented samples of how to store a single document, but what if the input contains multiple documents and we want to process them all in one execution? That’s where the IAsyncCollector comes in :)

Let’s start with our function.json file, I will define the httpTrigger input, an http output to send some response to the client and finally the documentDB output with some configuration properties (you can see the full configuration options here).

Now, I will be sending an array of objects I want to store in my database as a JSON payload. Here is a sample payload:

Storing Johns

Since the input is HTTP, I can make use of the automatic JSON deserialization and map it to a C# class MyClass , notice that the name of the httpTrigger input is called classes and I’m going to receive it not as an HttpRequestMessage but as MyClass[] parameter called classes . Afterwards, the output will be of type IAsyncCollector<MyClass> (notice the match on the naming on the function.json ) which will enable me to save multiple documents instead of just one. Let’s see the run.csx :

And that’s pretty much it! You didn’t have to create and maintain a connection, nor deal with anything other than calling the AddAsync method with the data you wanted to store, extremely simple!

You don’t really need to define a class for the IAsyncCollector, you could use dynamic too, but I wanted to show that you can leverage the automatic JSON deserialization if needed.

NodeJS is equally easy, the req.body will contain the object representation (an array of objects in this case) and we can use the context.bindings.documentsToStore accessor as an Array where you push each document in order to save it. Here is the index.js file:

Now you can pick and play with other input types that match your scenario and use the IAsyncCollector to store multiple documents in a single execution.

Stay tuned for more recipes!

Azure Cosmos DB + Functions Cookbook — output collector

Scenario

Ingredients

Recipe

Written by Matías Quaranta