In the real world, when we implement systems, there are often many kinds of users, such as super business users and some level 1 support technicians who understand the application domain and can support a lot of your applications. Still, due to limited skills and experience with Azure, they are constrained to how much of the application they can help.
A great example of this is when you have a solution that uses Azure Service Bus. If you have problems processing received messages, they get added to the dead letter queue. Often there is a support requirement for the messages to be triaged, possibly repaired and then resubmitted.
The conflict here is that the Azure experience and security privilege needed to support Azure Service Bus are high. Hence it is difficult for anyone other than an Azure Expert to support this part of the solution.
In Turbo360 Business Applications, we aimed to democratize this and allow an IT Support Operator with some knowledge of Azure to support queues from Azure Service Bus.
Sometimes you may need to democratize that even further so that you can allow someone who has almost no knowledge of Azure to support the messages that have failed to be processed. Hence, it will enable you to enable the support to use for your destination application or a business superuser to have visibility and access to manage your messages. Then, they can escalate an issue to your Azure experts if they cannot resolve the problem.
Using BAM, I was able to help a customer implement this pattern, and this article will demonstrate how you could achieve distributed tracing that is essential to monitor, debug, and optimize distributed Azure applications.
Scenario
Imagine a scenario where we have an order capture website that accepts orders from a customer and calls an Azure Function to write the order to a queue on Azure Service Bus.
A 2nd Function will then process the Azure Service Bus messages and load the order into CRM. The below picture shows this architecture.
In this scenario, the worker function will attempt to load the order into CRM, and if there is an error, it will perform retries based on the queue configuration.
If the retries are exhausted, the Service Bus will move the message to the dead letter queue, and the functions will move to the following message.
There can be several different causes that could result in messages being unable to be processed, including:
- Invalid messages
- Problems with the destination system
Azure Service Bus moves this message to the dead letter queue so that someone can check into the issue, and then when the issue is resolved, they could move the message back to the main queue, and it would be reprocessed again.
If you do not manage your dead letter queues, you might have a problem eventually filling up.
Your support user needs to look at this queue.
Many tools could help you here, such as:
- Azure Service Bus Explorer is an advanced tool for Azure Administrators
- Azure Portal offers an essential Service Bus Explorer preview feature for Azure Administrators
- Turbo360 offers a Business Applications feature where you can allow an IT support operator access to manage a queue
However, the problem is that you need to be an IT support operator who has a decent amount of knowledge of what you are doing for all of these options.
In the real world, there is a lot of value and cost-saving for a business if they can allow their domain experts or front-line support operators to be able to review the messages that cannot be processed, and they can resolve issues without having to escalate to their most experienced Azure experts.
Here is where the Turbo360 BAM feature can help. BAM is intended to allow non-expert users to be able to interact with processes in a friendly way. We would be able to use a Logic App to subscribe to our dead letter messages and push them to BAM to be managed in a user-friendly way via the Turbo360 portal, as shown below.
The BAM user will then search for messages and easily find the ones they are looking for. They will be able to track which ones have been addressed and know which messages still need fixing. They will also be able to create dashboards to see information about their processes performance.
The BAM user will also repair and resubmit messages back to the worker queue without needing an Azure Expert.
BAM Tracking
When we receive messages into BAM from the dead letter queue, they will be displayed with the promotion of information from the message. You have a searchable grid for messages like shown below, where you can see I am searching for the message which meets the customer id criteria shown below.
The grid will display dead-lettered messages, and I will click on one and open the BAM transaction below.
If you are already familiar with BAM from Turbo360, you may have seen this transaction view before and noticed that it’s a straightforward transaction. In this scenario, we don’t need a complex diagram because we have one shape to indicate that we have received a dead letter message.
If we click the stage marked in red, we can open it up, and we will see properties as shown below that were promoted for the search grid and show the message body if it was archived.
BAM Action Required
One of the features in BAM is action required. It’s important to know if you have work to do or if everything is ok.
Action Required is a list of errors that haven’t been taken to address the issue.
You can see below the action required list. In this scenario, you will probably be listing all dead letter messages as failed transactions so they would all appear in your effort required list.
When managing these errors, you have a couple of actions available:
- Ignore
- Reprocess
- Add as a favourite so you can easily find it later
When a message was reviewed, it was found that no action was needed. You can indicate the transaction can be ignored. This indication will remove it from the action required list. The transaction will still be accessed via the search, but you have removed it from the effort needed list.
If you need to resubmit the message for processing, you can do it from BAM to configure this for your transaction. You also have the option to repair a message if the data is invalid.
Try BAM
If you want to explore how BAM can help you implement interfaces that integrate with SAP or other systems using the Microsoft Integration Services, go to the Azure Distributed Tracing Tool page for more info and a trial.
