PRA PowerBI Monitoring Dashboard 

In our previous blog you can find how to connect PowerBI to UiPath Orchestrator. Today we will demonstrate how to create useful monitoring reports. 

Why Monitoring Dashboard is important? 

After publishing robots in production, it is very important to monitor real time results of automated business processes in one centralized place. Using Power BI, you can present everything that is important for achieving goals defined initially and any other key statistical data showing bot execution results. Power BI offers boundless flexibility in terms of which data we want to show, and in which format. This solution is applicable to any RPA environment that logs its transaction results (UiPath, Power Automate, Blue Prism…). 

We chose PowerBI to present all data because in this way we have everything in one place. We can create metrics that we want, define specific KPIs that we want to follow and create powerful visualizations. 

What to present in Power BI reports: 

  1. Different KPIs such as results of reduced time, cost efficiency, quality of execution and other measures about goals that are defined by top management and end business users 
  1. Performance success rate for revisions and bot optimizations in maintenance phase 
  1. Number of bots running in the organization, machines on which robots are executed 
  1. Overview of transactions in many ways 

All mentioned items and many others are important to determine and measure the success of the implementation of RPA in the company. 

PowerBI example report 

Data source 

Data like process name, organization unit, type of robot, queue name which are presented on the report are stored in SharePoint list because of real time refreshing data in the report. You can store data in other sources by your choice. If you store data in excel you will need to set a gateway for real time refreshing data. 

Data about transactions are retrieved from UiPath Orchestrator through connection which you can create through steps that we defined in our previous blog. Data from SharePoint and Orchestrator are connected through Queue name. When you directly connect PowerBI to Orchestrator there is a predefined time limitation, so that you can retrieve data for approximately past 12 months. If you need all transactions without time limitation, our advice is to get them with an API call out of PowerBI and store it in the database. 

Dashboard 

Dashboard presents all the basic information about RPA processes in the company. From Dashboard you can drill through other pages. 

Table visual presents all organizational units and processes to which that process belongs. There is also a date when the process was published to production environment. The last column is about savings in minutes.

Beside the main table there are card visuals that present the number of processes, number of attended and unattended processes per selected organization unit. Also, there is a decomposition tree which visualizes data in multiple dimensions.

Through a dashboard report you can easily present the basics of robotic process automation across company. From main page, we can drill trough Process details page.

Process details page with drill trough for Process D

Process schedule page

On Process schedule page is calendar presentation when the process should execute.

Transactions overview

Transactions overview presents successfully finished transactions per month, per process and per organization unit. There is a table with comparison of successfully finished transactions in the current month and in previous months. KPI demonstrates successfully finished transactions in this month where the target is the number of successfully finished transactions in previous month.

Conclusion

Monitoring of RPA bots in Power BI gives a powerfull overview of automatized processes in the company. This way you can follow different KPI-s, ROI, FTE savings, accuracy, quality and other RPA metrics. Reports present significant information about bot executions based on which you can optimize and improve quality of execution.

Working with same browser instance between multiple desktop flows in Power Automate

Introduction

In this article we will present how to work with the same browser instance through workflows in Power Automate Desktop and how to focus specific tab when there are multiple tabs.

Situation

Input and output workflow variables are the essential building blocks for making a decoupled RPA Process Architecture. Currently, Microsoft Power Automate Desktop does not support passing a browser instance as input or output variable.

A problem occurred when trying to use the same browser instance within more desktop flows. When you open another desktop flow, you must have browser instance to work with UI elements.

 If you don’t want to produce a new one, you can’t continue working.

And if you want to produce a new browser instance, attached to the one already running, a problem occurs with working with multiple tabs – attaching to a running browser instance with multiple tabs open may not switch focus to the needed tab.

Why this is a problem?

Let’s assume you have automated 10, 50 or even 100+ processes in your company. Assume your ERP client is a web application, as many of current ERP nowadays (e.g., T24, JD Edwards, Dynamics 365…).

Many of these processes will require logging in into this ERP to read data or process transactional information. 

Without the possibility to pass browser instances between workflows, you are forced to create a login section in each individual process workflow. Imagine now that with your 100+ automated processes, ERP login process is changed. You will need to make changes in each of the 100+ workflows that are using the ERP. 

What to do

A simple solution to this problem has three steps:

First step – deconstruct Browser instance from the parent workflow as custom object. Be sure to include the current URL, page title and other variables that can help you to reference this browser. 

Second step – Pass this custom object to the child workflow. 

Third Step – In a child flow, attach to a running browser instance using the Title, URL or other parameters. If that does not work, use the Handle property from deconstructed browser instance. 

We will create a desktop flow“Passing BI” in which we will initialize a browser instance and all required attributes, and after that we will create a second desktop flow “Receiving BI” that receives these information.

First step: Parent flow

Desktop flow – “Passing BI” setup:

First, we want to launch a new Browser and with it we are producing a new Browser Instance which we’ll use.

Variables that are required are URL’S to pages you want to work with. So:

  • Open new tab

 for example, purposes and using variable URL. Variable produced is set to same “Browser” instance, and by that it is being overwritten.

Right after tab is opened, we are using

  • Get details of web page” action getting the “Web page title”,
  • “Get details of web page”  action getting the “Web browser’s current URL address

just in case to be sure initial URL is not changed after opening page (in case it changes, we’ll overwrite our initial URL variable with correct value).

When we add those acitivites, workflow looks like this.

Web browser instance is not acceptable as input argument, so we cannot just pass it as it is.
On that account, we will create logic for passing necessary attributes by

  • initializing new variable as JSON

Next, we need to

  • convert it to custom object

 and after that variable is ready to be sent.

Second step: Passing custom object to child workflow

At the end “Passing BI” desktop flow should look like this:


Before calling “Receiving BI” desktop flow and passing our custom object as input value, we need to set it up:

Third step: Child flow

Desktop flow – “Receiving BI” setup:

The idea is that “Receiving BI” called from “Passing BI” is not opening / launching new browser, but only focusing already opened browser tabs.

Although we can pass object with browser attributer, passing it doesn’t allow us to assign type “Web browser instance” but staying as custom object, therefore is not usable for working with UI elements which requires type “Web browser instance”.

Let’s set input variable “inCustomObject” as type ‘custom object’

so, when “Receiving BI” is called, we will have defined input variable, and we can pass JSON as Custom Object Value.

Next,

  • “Launch new browser” with “Launch mode” set to “Attach to running instance” and attach by title using passed tab title value (both title and URL are passed, so it’s your choice).


Unfortunately, this option alone will not change tab focus, although it will attach our new browser instance to the existing one.

For this reason, we are using

  • “Send keys” with keys shortcut for switching tabs by specified order

“CTRL + 2” for second tab in line with passed tab index value sent to window instance/handle “Browser” instance as in the image below

The last step is now at your disposal to choose actions for working with UI elements (e.g., get details of the UI element). Now we can work without any further delays!

Whole “Receiving BI” flow process is shown below:

For those situations where attaching to a running instance by URL or Tab Name is not possible, there is a possibility to focus on a desired tab by sending hotkeys using the process handle from the Browser object. Afterwards, we will attach to the current active browser instance, pre-focused using the process handle.

That way, we have the possibility to share browser instances between different workflows.

How this solution works?

This solution gives us the opportunity to not repeat our actions (e.g., opening and closing tabs) and reuse the same browser instance within different desktop flows. Makes the process more compact and easier to work with. You still manage the browser instance from the flow who call it but all code for login routine is in its own flow, so in the future you don’t need to waste your time editing your flow one by one if there is e.g., CSS change on the website. You just need to edit/update your login flow routine 1 time. 

Povežite "Power BI" sa "Orchestrator"-om za automatizovane izveštaje robota (1/2)

Ovaj članak obrađuje temu povezivanja "Power BI" sa "Orchestrator"-om radi koriščenja njegovog interfejsa (API) za generisanje korisnih izveštaja. Prvi deo teksta se odnosi na povezivanje vašeg izveštaja sa "Orchestrator"-om.

Zašto povezivati "Power BI" sa "Orchestrator"-om

Mnogi od nas koji se bavimo razvojem rešenja u automatizaciji procesa primenom robotike smo svojevremeno pravili izveštaje robota odnosno zapise aktivnosti robota. To su mahom bili Excell izveštaji gde su sve transakcije prikazane iz poslovne perspektive (status, vremenski pečat, bitne stavke itd.) i korisnici su mogli da prate nivo uspeha robota. Dok je korišćen "Studio" i "Attended robot", ovo je i bilo adekvatno rešenje.

Danas kada je većina kompanija izgradila infrastrukturu u dovoljnoj meri i ima uspostavljene "Orchestrator"-e, Podaci iz njih i "Power BI" zajedno, mogu da iznedre moćne mehanizme za izveštavanje i praćenje rada koji se mogu koristiti više puta.

"Orchestrator" sam po sebi u paketu nosi raznovrstan izbor unapred pripremljenih izveštaja, međutim ovo često nije dovoljno. Istina, kombinovanjem "Orchestrator"-a i "Kibana"-e možete postići slične rezultate. Sa druge strane, ukoliko vaša firma pretežno koristi "Power BI" ili su vaši radnici veštiji sa njim nego sa "Kibana"-om, ovo je članak za vas.

Iako je moguće uspostaviti direktnu vezu između "Power BI" i "Orchestrator"-ove SQL baze podataka, u poslovnom okruženju administratori baze podataka će vam obično zameriti ako samo pomenete direktan pristup bazi. Iz ovih razloga ćemo vam pokazati kako da povežete "Power BI" sa "Orchestrator"-ovim "API" imajući pristup samo Orchestrator-ovom web interfejsu.

Preduslovi

Da biste izradili korisne izveštaje kombinovanjem "Orchestrator"-a i "Power BI", preporučljivo je da se pridržavate sledećih principa:

  • Primenite "Dispatcher-performer Pattern" i koristite "Orchestrator Queues"
  • Kvalitet pristupa "Orchestrator"-u (adekvatni kredencijali)
  • Posedovanje "Power BI Pro" licencu za korisnike koji će pratiti izveštaje robota

Iako postoji mnogo načina da iskoristite podatke "Orchestrator"-a bez korišćenja prethodne tri postavke, da biste u potpunosti iskoristili potencijal ove kombinacije, treba da ispoštujete napred navedene korake. Hajde da pogledamo kako izgleda uobičajeni "Orchestrator Queue".

Svi ovi podaci, kao i potpuno prilagodljivi dodatni podaci koje možete dodati u "Queue", dozvoljavaju skoro neograničen broj načina za formiranje izveštaja. Najvažnije, ovo doprinosi standardizaciji praćenja robotizovanih transakcija. Odvojeni tekst će se pozabaviti važnošću "Orchestrator Queues" i "Dispatcher-Performer Pattern", a sada da vidimo kako povezivanje izgleda u praksi.

Povežite vaš Power BI sa Orchestrator-om

Dobijanje podataka iz "Orchestrator"-a se vrši pomoću 2 "Orchestrator API call"-ova

  1. "Authentication call"
  2. "Data Request call"

Da bismo izveli autentifikaciju (prvi korak), neophodni su nam kredencijali. Preporučljivo je da napravite "read-only account" za izvršavanje "API call"-ova jer većina koristi "hard-coded" šifru u "Power Query"-ju.

Otvorite Power Query

Da biste izvršili autentifikaciju, trebaće vam kredencijali (dozvole), tako da najpre pravite "Blank Query" i nazivate je "Credentials" :

let
    Source = [
        tenancyName = "YOURTENNANTNAME",
        usernameOrEmailAddress = "READONLYUSERNAME",
        password = "READ-ONLYUSER PASSWORD"
    ]
in
    Source

Zatim, potrebno je da napravite vaš "API Request". "API Request" će se razlikovati u zavisnosti od prirode vašeg Orchestrator-a, odnosno da li je "on-premise", "cloud" ili "community" verzija. U nastavku možete videti prikaz "on-premise" varijante i odvojenog "Tennant"-a.

Da biste se lakše snalazili u "API", možete se pozvati na "swagger documentation site". obično se nalazi ispod YOURORCHESTRATORURL.com/swagger/index ili YOURORCHESTRATORURL.com/swagger/ui/index

let
    BaseUrl = "YOURORCHESTRATORURL"
    Path = "/odata/QueueItems",

    Auth = Json.Document(Web.Contents(BaseUrl, [Headers=[#"Content-Type"="application/json"], Content=Json.FromValue(Credentials), RelativePath="/api/account/authenticate"])),
    Token = Auth[result],

    Source = Json.Document(Web.Contents(BaseUrl, [Headers=[Accept="application/json", #"Authorization"="Bearer " & Token #"X-UIPATH-OrganizationUnitId"=YOURORGANIZATIONUNITID], RelativePath=Path]))
in
    Source

Ali sačekajte, gde bi mogli da pronađete vaš "OrganizationUnitld"? Da vidimo...

Identifikujte OrganizationUnitld koristeći Orchestrator API UI

Naravno, tako što ćete "pozvati" još jedan API. Alternativno, možete ići direktno do "swagger page" (kao i ja) i pribaviti "peške" vašu organizacionu jedinicu pozvavši GET na foldere kako biste dobili folder id.

Kada aktivirate GET po folderima kao rezultat treba da se pojavi nešto poput ovoga:

Id foldera je taj "Organizationunitld" koji treba da koristite prilikom pozivanja "Orchestrator API" radi dobijanja "queue items".

Dakle, u našem slučaju "Default folder" je 31 te ćemo u naš konačni kod (osim za vaš bazni Url) treba da poprimi ovakav izgled.

let
    BaseUrl = "YOURORCHESTRATORURL"
    Path = "/odata/QueueItems",

    Auth = Json.Document(Web.Contents(BaseUrl, [Headers=[#"Content-Type"="application/json"], Content=Json.FromValue(Credentials), RelativePath="/api/account/authenticate"])),
    Token = Auth[result],

    Source = Json.Document(Web.Contents(BaseUrl, [Headers=[Accept="application/json", #"Authorization"="Bearer " & Token #"X-UIPATH-OrganizationUnitId"=31], RelativePath=Path]))
in
    Source

Ako "Power Query" prigovara, idite na "Edit Credentials" i izaberite "Anonymous Access". Kada se koristi autentifikacija pomoću tokena dozvoljen je samo "Anonymous Access".

Ta da! Sada imate vezu sa "Orchestrator API". Sledeći tekst će obraditi kako da napravite robo-izveštaje za praćenje statusa transakcija i performansi robota.

sr_RSСрпски језик