Arcus Messaging has been around for quite a while now. It was created to remove the huge hurdle of rewriting the same boilerplate for processing message queues.
On March 27th, 2020 we’ve announced Arcus Messaging for the first time, this was the start of a new journey to where we are today.
The Arcus Messaging now has an upgrade in how you can interact with messages coming from Azure Service Bus.
Previous versions had set up a message handling system where messages could be routed and processed according to contextual information, but it didn’t cover all the scenarios that our customers have, for example, it didn’t provide a way to manually dead-letter a message.
Until now.
| public class OrderFallbackMessageHandler : IAzureServiceBusFallbackMessageHandler | |
| { | |
| public async Task ProcessMessageAsync(Message orderMessage, AzureServiceBusMessageContext context, ...) | |
| { | |
| // Processing order. | |
| } | |
| } |
When you decide you want to dead-letter the message, you’ll have to implement AzureServiceBusFallbackMessageHandler instead.
| public class OrderFallbackMessageHandler : AzureServiceFallbackMessageHandler | |
| { | |
| public override async Task ProcessMessageAsync(Message orderMessage, AzureServiceBusMessageContext context, ...) | |
| { | |
| // Processing order. | |
| await base.DeadLetterAsync(orderMessage); | |
| } | |
| } |
Note that because the fallback message handlers have more control over the original Azure Service Bus message, they will have to pass along the message to the base operations.
Registering this fallback message handler is just the same as when implementing the interface:
| public void ConfigureServices(IServiceCollection services) | |
| { | |
| services.AddServiceBusMessageHandler<OrderCompletedMessageHandler>() | |
| .AddServiceBusMessageHandler<OrderCancelledMessageHandler>() | |
| .AddServiceBusFallbackMessageHandler<OrderFallbackMessageHandler>(); | |
| } |
| public class OrderMessageHandler<Order> : IAzureServiceBusMessageHandler<Order> | |
| { | |
| public async Task ProcessMessageAsync(Order order, AzureServiceBusMessageContext context, ...) | |
| { | |
| // Processing order. | |
| } | |
| } |
If you decide you want to abandon the message when the order is not recognized, or the message context is invalid, you’ll have to implement AzureServiceBusMessageHandler instead.
| public class OrderMessageHandler<Order> : AzureServiceBusMessageHandler<Order> | |
| { | |
| public override async Task ProcessMessageAsync(Order order, AzureServiceBusMessageContext context, ...) | |
| { | |
| if (order.Customer is null) | |
| { | |
| // Calling base operation where the Azure Service Bus operations are located. | |
| await base.AbandonMessageAsync(); | |
| } | |
| else | |
| { | |
| // Processing order. | |
| } | |
| } | |
| } |
Note that in the regular message handling you don’t have to specify which message to abandon. This is all done behind the scenes, so the message handler only has to focus on the message processing and call the specific Azure Service Bus message operations when necessary.
The registration of this kind of message handler is just the same as any other regular message handler can can be added with the .AddServiceBusMessageHandler or .AddMessageHandler extensions.
That's not all!
We’ve released more improvements such as:
- Less verbose logging for our message pump and TCP health probes. All telemetry is still there, but moved to Trace verbosity
- Additional correlation extensions to pass along your own custom operation/transation ID property name
All improvements help the developer and consumer to be in more control of our messaging functionality.
What's on the horizon?
We are exploring how we can make our message handler approach available to customers using Azure Functions to provide a consistent experience. This would mean that Azure Functions would act as the message pump, but you can re-use your existing message handlers.
Next to that, we are working hard to give customers more control in how incoming messages are being deserialized before they’re passed to the message handling.
Have a question, remark, feedback or idea for a superduper addition? Feel free to take a look at our GitHub repository and create an issue.
Thank you very much for reading and happy messaging!
Arcus Team
Subscribe to our RSS feed