Recently we released a new feature for Business Activity Monitoring and one of our customers was able to get almost immediate value from this feature with an integration use case they were struggling to support.
The solution implemented involves the source data coming from various operational technology systems that push data to an event hub.
From there, the customer uses an Azure Function as a bridge from Event Hub to Service Bus, which is then used to use a pub/sub pattern to push messages to various systems. The solution looks like the one below.
When it comes to monitoring this solution, the customer is using Application Insights with Azure Functions and logging to App Insights is happening as each message is processed. In this case, the customer has a combination of out-of-the-box logging of those functions by default, which is a common pattern developers use with Azure Functions.
In this scenario App Insights provides a lot of low-level features for the developer to be able to explore the logged data and understand the performance of the solution.
The challenge that they have is that other stakeholders have questions about this interface. These stakeholders have no visibility of the integration or the logs and if they did the logs are too complex for them to use in a meaningful way. These stakeholders could be business super users or users/support teams for other applications who are waiting for their data to arrive.
This results in support tickets being raised to the developer who then stops what they are working on to query if a message for truck 123 was processed or not.
The outcome we want is as follows:
- To deal with these questions as early as possible
- Let’s have a positive customer experience for the users who depend on the integration
- Let’s stop taking the developer off the project work they are trying to do and have them chase support tickets
The customer was able to use the Log Query feature in Turbo360 BAM to provide a self-service view for users outside of the integration team so that they can check on what’s being processed.
Using some KQL queries, the developer was able to set up this view in about 15 minutes using the existing data they already logged and without needing to change any code.
The result is they have a dashboard like below where the end-user or support user can use Turbo360 to see a list of the messages being processed and some of the key properties they care about. They can also use Turbo360 to easily craft custom searches such as by filtering for a given Order ID.
When the user clicks on a message they are interested in, Turbo360 will open the transaction. The developer configured a user-friendly view to show what has happened by bringing together additional log messages to show the key information they want the user to see.
The user can even click on one of the steps and see more information. In this case the developer had been logging small messages with the log events which the user in BAM can now see if you want them too.
The end result for the customer is that they have short-cut their support escalation by using Turbo360 to provide self-service for users and support operators so that they can resolve queries and support questions without the need to escalate to the developer, who can continue to focus on the project development.
For this customer, within an hour, they had set up and got their users able to do self-service. This less than the time the developer would often spend on a single support query which is a really great return on investment. They are now looking at other places where they can use the same feature to get more value from the logging they are already doing.
