Some context

I’ve seen software systems built since 2001. My first exposure was to classic ASP and VB6 applications with traditional state-based architecture. As someone new to software development, I was both fascinated by the use of data stores such as SQL Server to persist the vast amounts of data and horrified by the ease of irreversible mistakes that could take place. I should be honest; that took place when I accidentally ran some SQL update statements against the wrong database. Glorious days of a newbie developer at a startup company. I learned quickly that a safe strategy includes backing up data frequently.

Message settlement with Azure Service Bus has undergone some changes over the past few iterations of the Service Bus SDK for .NET. In the latest SDK (Azure.Messaging.ServiceBus), the settlement is performed via the ServiceBusReceivedMessage. In the previous SDK, this was accomplished with the help of the MessageReceiver object.

Azure Functions In-Process SDK can disable message auto-completion by specifying AutoComplete = false on the ServiceBusTrigger. When auto-completion is disabled, the responsibility to complete (settle) the incoming message is on the function code. Except with the latest SDK, MessageReceiver is no longer an option. And while the equivalent, ServiceBusReceiver, seems to be the logical replacement, it is not. Instead, a particular type, ServiceBusMessageActions*, must be injected and used to settle messages.

Azure Functions Tools is at the heart of providing local development for Azure Function. Whenever you use Visual Studio, Rider, VS Code, or anything else, you need it to be able to run your bits. For command line folks, the installation process is outlined in the tools repository. For Visual Studio (2022) and Rider, it is less evident as it depends on the tool. So, where am I heading with this? Right, the need to update the Azure Functions Tools.

Upgrading to .NET 6, updating all the packages, boosters turned on, launching testing.

Houston, we’ve got a problem.

System.NotSupportedException: BinaryFormatter serialization and deserialization are disabled within this application. See https://aka.ms/binaryformatter for more information.

Ouch! What just happened? There were no warnings, no obsolete messages, nothing on to the autopsy.

NServiceBus has a data bus (or a ‘databus’) feature. The feature implements the Claim Check pattern to allow messages to surpass the imposed maximum message size by the underlying messaging technology. The feature serializes the data internally, and the default DefaultDataBusSerializer uses BinaryFormatter. Nothing new; it has been used for years. Unfortunately, with .NET 5, BinaryFormatter was deprecated due to a security risk it poses. And while you could skip .NET 5 and live with .NET Core 3.1, .NET 6 is breathing down the neck, and an upgrade is imminent.

Introduction

Handling messages out of order is always tricky. The asynchronous nature of messaging makes it challenging. On top of that, systems in the real world are messy and unpredictable. That’s why handling workflows always brings more complexity than just handling messages. To illustrate the challenge, I’ll use a scenario where my workflow depends on two different services.

1. Payments
2. Shipping

To successfully complete an order, I’ll need to handle a message from each service. PaymentAccepted from the Payments service and ItemShipped from the Shipping service. The order can be considered successfully completed only when the two messages are received. The absence of one of the messages would indicate a failed state and require a compensating action. The compensating action will depend on which one of the two messages has already been handled. I’ll leave the details of the compensating action out of this post to keep it somewhat light.

Azure Service Bus queues and subscriptions are an excellent way to process messages using competing consumers. But it can also get really tricky. Let’s look at a scenario where a single event needs to be processed by two services. For this example, I’ll use a process of an agent being assigned to a case. The requirement is pretty straightforward. When an agent is assigned to a case, we should send an email notifying the agent. In my system, I’ve designed it the way that when the event of assignment (AgentAssigned) is taking place, there are two event handlers that would react to it:

Azure timer triggered. Functions are convenient for automated execution. With the specified time interval, a function gets to execute when specified and then sleeps until the subsequent execution.

But what happens when a function needs to be executed on demand? For example, during development, when debugging the logic and want to kick off a function right away rather than waiting?

That’s possible with the TimerTrigger that accepts an additional parameter, RunOnStartup. Assign it a value of true, and the function will be executed when the Function App starts. You might want to wrap it with #if DEBUG to ensure it gets executed upon each deployment or restarting a Function/Function App in production.

About 5+ years ago I blogged about turning messages into audit blobs. Back then, it was for Storage Queue messages and the early Azure Functions implementation that required portal configuration. Since then, Storage Queues has been replaced by Azure Service Bus and Azure Functions has gained the ability to declare everything through the code. And not only that but also in two different ways, using

1. In-Process SDK
2. Isolated Worker SDK (out-of-process)

The concept hasn’t changed much but the the code did become somewhat simpler.

The new Azure Functions SDK for Isolated Worker (process) has been introduced around .NET 5. While it’s still in flux despite being GA-ed, it’s gaining more and more popularity. And yet, there are still some sharp edges you should be careful with and validate that everything you’re using with the older SDK, In-Process, is offered with the new SDK. Or at least there’s a replacement.

Today, I’ve stumbled upon a StackOverflow question about IAsyncCollector and Service Bus messages. IAsyncCollector, as its synchronous counterpart ICollector offers the comfort of output binding and returning multiple items. For example, with Azure Service Bus, one can send out multiple messages from the executing function. Quite handy, and with the In-Process SDK, it looks like the following. The function’s signature contains a collector (I call it dispatcher) that can be used to “add” messages. Those are actually getting dispatched to the queue the ServiceBus attribute is configured with by adding messages. Which, in this case, is a queue called dest.

A recent talk I gave online at ServerlessDays Amsterdam