Updates in ServiceControl 4.13

ServiceControl is the nerve center of your distributed system, storing the data and providing the APIs that allow ServicePulse and ServiceInsight to function.

In ServiceControl 4.13, we’ve made updates that make saga auditing more useful, provide better support for Azure Service Bus, simplify license management, and make it easier to keep ServiceControl up to date.

🔗Saga audit processing

In the new version, we’ve scaled out saga audit processing so that you can use saga audits even in production.

Saga Audit is an NServiceBus plugin that greatly enhances the business process development and troubleshooting. When enabled in an endpoint with a saga, it allows ServiceInsight to visualize the Saga data changes as the process progresses, resulting in diagrams like this:

These diagrams make developing and debugging sagas much more powerful because you can execute the code and then see exactly what happened at each step, including the incoming messages, the resulting outgoing messages, and how the stored saga data changed as a result.

Until now the Saga Audit data could only be processed by the primary ServiceControl instance, the same one that handles the recoverability. As it adds significant load, we discouraged the usage of the Saga Audit plugin in production.

Now, the Audit instances of ServiceControl can process the Saga Audit data too, and these can be scaled out. The Saga Audit plugin has to be configured to send the data to the same queue as used for auditing. If needed, the audit processing can be scaled out by adding more Audit instances which means from now on the Saga Audit plugin can also be used in production.

When enabling saga audits in an existing system make sure to provision enough resources as the Saga Audit plugin sends one additional message for each message processed by a saga.

🔗Azure Service Bus topic name

We’ve made it possible for some customers using Azure Service Bus to subscribe to useful integration events published by ServiceControl.

Under the hood, ServiceControl uses the publish/subscribe pattern just like NServiceBus endpoints. When using Azure Service Bus as the transport, a topic (named bundle-1 by default) is used for these pub/sub operations.

NServiceBus with the Azure Service Bus transport provides an API to rename this topic for customers that have strict naming conventions in their environments. For instance, a customer might need the topic to be called CompanyName.Department.ProjectName.PubSub, or something to that effect.

This topic is shared among all endpoints, including ServiceControl, which can publish integration events when messages fail processing, when custom checks are triggered, or when endpoint heartbeats are missed. To support these features, ServiceControl must be using the correct topic name as well.

With the latest version of ServiceControl, you can specify a topic name by adding TopicName=<topic-bundle-name> in the connection string.

You didn’t really think we’d show you our entire Azure Service Bus connection string, did you? 😉

With this change, it’s now possible for the customers with strict naming convention requirements to subscribe to the notification events ServiceControl publishes. From these subscribers, they can send emails to monitoring groups, ping a Slack channel, or do anything else in code that is necessary to notify someone in the organization that the system may be unhealthy and in need of administrative action.

🔗Simpler license management

When we first released ServiceControl, customers had a lot of options for where to store their license files including multiple locations on disk and in various parts of the Windows registry. Since we created the ServiceControl Management utility, customers have been able to use it to manage their ServiceControl license, and it stored the license in the most common locations that ServiceControl instances would look for it.

This could lead to situations where ServiceControl Management and ServiceControl instances were looking at different licensing information, especially if they run under different credentials. ServiceControl instances would report via their API to ServicePulse that their licenses had expired, but ServiceControl Management would report that the license was current and valid (and vice versa).

We simplified this by reducing the number of locations that ServiceControl looks for licensing information to just one. Now, when you use ServiceControl Management to manage your ServiceControl license, it will be installed into a subfolder of the CommonApplicationData folder. Every ServiceControl instance will only check this location for its license. ServiceControl Management and ServiceControl instances are always looking at the same license data.

ServiceControl Management has been storing license files here since November 2017, so your license file is already installed there. Everything should Just Work™.

🔗Keeping up to date

ServiceControl is constantly updated with new features and improvements and we want to make sure that you know when they’re ready for you. While we already post announcements about every release in our discussion group, we wanted to make it even easier for you to see when ServiceControl gets updated.

At startup, ServiceControl Management will check to see if there’s a newer version available and if there is it will prompt you to download it.

Of course, you won’t see it until we release the next cool thing. Stay tuned for it.

🔗Summary

We’re constantly improving NServiceBus to bring you more features and greater stability. Unlike NServiceBus, we only support the latest minor release of any supported major version, so we encourage you to upgrade to ServiceControl 4.13 at your next available upgrade window.

You can always get the latest version of ServiceControl from our downloads page.