Azure Event Hubs binding spec

Component format

To setup an Azure Event Hubs binding, create a component of type bindings.azure.eventhubs. See this guide on how to create and apply a binding configuration.

See this for instructions on how to set up an Event Hub.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: <NAME>
spec:
  type: bindings.azure.eventhubs
  version: v1
  metadata:
    # Hub name ("topic")
    - name: eventHub
      value: "mytopic"
    - name: consumerGroup
      value: "myapp"
    # Either connectionString or eventHubNamespace is required
    # Use connectionString when *not* using Microsoft Entra ID
    - name: connectionString
      value: "Endpoint=sb://{EventHubNamespace}.servicebus.windows.net/;SharedAccessKeyName={PolicyName};SharedAccessKey={Key};EntityPath={EventHub}"
    # Use eventHubNamespace when using Microsoft Entra ID
    - name: eventHubNamespace
      value: "namespace"
    - name: enableEntityManagement
      value: "false"
    - name: enableInOrderMessageDelivery
      value: "false"
    - name: maxConcurrentHandlers
      value: "100"
    # The following four properties are needed only if enableEntityManagement is set to true
    - name: resourceGroupName
      value: "test-rg"
    - name: subscriptionID
      value: "value of Azure subscription ID"
    - name: partitionCount
      value: "1"
    - name: messageRetentionInDays
      value: "3"
    # Checkpoint store attributes
    - name: storageAccountName
      value: "myeventhubstorage"
    - name: storageAccountKey
      value: "112233445566778899"
    - name: storageContainerName
      value: "myeventhubstoragecontainer"
    # Alternative to passing storageAccountKey
    - name: storageConnectionString
      value: "DefaultEndpointsProtocol=https;AccountName=<account>;AccountKey=<account-key>"
    # Optional metadata
    - name: getAllMessageProperties
      value: "true"
    - name: direction
      value: "input, output"

Spec metadata fields

Input binding delivery behavior

When enableInOrderMessageDelivery is true, the component processes one event at a time in partition order. When false, handlers run concurrently. Both modes provide at-least-once delivery. The component retries a failed handler invocation indefinitely using the configured backoff timing, until processing succeeds or the binding shuts down.

In concurrent mode, maxConcurrentHandlers limits the number of outstanding handler invocations per partition. Each invocation handles one event. An invocation holds its slot while it runs or retries, and after it succeeds if an earlier invocation on the partition has not succeeded yet. The component frees the slot once the invocation and every earlier one have succeeded. When all slots are in use, the component stops receiving from the partition until a slot frees up. An event that keeps failing holds its slot, and so does every later invocation, so the partition stops receiving once the limit is reached.

Checkpoints advance only through contiguous successfully processed events. The component writes a checkpoint each time that range advances. For example, if events 1, 2, and 4 succeed while event 3 is still running or retrying, the checkpoint stays at event 2. After event 3 succeeds, the checkpoint advances through event 4. An existing stored checkpoint remains the restart position. If no checkpoint exists, both ordered and concurrent modes start from the earliest retained event.

Microsoft Entra ID authentication

The Azure Event Hubs pub/sub component supports authentication using all Microsoft Entra ID mechanisms. For further information and the relevant component metadata fields to provide depending on the choice of Microsoft Entra ID authentication mechanism, see the docs for authenticating to Azure.

Binding support

This component supports output binding with the following operations:

• create: publishes a new message to Azure Event Hubs

Input Binding to Azure IoT Hub Events

Azure IoT Hub provides an endpoint that is compatible with Event Hubs, so Dapr apps can create input bindings to read Azure IoT Hub events using the Event Hubs bindings component.

The device-to-cloud events created by Azure IoT Hub devices will contain additional IoT Hub System Properties, and the Azure Event Hubs binding for Dapr will return the following as part of the response metadata:

For example, the headers of a HTTP Read() response would contain:

{
  'user-agent': 'fasthttp',
  'host': '127.0.0.1:3000',
  'content-type': 'application/json',
  'content-length': '120',
  'iothub-connection-device-id': 'my-test-device',
  'iothub-connection-auth-generation-id': '637618061680407492',
  'iothub-connection-auth-method': '{"scope":"module","type":"sas","issuer":"iothub","acceptingIpFilterRule":null}',
  'iothub-connection-module-id': 'my-test-module-a',
  'iothub-enqueuedtime': '2021-07-13T22:08:09Z',
  'message-id': 'my-custom-message-id',
  'x-opt-sequence-number': '35',
  'x-opt-enqueued-time': '2021-07-13T22:08:09Z',
  'x-opt-offset': '21560',
  'traceparent': '00-4655608164bc48b985b42d39865f3834-ed6cf3697c86e7bd-01'
}

Related links

• Basic schema for a Dapr component
• Bindings building block
• How-To: Trigger application with input binding
• How-To: Use bindings to interface with external resources
• Bindings API reference