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.
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.
Conclusion
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