Service Bus Input Bindings

Learn how to use Service Bus input bindings to read messages from Azure Service Bus queues and topics in your Azure Functions.

Overview

Service Bus input bindings enable your Azure Functions to retrieve messages from Service Bus queues or topic subscriptions. This allows you to process messages that have been sent to Service Bus without the need to explicitly write code to poll for new messages.

Supported Service Bus Entities

Queues
Topic Subscriptions

Configuration

To configure a Service Bus input binding, you typically define it in your function's function.json file (for in-process .NET) or using attributes in your code (for .NET isolated or other languages).

`function.json` Example (Node.js)


{
  "bindings": [
    {
      "name": "message",
      "type": "serviceBusTrigger",
      "direction": "in",
      "queueName": "myqueue",
      "connection": "ServiceBusConnection"
    },
    {
      "name": "outputBlob",
      "type": "blob",
      "direction": "out",
      "path": "output/{sys.RANDOM_GUID}.txt",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

Note: The example above shows a trigger, but the concept for input bindings is similar, typically used within a triggered function or a timer-based function.

Service Bus Input Binding Properties

Property	Description	Required
`name`	The name of the variable that will hold the Service Bus message in your function code.	Yes
`type`	Must be set to `serviceBus`.	Yes
`direction`	Must be set to `in`.	Yes
`queueName`	The name of the Service Bus queue to read messages from. Specify either `queueName` or `topicName` and `subscriptionName`.	Yes (either `queueName` or `topicName`/`subscriptionName`)
`topicName`	The name of the Service Bus topic.	Yes (if reading from a subscription)
`subscriptionName`	The name of the Service Bus topic subscription.	Yes (if reading from a subscription)
`connection`	The name of the application setting that contains your Service Bus connection string.	Yes

Usage in Code

C# (In-process)


using Microsoft.Azure.WebJobs;
using Microsoft.Azure.ServiceBus;

public static class ServiceBusInputFunction
{
    [FunctionName("ServiceBusInputProcessor")]
    public static void Run(
        [ServiceBusTrigger("myqueue", Connection = "ServiceBusConnection")] Message message,
        [Blob("output/{sys.RANDOM_GUID}.txt", FileAccess.Write, Connection = "AzureWebJobsStorage")] out string outputBlob)
    {
        // The 'message' variable now contains the Service Bus message
        string messageBody = System.Text.Encoding.UTF8.GetString(message.Body);
        outputBlob = $"Processed message: {messageBody}";
        
        Console.WriteLine($"C# ServiceBus queue trigger function processed message: {messageBody}");
    }
}

Node.js


module.exports = async function (context, message) {
    // The 'message' object now contains the Service Bus message
    context.log('JavaScript ServiceBus queue trigger function processed message', message);
    
    // Example: Writing message body to an output blob
    context.bindings.outputBlob = `Processed: ${message.body}`;
};

In Node.js, the message parameter automatically represents the Service Bus message content when using the serviceBusTrigger. For input bindings used within other triggers (e.g., timer), you would declare it as an input in function.json and it would be passed as a separate parameter.

Message Properties

When you retrieve a message using a Service Bus input binding, you can access its properties. The exact structure depends on the language and runtime.

For example, in C#, the Microsoft.Azure.ServiceBus.Message object provides properties like:

Body: The message content.
MessageId: The message identifier.
Subject: The message subject.
Properties: Custom application properties.

Error Handling and Dead-Lettering

Azure Functions integrates with Service Bus error handling. If your function execution fails, the message might be automatically dead-lettered by Service Bus, depending on your configuration and the trigger type.

Important Note

For input bindings, unlike triggers, the message is not automatically removed from the queue/subscription after successful processing. You typically need to implement explicit logic to complete or abandon the message if you are reading it as a separate input binding within a function triggered by something else.

Considerations

When using a serviceBusTrigger, messages are automatically completed upon successful function execution.
If your function throws an unhandled exception, the message may be dead-lettered by default.
For Service Bus input bindings that are not triggers, manual message completion or abandonment might be necessary.

Azure Functions