Processing Azure Service Bus messages using an Azure Function

When investigating using Azure Service Bus for our messaging architecture, I wanted some mechanism whereby I could receive and therefore process the messages that were added to the service bus queue. At first I wasn't sure how I would achieve this. As the various components involved in a service bus architecture have no direct means of communicating with each other, then there is obviously no way that the receiving application can know when a message has been added to the service bus queue by a client application. Therefore what is needed is a polling mechanism that will continuously poll the service bus queue looking for messages that have been added.

I didn't want to have to rely on local infrastructure, but wasn't sure what Azure had to offer. After some investigation, it seemed that the two most likely candidates were Azure WebJobs or an Azure Function. I decided to use an Azure Function as this seemed the best fit for what I was looking for. They are cloud hosted functions that have in-built support for listening to Azure Service Bus message queues. They also support a wide range of other Azure events and processes.

If your needs are fairly straight-forward, and you just want some mechanism for processing your Azure Service Bus messages, then Azure Functions are a good fit. If your requirements are more complex, then you may want to investigate Azure WebJobs. This article[^] proved instructive whilst setting up my Azure Function. I have two Azure Functions configured. One for testing and one for production. My unit tests post messages to the test Azure Service Bus queue, which is polled by the test Azure Function for messages. And conversely, I also have a production Azure Function which listens to the production Azure Service Bus queue for messages.

If your function needs to reference a third-party assembly or one of your own assemblies, then you will need to upload the assembly to the Azure Function. This article[^] explains the process. If you are referencing your own assembly, then you may want to investigate the various ways you can amend your continuous integration pipeline so that the assembly is kept up-to-date. I have added a new step to our Team Foundation Server 2015 build which invokes a batch file that FTPs the required assembly to our Azure Functions. Alternatively, Azure Functions support continuous integration from Gitub, Dropbox, Bitbucket to name a few. So keeping the assemblies used by your Azure Function in synch with your source code is simple. In fact, you can configure your Azure Function to consume not just assemblies, but the code itself from your continuous integration pipeline.

You will probably want to amend the default function code that is created when you first configure your Azure Function. Here is an example of a very simple Azure Function.

using System;using System.Collections.Generic;using System.Threading.Tasks;using Microsoft.ServiceBus.Messaging;publicstaticvoid Run(BrokeredMessage message, TraceWriter log)
{
    log.Info($"C# ServiceBus queue trigger function processed message: {message.MessageId}");try
    {if (message != null)
        {//do something with the message here

            log.Info("Completing message.");
            message.Complete();
        }
    }catch (Exception ex)
    {
        message.Abandon();
        log.Info($"Exception occurred: {ex.Message}");
    }
}

By definition an Azure Function should not be monolothic, but instead should be highly cohesive (just as when writing any function). So keep your Azure Functions short and focused.

Whilst testing the performance of processing messages using the Azure Function, I found it was significantly faster than when using local infrastructure. They are blazingly fast.

Azure Functions are very flexible and can be used in conjunction with many processes and tasks within the Azure ecosystem, so they are well worth checking out if you are looking at hosting your own processes.