Edit

Share via

Azure Event Hubs trigger and bindings for Azure Functions

  • Article

This article explains how to work with Azure Event Hubs bindings for Azure Functions. Azure Functions supports trigger and output bindings for Event Hubs.

Action Type
Respond to events sent to an event hub event stream. Trigger
Write events to an event stream Output binding

Install extension

The extension NuGet package you install depends on the C# mode you're using in your function app:

Functions execute in an isolated C# worker process. To learn more, see Guide for running C# Azure Functions in an isolated worker process.

The functionality of the extension varies depending on the extension version:

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 supports configuration of triggers and bindings through .NET Aspire integration.

Add the extension to your project by installing the NuGet package, version 5.x.

Install bundle

The Event Hubs extension 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.

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.

You can add this version of the extension from the extension bundle v3 by adding or replacing the following code in your host.json file:

{
    "version": "2.0",
    "extensionBundle": {
        "id": "Microsoft.Azure.Functions.ExtensionBundle",
        "version": "[3.3.0, 4.0.0)"
    }
}

To learn more, see Update your extensions.

Binding types

The binding types supported for .NET depend on both the extension version and C# execution mode, which can be one of the following options:

An isolated worker process class library compiled C# function runs in a process isolated from the runtime.

Choose a version to see binding type details for the mode and version.

The isolated worker process supports parameter types according to the tables below. Support for binding to types from Azure.Messaging.EventHubs is in preview.

Event Hubs trigger

When you want the function to process a single event, the Event Hubs trigger can bind to the following types:

Type Description
string The event as a string. Use when the event is simple text.
byte[] The bytes of the event.
JSON serializable types When an event contains JSON data, Functions tries to deserialize the JSON data into a plain-old CLR object (POCO) type.
Azure.Messaging.EventHubs.EventData1 The event object.
If you are migrating from any older versions of the Event Hubs SDKs, note that this version drops support for the legacy Body type in favor of EventBody.

When you want the function to process a batch of events, the Event Hubs trigger can bind to the following types:

Type Description
string[] An array of events from the batch, as strings. Each entry represents one event.
EventData[] 1 An array of events from the batch, as instances of Azure.Messaging.EventHubs.EventData. Each entry represents one event.
T[] where T is a JSON serializable type1 An array of events from the batch, as instances of a custom POCO type. Each entry represents one event.

1 To use these types, you need to reference Microsoft.Azure.Functions.Worker.Extensions.EventHubs 5.5.0 or later and the common dependencies for SDK type bindings.

Event Hubs output binding

When you want the function to write a single event, the Event Hubs output binding can bind to the following types:

Type Description
string The event as a string. Use when the event is simple text.
byte[] The bytes of the event.
JSON serializable types An object representing the event. Functions tries to serialize a plain-old CLR object (POCO) type into JSON data.

When you want the function to write multiple events, the Event Hubs output binding can bind to the following types:

Type Description
T[] where T is one of the single event types An array containing multiple events. Each entry represents one event.

For other output scenarios, create and use an EventHubProducerClient with other types from Azure.Messaging.EventHubs directly. See Register Azure clients for an example of using dependency injection to create a client type from the Azure SDK.

host.json settings

The host.json file contains settings that control behavior for the Event Hubs trigger. The configuration is different depending on the extension version.

{
    "version": "2.0",
    "extensions": {
        "eventHubs": {
            "maxEventBatchSize" : 100,
            "minEventBatchSize" : 25,
            "maxWaitTime" : "00:05:00",            
            "batchCheckpointFrequency" : 1,
            "prefetchCount" : 300,
            "transportType" : "amqpWebSockets",
            "webProxy" : "https://proxyserver:8080",
            "customEndpointAddress" : "amqps://company.gateway.local",
            "targetUnprocessedEventThreshold" : 75,
            "initialOffsetOptions" : {
                "type" : "fromStart",
                "enqueuedTimeUtc" : ""
            },
            "clientRetryOptions":{
                "mode" : "exponential",
                "tryTimeout" : "00:01:00",
                "delay" : "00:00:00.80",
                "maximumDelay" : "00:01:00",
                "maximumRetries" : 3
            }
        }
    }
}
Property Default Description
maxEventBatchSize2 100 The maximum number of events included in a batch for a single invocation. Must be at least 1.
minEventBatchSize1 1 The minimum number of events desired in a batch. The minimum applies only when the function is receiving multiple events and must be less than maxEventBatchSize.
The minimum size isn't strictly guaranteed. A partial batch is dispatched when a full batch can't be prepared before the maxWaitTime has elapsed. Partial batches are also likely for the first invocation of the function after scaling takes place.
maxWaitTime1 00:01:00 The maximum interval that the trigger should wait to fill a batch before invoking the function. The wait time is only considered when minEventBatchSize is larger than 1 and is otherwise ignored. If less than minEventBatchSize events were available before the wait time elapses, the function is invoked with a partial batch. The longest allowed wait time is 10 minutes.

NOTE: This interval is not a strict guarantee for the exact timing on which the function is invoked. There is a small margin of error due to timer precision. When scaling takes place, the first invocation with a partial batch may occur more quickly or may take up to twice the configured wait time.
batchCheckpointFrequency 1 The number of batches to process before creating a checkpoint for the event hub.
prefetchCount 300 The number of events that is eagerly requested from Event Hubs and held in a local cache to allow reads to avoid waiting on a network operation
transportType amqpTcp The protocol and transport that is used for communicating with Event Hubs. Available options: amqpTcp, amqpWebSockets
webProxy null The proxy to use for communicating with Event Hubs over web sockets. A proxy cannot be used with the amqpTcp transport.
customEndpointAddress null The address to use when establishing a connection to Event Hubs, allowing network requests to be routed through an application gateway or other path needed for the host environment. The fully qualified namespace for the event hub is still needed when a custom endpoint address is used, and it must be specified explicitly or via the connection string.
targetUnprocessedEventThreshold1 null The desired number of unprocessed events per function instance. The threshold is used in target-based scaling to override the default scaling threshold inferred from the maxEventBatchSize option. When set, the total unprocessed event count is divided by this value to determine the number of function instances needed. The instance count is rounded up to a number that creates a balanced partition distribution.
initialOffsetOptions/type fromStart The location in the event stream to start processing when a checkpoint does not exist in storage. Applies to all partitions. For more information, see the OffsetType documentation. Available options: fromStart, fromEnd, fromEnqueuedTime
initialOffsetOptions/enqueuedTimeUtc null Specifies the enqueued time of the event in the stream from which to start processing. When initialOffsetOptions/type is configured as fromEnqueuedTime, this setting is mandatory. Supports time in any format supported by DateTime.Parse(), such as 2020-10-26T20:31Z. For clarity, you should also specify a timezone. When timezone isn't specified, Functions assumes the local timezone of the machine running the function app, which is UTC when running on Azure.
clientRetryOptions/mode exponential The approach to use for calculating retry delays. Exponential mode retries attempts with a delay based on a back-off strategy where each attempt will increase the duration that it waits before retrying. The fixed mode retries attempts at fixed intervals with each delay having a consistent duration. Available options: exponential, fixed
clientRetryOptions/tryTimeout 00:01:00 The maximum duration to wait for an Event Hubs operation to complete, per attempt.
clientRetryOptions/delay 00:00:00.80 The delay or back-off factor to apply between retry attempts.
clientRetryOptions/maximumDelay 00:00:01 The maximum delay to allow between retry attempts.
clientRetryOptions/maximumRetries 3 The maximum number of retry attempts before considering the associated operation to have failed.

1 Using minEventBatchSize and maxWaitTime requires v5.3.0 of the Microsoft.Azure.WebJobs.Extensions.EventHubs package, or a later version.

2 The default maxEventBatchSize changed in v6.0.0 of the Microsoft.Azure.WebJobs.Extensions.EventHubs package. In earlier versions, this was 10.

The clientRetryOptions are used to retry operations between the Functions host and Event Hubs (such as fetching events and sending events). Refer to guidance on Azure Functions error handling and retries for information on applying retry policies to individual functions.

For a reference of host.json in Azure Functions 2.x and beyond, see host.json reference for Azure Functions.

Next steps