Azure Functions: Input and Output Bindings

1. Understanding Triggers, Input, and Output Bindings

In Azure Functions, bindings provide a declarative way to connect to data from within your code. They come in three directions:

• Trigger: A special input binding that starts your function. A function must have exactly one trigger (e.g., HttpTrigger, QueueTrigger). You've already used the HTTP trigger.
• Input Binding: Provides data to your function as a parameter. It's a way to read data from a source without using an SDK client.
• Output Binding: A destination for data from your function. Typically, the return value of your function is sent to the output binding.

The primary benefit is simplicity. You declare the connection with an attribute, and the runtime handles opening connections, reading/writing data, and closing connections.

This short video explains the concept clearly.

2. Implementing an Output Binding

Let's start with the most common use case: taking data from a trigger and writing it somewhere. We'll modify the HTTP-triggered function you built in the previous lesson to write a document to an Azure Cosmos DB container. Since you have a strong background in C#, you'll find that this is mainly about applying the correct attributes and NuGet packages.

For functions using the .NET Isolated Worker model (which you are), you typically define a single output binding by applying an attribute to the function method and using the method's return value as the data to be written.

Let's look at the official documentation to see how this is structured.

Now, let's apply this concept. The following resource provides a clean, modern example of an HTTP trigger writing to Cosmos DB.

1. Add the NuGet Package: From the command line in your project directory, run dotnet add package Microsoft.Azure.Functions.Worker.Extensions.CosmosDB.
2. Modify Your Function: Replace your existing HTTP-triggered function's code with the code from the example. You can simplify the Run method's return object for now to just this, which we'll trigger from a query string:

   public object Run(
       [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "orders")] HttpRequestData req)
   {
       string name = req.Query["name"]; // Read 'name' from query string
   
       return new
       {
           // a unique id is required
           id = Guid.NewGuid().ToString(),
           customerName = name,
           createdAt = DateTime.UtcNow
       };
   }
   

3. Configure Settings: Open your local.settings.json file. You need to add a connection string for your Cosmos DB account. The name must match the Connection property in the [CosmosDBOutput] attribute ("CosmosDBConnection").

   {
     "IsEncrypted": false,
     "Values": {
       "AzureWebJobsStorage": "UseDevelopmentStorage=true",
       "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
       "CosmosDBConnection": "AccountEndpoint=...;AccountKey=...;"
     }
   }
   

   You will need to create a Cosmos DB account in the Azure portal to get this connection string. Use the API for NoSQL.

After setting this up, run your function locally (F5). Navigate to the URL and add a query parameter (e.g., http://localhost:7071/api/orders?name=JohnDoe). You should see a new document created in your Cosmos DB container.

3. Implementing an Input Binding

Input bindings are just as straightforward. They allow you to fetch data and pass it into your function as a parameter. A common pattern is to use a route parameter from an HTTP trigger to look up a specific item.

For this, you decorate a method parameter with an input binding attribute.

To test this, run your project and use the ID of a document you created in the previous step. Navigate to http://localhost:7071/api/orders/{your-document-id}. Your function will be invoked with the corresponding document already retrieved from Cosmos DB.

4. Handling Multiple Output Bindings

What if your function needs to write to more than one destination? For example, returning an HTTP response and writing a message to a queue.

In the .NET Isolated model, you handle this by creating a custom C# class for your return type. Each property of the class can then be decorated with an output binding attribute.

This is a powerful pattern that allows you to compose complex operations declaratively. Let's imagine an HTTP-triggered function that creates a Cosmos DB entry and also returns an HTTP 200 OK response.

Your implementation would look like this:

// Define a custom return type
public class MultiOutput
{
    // Property for the Cosmos DB output binding
    [CosmosDBOutput("OrdersDB", "Orders", Connection = "CosmosDBConnection")]
    public object Document { get; set; }

    // Property for the HTTP response
    public HttpResponseData HttpResponse { get; set; }
}

// ... in your function class ...
[Function("CreateOrderAndRespond")]
public MultiOutput Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "multi-output-order")] HttpRequestData req)
{
    // Assume we read some data from the request body
    var orderData = ...; 

    var response = req.CreateResponse(HttpStatusCode.OK);
    response.WriteString("Order created successfully.");

    return new MultiOutput
    {
        Document = orderData,
        HttpResponse = response
    };
}

In this scenario, the Functions runtime inspects the returned MultiOutput object. It sees the [CosmosDBOutput] attribute and writes the Document property's content to Cosmos DB. Simultaneously, it uses the HttpResponse property to construct and send the HTTP response back to the client.

5. A Complete Workflow Example

To tie these concepts together, let's watch a video that demonstrates a full end-to-end workflow. An HTTP trigger will write a message to an Azure Service Bus queue (output binding), and a second function will be triggered by that queue message and write the content to Azure Blob Storage (another output binding).

Note: The video uses the older .NET in-process model, so the C# syntax for defining the bindings is slightly different (e.g., binding to IAsyncCollector<T>). However, the overall process—adding NuGet packages, decorating with attributes, configuring local.settings.json, and seeing the data flow—is identical and provides an excellent practical demonstration.

Conclusion

In this lesson, you've learned how to leverage one of the most productive features of Azure Functions. By using bindings, you can focus on your business logic and let the platform handle the mechanics of data integration.

Here are the key takeaways:

• Declarative Integration: Bindings are attributes in your C# code that connect your function to other Azure services.
• Input vs. Output: Input bindings bring data into your function via parameters. Output bindings send data from your function, typically via the return value.
• .NET Isolated Model Patterns: For a single output, you return the object to be written. for multiple outputs, you create a custom class and decorate its properties with output binding attributes.
• Configuration is Key: The Connection property in a binding attribute must correspond to an entry in your local.settings.json file (for local development) or application settings (in Azure).

In our next lesson, we will explore another trigger type: the timer trigger. You'll learn how to create functions that run on a recurring schedule using CRON expressions, a common requirement for background jobs and maintenance tasks.