Message Filtering

Azure Service Bus supports message filtering with Topics. It is supported with queues. You can configure subscription rules for Azure Service Bus Topics to deliver messages categorically to different subscribers as per the business requirements. A subscription rule can consist of filter condition or actions. To learn more about the message filtering feature of Azure Service Bus, take a look at https://docs.microsoft.com/en-us/azure/service-bus-messaging/topic-filters.

Message Sessions

Azure Service Bus provides a guaranteed reliable delivery of related messages in a particular sequence to the receiver/subscriber application by using message sessions. To leverage this feature, you will have to enable sessions while creating queues/topics. While sending a message to the queue/topic as part of a session, the sender application will also have to set the session ID property. This will help the receiver application to distinguish if a particular message is associated with a particular session or not. To learn more about message sessions of Azure Service Bus, check out https://docs.microsoft.com/en-us/azure/service-bus-messaging/message-sessions.

Message Auto-forwarding

Azure Service Bus provides a way to send messages from a particular queue or subscription to another queue or topic within the namespace for the purpose of chaining them. Any messages coming to our source queue/subscription will be removed and moved to the destination queue/topic automatically.

Duplicate Detection

In certain scenarios, a message sent by the sender application may not get delivered within a certain time period, because of which the sender application might resend the message to the service bus queue to be picked up by the receiver application for further processing. Now our receiver application will be processing the same message twice because of the message being resent by the sender. To remove such duplicate messages, Azure Service Bus provides a duplicate detection feature that discards the duplicate message for us.

Message Expiration

While solving real-world problems, we often come across scenarios where the time to live of a message is crucial for the sanity of the message. Some messages can be of no value after a certain threshold. For example, if a notification of an EMI payment to the customer is sent after the due date, it does not add any business value and may result in a bad customer experience. To avoid such scenarios, Azure Service Bus provides a feature to define the maximum time to live of messages for a queue or topic while we are provisioning them.

Message Deferral

Whenever you send a message to a message broker, it gets enqueued in a queue or topic and is available for the receiver application to pick up the message and process it further. But in some scenarios where you might want to schedule a message to be processed at a later date. Azure Service Bus provides a message deferral mechanism to address this scenario. You can schedule a message to be sent at a future date in the queue and the message will only get queued once the scheduled date has come. We are going on a use case for this feature and implement it later in the chapter.

Message Batching

Azure Service Bus provides a mechanism to batch a certain number of messages and send them in a batch to the receiver application to process at one go, which results in better utilization of resources at the receiver’s end.

Queues

Azure Service Bus Queue enables applications to interact with each other using point-to-point messaging. In the point-to-point messaging style, we send messages in a synchronous as well as asynchronous manner using Queues. The message, sent by the sender application, is sent to the receiver application using the queue. Each message is delivered to the queue only once to a single receiver application. If a receiver is not available to process the message, the message stays in the queue until the configured time to live of the message expires.

Topics

Azure Service Bus Topics enables applications to interact with each other using the publisher-subscriber model. In the publisher-subscriber messaging style, sender applications are called publishers and receiver applications are called subscribers. Here, we use Topics to convey the messages among these sender and receiver applications. A topic can consist of multiple subscriptions. To receive messages, receiver applications need to subscribe to a subscription. Once receivers are registered to the subscription of the topic, every time a message is sent by the sender, all the receivers receive the messages.

Namespaces

In Azure Service Bus, Namespaces acts as a logical container for all the queues and topics. To create any queues or topics in Azure Service Bus, you first have to provision an Azure Service Bus Namespace. The number of queues or topics that you can have in a namespace is dependent on the pricing tier that you select while provisioning the namespace.

Create an Azure Service Bus Namespace in Azure Portal

Go to the Microsoft Azure portal and search for Service Bus in the search box. Click Service Bus as shown in Figure 2-3.

Click Create to provision a new Service Bus namespace, as shown in Figure 2-4.

Select the Azure subscription and resource group name from the Subscription and Resource group drop-down lists, respectively, as shown in Figure 2-5. Then provide the namespace name, location, and pricing tier in the corresponding fields. The namespace name needs to be unique globally. After filling in all the required information, click Review + create.

A validation check will be done in the current page with all the data that you have provided. If all the data is valid (see Figure 2-6), then you will be able to create the namespace. If there was any error, then the particular error will be highlighted in this screen. Once the validation is successful, click Create.

You will be redirected to a page similar to Figure 2-7 that shows the status of the provisioning of your Service Bus namespace. Once the namespace has been created, click Go to resource.

Create an Azure Service Bus Namespace in Azure Portal

To create an Azure Service Queue inside your namespace, click + Queue as highlighted in Figure 2-8.

To create the queue, you have to provide the queue name, as shown in Figure 2-9. The queue name needs to be unique inside a namespace. For purposes of this example, use the name myqueue. Keep the defaults for the Max queue size, Max delivery count, Message time to live, and Lock duration settings. The Message time to live configuration defines how long an unprocessed message stays in the queue, and the Lock duration configuration defines the time period during which the message is going to be unavailable in the queue. After the entering the details, click Create.

This creates a Queue inside your Service Bus Namespace. You can view it by clicking Queues in the Entities section on the left side of the screen, as shown in Figure 2-10. You will see the list of all the queues present inside the namespace. Currently, you have just one queue, myqueue, as shown on the right in Figure 2-10.

Create an SAS Policy to Access the Azure Service Bus Namespace

To access or interact with Azure Service Bus Queues or Topics from our application, we need to authenticate our application’s request to the service bus. This can be done in different ways, such as using Azure Active Directory (Azure AD)–based authentication or SAS policies. For the purpose of this book, we will be using SAS policies. For enterprise applications, it is recommended to use Azure AD–based authentication or managed identity if the applications are deployed inside Azure in an Azure Function or App Service by providing necessary role-based access control (RBAC) permissions to the service bus instance.

To create an SAS policy, click Shared access policies in the Settings section, as shown in Figure 2-11, and then click Add to add a new policy. Enter the policy name in the Policy name box on the right and define the scope of this policy. Following the principle to provide least privilege, click the Send check box to assign this policy only the ability to send messages to service bus queues or topics present inside our namespace, and then click Create.

Once the policy has been created, you need to fetch the primary connection string. We will be using this connection string later in this chapter to interact with Azure Service Bus Queue to send and schedule messages.

Create a Console App to Send Messages to Azure Service Bus Queue

Now run your console app. Once the application has executed, go to the queue in the Azure portal. Figure 2-13 shows that ten messages were enqueued in the queue.

Create a Web API to Schedule Messages in Azure Service Bus Queue

In the previous section, you learned ways to send messages to the Azure Service Bus queue from your console application. This section focuses on solving the need of a fictional dental clinic to send appointment notifications to its patients. The dental clinic currently has a worker process in place that picks up messages from the service bus queue and processes them to send notifications. Currently, the worker process is processing any messages that are available in the queue, but the clinic doesn’t want the worker to send the notification until the right time. The notifications should be sent only three hours before the appointment time. Thus, the message cannot be sent to the queue directly. To solve this problem, we need to build a solution to schedule a message—an appointment reminder in this case—three hours before the appointment time so that the message enqueues in the queue at the scheduled time and then the worker process picks it up to process it and sends the notification to the patient.

We will be building an ASP.NET Core Web API to solve this problem by scheduling messages in the service bus queue by using the message deferral feature of Azure Service Bus. Our web API will provide two essential features: schedule a message to the service bus queue and cancel a scheduled message. There can be business scenarios where a patient can cancel a scheduled appointment and reschedule it for a future date. In such scenarios, the cancel feature will be essential, as we will have to cancel the existing scheduled message because it is no longer valid and may cause a bad customer experience.

As we have covered the business requirement, let’s start building our web API. Open Visual Studio 2022 and click Create a new project, as shown in Figure 2-14.

Select the ASP.NET Core Web API project template, as shown in Figure 2-15, and click Next.

Enter the project name, location, and solution name in the corresponding fields, as shown in Figure 2-16. Click Next to continue.

Now check the Use controllers check box, as we don’t want to use minimal APIs for the project, and keep the other options as shown in Figure 2-17. Click Create to create our web API project.

Visual Studio will create a sample API project for us that contains a simple WeatherForecastController, which returns randomly generated weather data to the client. Remove the WeatherForecastController.cs and WeatherForecast.cs files from our project, because we don’t need them.

For the time being, we are done with the program.cs file of our project. Let’s create two folders in our project: Business and Models. The Business folder will contain our interface and the classes implementing them. The Models folder will contain the classes of our data models.

In the preceding code snippet, we are leveraging the ServiceBusClient that we had injected in the DI container in our program.cs file and we are using it to instantiate the _serviceBusSender client to interact with the Azure Service Bus Queue whose name is stored with the key name as queueName in our appsetting.json file.

Now let’s implement the methods of the INotificationBusiness interface in the class. Let’s add the following code snippet to implement the methods.

The ScheduleAppointmentNotification converts the appointment object coming in the parameter of the method to a string type and then converts it into a service bus message. Then we calculate the time when we want to schedule it by subtracting three hours from the value passed in the ScheduledAt property of our appointment object in the parameter of our method and store it in the enqueueTime variable. It might be confusing at first glance when you see that enqueueTime will have three hours subtracted while we are using the AddHours method. It is happening as such because the value of enqueueDifference in our appsettings.json file is -3. We then use the ScheduleMessageAsync method of the ServiceBusSender client to schedule the message by passing our serviceBusMessage and enqueueTime as parameters. This method returns the sequence number of the scheduled message in the service bus queue.

The CancelAppointmentNotification method takes a long value (i.e., messageSequenceNumber) as a parameter and then uses the CancelScheduledMessageAsync method of the serviceBusSender client to cancel the method.

Let’s add our actions in our AppointmentController. We are going to have two actions: ScheduledAppointmentNotificationInQueue and CancelAppointmentNotificationFromQueue.

And with this our API project to schedule notifications for our fictional dental clinic is complete. Press Ctrl+F5 to build and run our project. The complete source code of this API project can be found at the following GitHub repository: https://github.com/AshirwadSatapathi/DentalAppointments.

In the next section, we will test our API using Postman, which is an API testing tool.

Test APIs Using Postman

Now that we have developed our APIs and have run them locally, let’s perform a sanity test on the functionalities of our API. Let’s open Postman and create a collection for our requests. After creating the collection, add a request to test the ScheduledAppointmentNotificationInQueue API. Now define the request method as POST and define the route as http://localhost:5010/api/Appointment/Notification/schedule and then click the Body tab to add the appointment information in the payload in key/value pairs. After you add the preceding information, click Send to send a request to our API. The API will now receive a request, process this information, and schedule this message in the service bus queue. Once the message has been scheduled, it will return a 200 response code along with the messageSequenceNumber as shown in Figure 2-18.

We can now go to our queue in the service bus and see that a message has been scheduled, as shown in Figure 2-19.

Now that we have tested the ScheduledAppointmentNotificationInQueue API, let’s create a request in our collection to the CancelAppointmentNotificationFromQueue API. We will cancel the message that was scheduled as part of our test for the ScheduledAppointmentNotificationInQueue API. We will do this by passing the messageSequenceNumber of the scheduled message that was returned by our ScheduledAppointmentNotificationInQueue API as response i.e., 11. After creating a new request, define the request method as DELETE and define the API URL as http://localhost:5010/api/Appointment/Notification/Cancel/11. To test this API, just click Send and our CancelAppointmentNotificationFromQueue API will cancel the message and it won’t be able go to the queue anymore. Upon successful execution, our API would return 200 OK as the status code with the message Scheduled message has been discarded, as shown in Figure 2-20.

We can now go to our queue in the service bus and see that a message has been discarded and we have no scheduled message, as can be seen in Figure 2-21.