all Technical posts

Introducing More Message Flow Control with Azure Service Bus in Arcus Messaging v0.5

Previous versions of Arcus Messaging have a set of message handling system where messages can be routed and processed according to contextual information, but it didn't cover all the scenarios that our customers have, such as providing a way to manually dead-letter a message.

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.

 

Fallback message handling

We’ve introduced the capability to fallback to a dedicated message handler when no other handler criteria is met.

When a message is received on the message pump and there is not a single registered message handler that can handle the message correctly based on the message routing, the library provides a way to route your message to a fallback message handler.

This can be used as a fail-safe to create awareness of these messages or when you expect that the received message will not always be handled.

For more information on this topic, see our dedicated docs page that explains this concept more thoroughly.

The fallback message handling can be used to dead-letter messages, for example, so that an operator can have a look at them and decide they were not correctly processed due to a bug or if it’s the expected behavior.

Here’s an example of how a normal IServiceBusFallbackMessageHandler is implemented.
AzureServiceBusFallbackMessageHandler is an IServiceBusFallbackMessageHandler implementation which provides the specific Azure Service Bus message operations

 

When you decide you want to dead-letter the message, you’ll have to implement AzureServiceBusFallbackMessageHandler instead.

 

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:

 

Providing capability to directly decide what to do with Azure Service Bus messages

We have introduced three new message operations for Azure Service Bus which you can now use in your message handlers:

  • Completing a message which marks the Service Bus message ‘complete’ on Azure so no other queue can process it again (this is normally done automatically but can be turned off so you’re in full control).
  • Dead lettering a message which marks the Service Bus message ‘dead lettered’ on Azure so it’s moved to the dead letter queue.
  • Abandoning a message which marks the Service Bus message ‘abandonned’ on Azure.

 

Specific Azure Service Bus message handlers

Because of the way the message handlers are registered and used inside the application, there’s no ‘callback’ function to access the Azure Service Bus.

That’s why we’ve created two dedicated message handlers for Azure Service Bus which allow you to interact closely with the message itself so that you can influence the message processing.

  • AzureServiceBusMessageHandler: is an IMessageHandler implementation which provides the specific Azure Service Bus message operations.
  • AzureServiceBusFallbackMessageHandler: is an IServiceBusFallbackMessageHandler implementation which provides the specific Azure Service Bus message operations

The IAzureServiceBusMessageHanlder<> is used here as shortcut, which in fact implements the IMessageHandler<>.

 

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.

 

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

Let's talk, what's your first name?

Press Enter

Press Enter

Hi , what's on your mind?

Press Enter

Great! Leave your email and we'll be in touch
Submit
Thanks, we’ll be in touch soon!