Azure Service Bus — Message Queue

Chris Smith
5 min readFeb 26, 2021

How to process messages on an Azure Service Bus queue

Azure Service Bus is a managed messaging service used to send messages asynchronously between applications.

It works on two different models:

Queues
These work on a 1-to-1 relationship in a first-in-first-out (FIFO) order, where there is single sender and a single receiver.

Azure Service Bus Queue

Topics
Unlike queues, these work on a 1-to-many relationship. Each of the receivers subscribe to a topic in order to receive the message. Filters can be applied to the subscription to limit the messages being received.

Azure Service Bus Topic

In this blog I will only cover queues, showing you how to quickly get a working setup whereby you can send and receive messages to/from a queue.

All sample code is written in C# using .NET Core and can be found within my github.

Create a Message Queue

The first thing you will need to do is setup an Azure Service Bus and a Message Queue. If you don’t already have an Azure account then you will need to create one, a free trial plan is available. Ideally we would be able to do all this on our own local development environment however there are currently no emulators available for Azure Service Bus and queues.

There are several steps required to created a service bus and queue which I won’t go over in this blog as Microsoft have already done that for me - Azure Service Bus

For my own demo I have used the steps set out by Microsoft to create a queue demoqueue within the az-service-bus-demo namespace.

Once created, the queue is available to view within the Azure portal:

Azure Portal — View of the demo queue with 0 active messages

Demo Application

As already mentioned I’ll be using C# as my language of choice for my demo project.

I started by creating a .NET Core Console App project azure.service.bus.demo and added an appsettings.json file within the project. The appsettings file is used to hold the service bus connection string and the queue name.

appsettings — configuration file holding the service bus and queue details

Also required is the installation of the NuGet package Azure.Messaging.ServiceBus into your project. This package provides us with the functionality required to send and receive message to the Azure Service Bus.

azure.service.bus.demo — project structure highlighting the installed NuGut package

Program class

The main file of our project this is responsible for reading the configuration from the appsettings.json file and calling both the Sender and Receiver classes to do the work of processing the queue.

Program — main class that kick-offs the queue processing

Sender class

In the Sender.cs class there are three main tasks being performed, all within the SendMessagesAsync method:

  1. Creation of a ServiceBusClient, passing in the connection string from config. This client provides us with the connection to the service bus in Azure.
  2. Creation of a ServiceBusSender associated with the client. We pass in the queue name from config to ensure connection is to the correct queue.
  3. The actual sending of the message using SendMessageAsync. After making this call the message will be available within our queue.

All code to connect and send is being performed using the functionality provided to us by the installed NuGet package Azure.Messaging.ServiceBus, as can be seen by the using statement on line 3.

Sender — class responsible for sending messages to the queue

This code simply iterates the SendMessageAsync call sending 20 messages to the service bus queue. Once this code has been run we can use the Azure portal to view our queue and confirm that there are now 20 active messages.

Azure Portal — View of the demo queue with 20 active messages

Receiver class

In the Receiver.cs class we have three methods:

  1. MessageHandler
    This event handler processes each message within the queue, and calls CompleteMessageAsync to mark the message as completed which will tell the service bus to delete it from the queue.
  2. ErrorHandler
    This is a default error handler required by the ServiceBusProcessor.
  3. ReceiveMessageAsync
    This method has the following responsibilities:
  • Creation of a ServiceBusClient. As with the sender, the connection string from config is passed in as a parameter to ensure our client is connecting to the correct service bus in Azure.
  • Creation of a ServiceBusProcessor which is given the queue name from config and default processor options as parameters. The processor provides us with the ability to process messages using the event handlers.
  • Assigns the two event handlers to the processors events.
  • Starts the processing of messages using the StartProcessingAsync call. When a message is found on the queue, the MessageHandler will be called and the messaged processed.
  • Stops the processing of messages using the StopProcessingAsync call.
Receiver — class responsible for receiving and processing queue messages

Again, after running this code we can view the Azure portal to check our queue. As you can see there is now 0 active messages as they have all been received, marked as completed by the receiver and deleted from the queue.

Azure Portal — View of the demo queue with 0 active messages

Console window output

You may have noticed in the code snippets that some debug information is being output to the console window. These outputs show the 20 message being sent to the queue and them being received from the queue:

Messages sent to the queue
Messages received and processed from the queue

Summary

Hopefully this blog has provided you with a quick guide into the world of Azure Service Bus and in particular the queue model.

There is a lot more that can be done with the service bus especially when diving into the publish/subscribe model using Topics, dead-letter queues, message time to live, duplicate detection etc. Those however are all for another day and another blog!

Thanks for reading.

--

--

Chris Smith

Software Engineer at Kainos. Normally found on a golf course or watching football. All views expressed here are my own.