all Technical posts

Arcus Messaging v1.3: Added EventHubs Support, Correlated Service Bus Messages and Much More

The Arcus Messaging v1.3 release promises big changes. In this post, we'll go over the major parts of this release, including the new features, extended functionality, and useful helpers.

EventHubs' message handling support

Arcus Messaging v1.3 introduces a new type of messaging to the family: EventHubs messaging. Previously, we only supported Azure Service Bus messaging in both message pump worker, and Azure Functions trigger scenarios. EventHubs support is a long-awaited feature and received more priority due to the help of our internal community. Above all, this demonstrates how Arcus is driven by community work and not by influences higher-up.

Because of our very flexible messaging framework, we were able to quickly and easily add EventHubs messaging. A message pump implementation is available in the Arcus.Messaging.Pumps.EventHubs package and a message router implementation (for non-message pump scenarios, like Azure Functions) is available in the Arcus.Messaging.Abstractions.EventHubs package.

You can create your own EventHubs message handler implementation by implementing the IAzureEventHubsMessageHandler interface. This process is very similar to Service Bus. The only difference here is the use of a specific message context: AzureEventHubsMessageContext, which gives consumers access to EventHubs-specific information. This includes the EventHubs namespace, consumer group but also message-specific information like the partition key. This info is useful for message tracking during message processing.

The following example shows how a sensor reading can be processed from a message handler implementation.

Registering this implementation is also very similar to Service Bus. We provide an .AddEventHubsMessagePump(...) extension to register a message pump implementation that retrieves events from EventHubs without any additional action on your part. The consumers’ job is only to focus on how events, or in this case sensor reading events, should be processed.

⚠ Note that the EventHubs connection string and storage account connection string are not passed along directly to the message pump extension, but that a secret name is provided. This secret name should correspond with a stored secret in the Arcus secret store. For more information on the secret store, see our official documentation.

💡 The EventHubs message pump and message router have a lot more options to modify the message handling to your needs. See our official documentation for more information on this and other topics.

Correlated Service Bus and EventHubs messages

Service-to-service correlation is a big focus within Arcus. We have already updated our Web API package to fully support send/receive operations of correlated HTTP requests/responses. This results in a clear overview of all the interactions between multiple components in Application Insights. The same correlation functionality is now added to the Messaging library, making almost all our components correlation-ready.

Retrieving and processing messages via message pumps or message routers automatically results in request telemetry in Application Insights, so no consumer action is required here. Placing messages on Service Bus or an EventHubs queue requires you to use one of our extensions on ServiceBusSender or EventHubsProducerClient respectively. Usually, when interacting with Azure in this way, you register these clients into your application so they can be injected, reused, and tested easily. Azure SDK clients is a great way to do this.

Registering your clients this way provides you with an IAzureClientFactory implementation from which you can create a ServiceBusSender or EventHubsProducerClient instance. This example shows that with one of the provided SendAsync extensions, you can pass along your application correlation so that the send-out message will be correlated. This works well together with our message pumps/routers.

⚡ We have similar functionality for EventHubs where we provide SendAsync extensions on the EventHubsProducerClient.

For more information see our official documentation for Service Bus extensions and EventHubs extensions.

💡 We have a user guide that explains fully how service-to-service correlations work for applications that integrate Service Bus.

Removed exception details from TCP health probe

We also added a small feature with a big security impact to this release. The v0.8 Arcus Templates release included a dedicated API health report model with the exception details removed. These details are useful for defect localization but are unnecessary information for the public eye. In certain cases, this information could be used maliciously and pose a security risk.

The Arcus Messaging also has a variant on this health report endpoint, which is our TCP health probe that exposes the health of an application via a configurable TCP endpoint. This was using Microsoft’s default health report, which included exception details.

Starting from Arcus Messaging v1.3, these exception details are removed from the public endpoint which makes it a safer and production-ready implementation.


Arcus Messaging v1.3 is a big release with support for EventHubs, but also provides extensive functionality to fully support service-to-service scenarios. Have a look at our release notes and official documentation for more information on this new release.

If you have any questions, remarks, comments, or just want to discuss something with us; feel free to contact the Arcus team at Codit.

Thanks for reading!
The Arcus team

Subscribe to our RSS feed

Hi there,
how can we help?

Got a project in mind?

Connect with us

Let's talk

Let's talk

Thanks, we'll be in touch soon!

Call us

Thanks, we've sent the link to your inbox

Invalid email address


Your download should start shortly!

Stay in Touch - Subscribe to Our Newsletter

Keep up to date with industry trends, events and the latest customer stories

Invalid email address


Great you’re on the list!