At Codit, we have been doing messaging since the company has started – initially by using Microsoft BizTalk Server, but over time we’ve been writing apps built on messaging in Azure as well.
We’ve discovered that we’re constantly having to write the same boilerplate for processing message queues over and over again and it’s a huge hurdle!
That’s why we’ve decided to use our experience and start Arcus Messaging and Arcus Background Jobs. This helps you clear that hurdle by providing all of the boilerplate – so that you can focus on the application that you are building!
Recently we released v0.1.0 of the Arcus.Messaging and Arcus.BackgroundJobs and they are now available on NuGet.
Both help with writing repeating jobs that securely receive external events and process them any way you want.
Check it out and see what they have to offer!
Receiving Messages From Azure Service Bus Queues and Topics
With Arcus Messaging we make it easier to process messages. By using a message pump, we will automatically get messages from a broker where we support Azure Service Bus for now.
This pump can be registered very easily on startup of your application and provides exception handling, deserialization, telemetry and more.
Once registered, one or more message handlers can be plugged in which will process messages.
Based on the message type, the pump will send the message to the correct registered handler.
This allows a loosely coupled system between receiving and processing.
By using our Arcus.Messaging.Pumps.ServiceBus NuGet package, you can configure such a pump during startup.
See the following section as an example to handle Order messages with a custom OrdersMessageHandler implementation.
Where the your OrderMessageHandler will process the Order messages received on the Azure Service Bus Queue:
Monitoring Health of a Worker
With Arcus Messaging we provide the capability to expose a TCP health probe endpoint that allows processes to periodically check the readiness of the application which is extremely important in container workloads.
This allows you to expose a health endpoint without having to include the HTTP stack in your workers, keeping your application simple.
Instead of reinventing the wheel, we’ve decided to build upon the built-in .NET Core Health Checks which allows us to integrate with existing tooling and leveraging a very compatible system.
By using our Arcus.Messaging.Health NuGet package, you can very easily opt-in to expose the TCP endpoint:
Automatically Invalidate Azure Key Vault Secrets
With Arcus Background Jobs we provide capabilities for running a background job that automatically invalidates Key Vault secrets based on Azure Event Grid events emitted by the vault.
Adding this job to you application ensures that your cached secret providers in your application are always evicting the cache to use the most recent secrets.
By using our Arcus.BackgroundJobs.KeyVault NuGet package, you can very easily opt-in to automatically invalidate Azure Key Vault secrets:
See the docs for more info.
What’s next?
We’re just getting started and we’re looking forward to rolling out more features.
There’s a lot of things we’d like to tackle, such as:
- A background job to report Databricks job outcome as a metric allowing you to create alerts on them (Background Jobs #26)
- Provide support for using message pump for Azure Event Hubs (Messaging #24)
- Provide capability to support multiple message handlers based on message context (Messaging #26)
- Provide capability to support multiple message handlers based on message body (Messaging #27)
- Provide support for multi-staged message processing (Messaging #25)
- Provide support for key rolling for Service Bus message pump (Messaging #37)
- Provide health check for Azure Service Bus message pump (Messaging #38)
However, that list is just to start and we are always open for feedback! What do you think is painful or what would you like to see? Let us know.
Thanks for reading,
Stijn & Tom
Subscribe to our RSS feed