2021-01-19 update: code for subscription was adjusted to ensure the correct default rule for subscription is created.

In the previous post, Automatically create Service Bus trigger queue for Azure Function, I’ve shown how to provision a ServiceBusTrigger queue from within a Function.

In this post, we’ll take that idea and push it further to something a bit more sophisticated - provisioning the topology necessary for NServiceBus endpoint hosted with Azure Function and using Azure Service Bus transport. If you haven’t used NServiceBus or NServiceBus with Azure Functions, here’s a starting point for you. NServiceBus can bring a few advantages over native Functions I’ll leave to discover on your own. And now, let’s have a look at what are the things we’ll need to accomplish.

Azure Functions are great. Take HTTP triggered Function. You make a request, it’s passed into the Function code, the code is executed, and that’s it. Simple. What does it take to deploy an HTTP-triggered function? Packaging and deploying it.

When developing locally, there are many ways to store secrets locally without risk of receiving a GitHub notification about leaked keys and secrets. Environment variables, local files excluded from check-ins, user secrets with secret storage, etc. This post is about user secrets. If you have no experience with user secrets, this Microsoft article does a good job to go from zero to sixty in about 30 seconds.

When working with CosmosDB, you’re quickly accustomed to the idea that each operation costs a certain amount of RUs. And when there’s not enough RUs, the request gets throttled. There’s a capacity calculator that helps to find out the estimated required throughput based on the operations and other criteria to avoid throttling. But this calculator is omitting important information that does not appear to be documented at the moment. Creating collections can be throttled as well, except not due to an insufficient amount of RUs. To demonstrate how collection creation requests can be throttled, I’ll emulate concurrent requests coming to the broker to create temporary collection.

Why Azurite?

For a long time, I was using Storage Emulator to execute some verification tests for ServiceBus.AttachmentPlugin project. And I’d continue using it if not a few inconveniences it had.

• Needs to be installed. While it’s not big of a deal, using something like PowerShell it can be download and installed swiftly.
  

Event Grid subscriptions filtering offers advanced filtering that allows data payload attributes filtering. Or filtering on the payload. This is a feature you cannot have with Azure Service Bus, for example. If you’d like to achieve the same functionality with Service Bus, you’d need to promote data from the payload into the headers. But back to Event Grid.

There is a maximum of 5 advanced filters per subscription. This might seem not much, but it’s actually quite a lot. Advanced filtered are evaluated using AND logic among themselves. Within each advanced filter, the evaluation of multiple values is done using OR logic. Except there’s a caveat. The documentation is outdated and the portal does not reflect the real power of these filters - the number of values advanced filters can evaluate are not restricted to 5 values per filter. Rather, the number of those values is a pool shared by all 5 advanced filters.

2022-04 Update: as Lee McMullen has pointed out, the deployment task srijken/azure-zip-deploy@v1.0.1 has been replaced by azure/webapps-deploy@.

WebJobs are a hidden gem within Azure App Service. While it’s coupled to the web application, one of the neat tricks is to turn it into a worker service for continuous background processing. Arguably, this could be also accomplished by Azure Functions, but in certain scenarios, it’s simpler to have an equivalent of what used to be a Windows Service. I will skip the building a WebJob part. It’s sufficiently enough documented by Microsoft. Yves Goeleven has done some really nice work with WebJobs he’d be happy to share with those that are looking for ideas. And while what he’s done is great, I will mention that I’d love to see a WebJob as a Service kind of offer coming soon. Or some Worker as a role. Something that would fill in the gap that is there. Not everything is containers/Kubernetes or Functions. And using WebJobs under the App Service umbrella feels like hunting a mosquito with a canon. Without further ado, how to deploy a WebJob using GitHub actions?

Table of contents

1. The future of Azure Service Bus .NET SDK
2. ServiceBusClient
3. ServiceBusSender
4. ServiceBusReceiver
5. Safe Batching

Unsafe batching

In one of the previous posts, Sending ServiceBusMessage(s) I’ve mentioned the option to send a single message using SendAsync() API. Sometimes, sending a single message is not enough and multiple messages need to be sent. The same method provides an overload to send a collection of messages.

If you ever used the Service Bus Explorer (SBE) tool, you can appreciate how handy it is to be able to explore the namespace, inspect individual entities, and perform CRUD operation. It’s also extremely handy to be able to perform operations that involve messages. For a long time, the tool was only available for Windows users and there was a long-standing feature request to make the tool cross-platform. The tool is an open-source project and is entirely driven by the volunteered effort. For a long time, the tool was compensating for what Microsoft didn’t provide. And, I must admit, was doing a great job, considering its open-source nature and completely voluntary contributions. Until today.

Table of contents

1. The future of Azure Service Bus .NET SDK
2. ServiceBusClient
3. ServiceBusSender
4. ServiceBusReceiver
5. Safe Batching

Sent message vs received message

Not all messages are born equal. A message sent starts its life on the client-side and has fewer attributes than a message that is received. Why is that? Well, a message that is sent has not been on the server-side. It hasn’t been received and “leased”. And as a result of that, it has no values for SequenceNumber, DeliveryCount, LockToken/LockedUntil, DeadLetterReason or any other value that would be set on the broker. But historically, that was not the case. Both, Track 0 and Track 1 took an approach of a canonical message that represented both messages, sent and received. With Track 2 that’s changing. Message sent from the client-side, ServiceBusMessage is not the type received. Received messages are of the type ServiceBusReceivedMessage. It’s an “extension” of the ServiceBusMessage, containing all the additional information broker (server-side) would set.