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 Serverless360 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
- Serverless360 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 Serverless360 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 Serverless360 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.
This article was originally published on Serverless360 site.