The critical use case for BAM is to provide a simplified business-friendly view of the integrated processes that are key to your business. In business today, Robotic Process Automation (RPA) is a trending technology. While it has been around for quite a long time, it has gained a significant boost in popularity alongside the popularity of citizen developer and maker use cases. Microsoft Power Automate now includes modules in the RPA space, which has made the technology accessible to many users and scenarios through its association with the Microsoft Power Platform and Office 365.
RPA can let you try out the right ideas in automation, which you may re-make as a fully-fledged automated solution, or you may choose to keep the RPA solution if it just works for your needs.
Due to the popularity of opportunities RPA offers, customers will want to be able to fit RPA use cases into the same business activity monitoring (BAM) approaches they currently use for monitoring other critical business processes. With Serverless360, we wanted to explore how customers might use our BAM product to monitor RPA processes to ensure they can easily track progress, monitor, and troubleshoot.
Scenario
If we consider an example scenario, we will have a sales user meeting a customer. They will discuss a sales deal, and then when the sales user has concluded the deal, they will click a button on their mobile to trigger a cloud flow via the flow button.
The process for this example would be:
- The user captures some data on mobile
- The user clicks a button on mobile to submit data
- Power Automate cloud flow runs and queries additional information from SAP
- Cloud flow then runs a desktop flow to integrate with the legacy desktop application and process an order
The below diagram illustrates what this might look like.
This automated process will execute across several places, and we want a consolidated view of what is happening. We want to see what’s happening in a way that is easy to digest so that the support and business user does not need to be an expert to understand it.
By using Serverless360’s distributed tracing capability, BAM, we can send events about significant milestones. We will be able to send BAM events from the Power Automate Cloud flow and the Power Automate Desktop RPA flow, as shown in the diagram below.
BAM Design Time
I described how a real cloud and RPA combined solution might work in the scenario above. In a simplified demo to walk through how you can use BAM, we will design a business transaction that looks like the following diagram.
Here we have four steps. The “Cloud Flow Triggered” and “Cloud Flow Complete” steps will execute in the Power Automate Cloud Flow. The middle two steps will perform in our RPA Power Automate Desktop Flow.
In each stage, you will be able to configure the properties as shown in the image below, and the critical thing you want is the Tracking Name which maps to one of the fields of info you will pass from the Flow.
If you would like to take a step back for a moment and learn more about how to build the BAM transaction at design time, there is more information on this page: https://docs.serverless360.com/docs/bam-end-to-end-tracking
Implement BAM in Cloud Flow
In the cloud flow, we will manually trigger a flow trigger to allow a user to trigger the Flow from a flow button that can accept some user input, as shown below.
The cloud flow will then use the Serverless360 Start Transaction, telling BAM that we have started a transaction. The Flow will then call Power Automate Desktop to run a flow on a machine, and then it will use the BAM CheckPoint shape to indicate the Flow is complete.
The below shape shows calling the Start Transaction. We passed in some information, such as the order and triggered, so that we can see this in BAM.
The below shape shows calling the RPA process. The output from the BAM Start Transaction is a transaction instance id that we will pass down to the RPA flow, which will use this id to correlate BAM events it sends to the same transaction.
Finally, when the desktop flow is complete, we will use another CheckPoint shape to indicate the entire process is complete.
Implement BAM in Desktop Flow
In Power Automate Desktop (PAD), I can now create a flow that will perform actions when it is running on a machine simulating a user performing actions on the desktop.
In PAD, there is the option to use the Invoke Web Service action, allowing you to make an HTTP call from your desktop flow.
Design Decision
One of the design decisions I think you need to make here is how you will allow people to consume your BAM API. From a personal perspective, I would prefer to have RPA use cases call out to an API on my Azure API Management which sits in front of the BAM API. It is how most enterprise customers would likely do this because it gives you rich API Management features for monitoring an API and managing security for multiple users, which will help you support many different RPA projects.
If you decide to use API Management as a proxy to your BAM API, the only difference is that the hostname for your API and the key and header would be different. In this case, I will use APIM as a Proxy which is discussed in one of our previous articles.
View of RPA Desktop Flow
In the desktop flow, I am doing a brief demo below. I will set a variable, the API key, for calling my web service. I will invoke a web service, the BAM CheckPoint, which we also used above from the cloud flow.
I will then wait, simulating and performing some actions to automate the desktop.
I will then execute another checkpoint with the invoke web service action.
The below picture shows the desktop flow.
The first step in my Flow is the key for my API calls to BAM. I can either store this as a variable in my desktop flow or pass it in as a variable from the cloud flow.
If we look at the individual action for invoking web service, you can see that you do an HTTP post to the API Management, which then forwards the call to the BAM API. (Remember that you can call BAM directly if you don’t want to use APIM).
The key bits of information to supply are in the custom headers and body. If you note that the SL-360-TransactionInstanceId is the variable we passed in from the cloud flow.
The SL360-Stage will match the value of the tracking name property from the stage in the BAM designer.
The below picture shows the various settings for calling BAM.
There is one KEY point you need to remember here. When using this action, you need to turn off the encode request body property on the advanced settings for the Invoke Web Service. If you don’t turn this off, the JSON body will be encoded, and you will get an error. The below picture shows this setting.
In the request body, I provided the below JSON.
{
"messageBody":{},
"messageHeader":{
"OrderId":"%orderId%"
}
}
It allows me to pass a message body and an array of headers to BAM. In this case, I’m giving the order id. I could also pass others; maybe something like the machine name from the unattended agent would make sense.
Running the Scenario
When I save and deploy my BAM Desktop flow, I should now have my cloud and desktop flow available. I will see a flow button on my mobile that can run my process.
When I click this, it will open a form created by the Flow button to capture some data, and then I can click to start my Flow, as shown below.
If I want to see what happened to the execution, as a Power Automate user who knows what they are doing, I could go into Power Automate and look at the run history and see how the Flow executed, as shown below.
While this is a pretty good experience, what happens when you move this to the real world and scale it up? What if you have many users triggering processes and need to be able to let your support team, who aren’t Power Automate experts, provide that triage to support your solution to deal with everyday issues? Here is where BAM can help you.
BAM Runtime Tracking
If you are a super user or support user, then you could access BAM and see what is happening because we sent events from our Cloud Flow and Desktop Flow to BAM so we can get visibility of the transactions being processed.
Below is a view from the BAM track where some transactions are in flight.
By promoting metadata from the flows, we can create excellent views which make it easy to see what’s happening. We can also search within these views so that you can search for an instance related to a specific order id.
If you want to check what’s happening to a specific process instance, you can click on it in the above tracking view. It will open up an activity diagram, as shown below, representing the design time diagram you drew earlier in the article.
Here, each shape is shown based on the runtime data to indicate if it is executed and what the results were.
When the transactions finish executing, you can see in the below view both are finished.
Next up, you can click the transaction again and see all shapes are complete.
This tracking view should make it a lot easier to troubleshoot your Power Automate Desktop RPA processes.
Some of the other things you might choose to do when linking Power Automate Desktop or Cloud flows to BAM include:
- Send the run id from the Flow to BAM, so it’s easy to work out which Flow ran which process
- Send messages or responses to BAM so you can make them more accessible for the support user to see
- Promote additional metadata properties so you can search on them
BAM Dashboards
BAM has a dashboard feature that you might find very useful. Once your RPA processes are up and running and you are managing them with BAM, you might be interested to see some analysis of the success and performance of your processes.
With BAM, you will get a generated dashboard for some metrics about your process. You can also add customized widgets based on specific properties or criteria that will provide a rich view of what’s happening.
BAM Action Required
In BAM, we also have a feature called Action Required. The action required aims to help you manage any issues with your processes. If a transaction in BAM is recorded as a failure, it will appear in action needed list.
You can then ignore it and provide a message if you have handled it outside of Serverless360 or configure a reprocessing step that your Serverless360 BAM user can use to reprocess a message. It might allow you to configure a way for your support team to reprocess a message if needed, marking the transaction instance as having been reprocessed.
Action Required is about helping you keep things healthy by knowing what issues haven’t been dealt with yet.
Conclusion
I hope this article shows how easy it is to add BAM to an RPA solution. As customers become more invested in the power of RPA solutions, we believe that plugging them into the modules you use simplifies the management and operations of your other integrated solutions. It will help customers to provide excellent support services to the business functions that depend on IT support for the RPA processes they develop.
Top comments (0)