Robotic Process Automation: Exception Handling, Debugging, and Logging, Study notes of Robotics

Download Robotic Process Automation: Exception Handling, Debugging, and Logging and more Study notes Robotics in PDF only on Docsity!

Exception handling

MODULE 5

Exception Handling, Debugging, and Logging

Exception handling is a way to handle exceptions for a process that the program or the procedure has failed to execute. For handling exceptions in a program, the best practice considered is to use the Try catch activity. The Try catch activity can be found in the Activities panel. By dragging and dropping the Try catch activity into the workspace, we can handle exceptions. For handling errors in the Try catch block, we can divide the whole process into four parts just to make it simpler:

• Drag and drop the Try catch activity
• Try block
• Catch block
• Finally block These steps are illustrated in the following example:

1. Drag and drop the Try catch activity: Create a blank project. Drag and drop the Flowchart activity into the Designer panel. Search for the Try catch activity in the Activities panel and drag it into the Flowchart. Set it as the Start node:

3. Catches : Inside the Catches activity, first we have to click on Add new Catch and then click on Add Exception option, from which we have to select the type of exception. In most cases, System.Exception is preferred. The following screenshot shows the types of exception. There are many more exceptions which can be viewed by clicking on the Browse for Types option: Say the execution fails: for example, the Click activity is unable to be executed because of the unavailability of a UI element. In such a case, we can use the Catches block in order to either view the error that has occurred or for an alternative method to be used if that particular error occurs. As shown in the following screenshot, we will drop the activity in the Catches block. To print a message, we use a Message box : When we click on Add new catch , we are asked to select the type of exception. We have selected System.Exception. Now inside the exception block, we have dropped a Message box activity. Entering exception.ToString will display the error that occurred during execution.
4. Finally : When we have defined the exception for our sequence, the Finally block will always work, regardless of whether the execution was successful or not. Suppose we want to display a message to the user notifying that the process is complete. To make sure that the whole Try catch activity is executed, we will just drop a Message box activity in the area provided in the Finally block, as shown in the following screenshot:

Common exceptions and ways to handle them

Unavailability of UI element:

When working on UiPath, especially on the web, we may encounter this type of error. This is because the UI element was not found due to the dynamic behavior of the web page. To handle this exception, we have to make changes in the selector attributes or we have to add new attributes to the selector so that the UI element can be easily found. For example, if we have a variable which is dynamically changing, we can use a wildcard so that it can be easily found by the robot. We can edit the dynamic attribute of the selector using wildcard characters. Another way is to attach it to the live element.

Handling runtime exceptions:

We may encounter runtime errors while working in UiPath. To rectify these errors, one of the best practices is to use the Try catch activity, which can be used to handle exceptions at runtime. By keeping an alternative inside the catch block, we can also overcome the error which we encountered before.

Logging and taking screenshots:

Click Generic error - cannot use UI CONTROL API on this UI node please

use UI Hardware ELEMENTS method

This type of error occurs when the environment in which we are trying to use the Click activity does not support Simulate or Send message activity (used by us to click the UI element). Sometimes, either SimulateClick or the SendWindowMessages may be checked. In both cases, when an exception is thrown we just have to uncheck the appropriate box. UiPath has a multi-process architecture that offers to execute each workflow separately in the executor. Executors are managed by UI robots. So, if any executor stops working, then the entire process will not be affected.

Client logging

Client logs basically enable a server to record connections. These logs can be used by content providers in various scenarios, such as to generate billing, to trace media server usage, or to deliver suitable quality content depending on the speed of the client's server. For client logging in UiPath, we have an NLog configuration file which makes it easy and flexible to integrate with databases, servers, or any other NLog targets. Logging can be configured with this NLog.config file. UiPath Studio, Robot, and workflow execution generate log messages on the client side:

• Messages which are produced by the workflow execution are logged with the execution logging source. Messages produced by UiPath Studio are logged as Studio Source and those produced by UiPath Robot are logged as Robot logging Source.
• We can also access these logs from UiPath Studio. We can access the stored logs by clicking on Open Logs in the EXECUTE option. By default, these Logs are saved in %Local App %\Uipath\Logs :
• The automatic logging mechanism for all errors generated, including values of variables and arguments, may be enabled in the UiRobot.exe config file, which is present in C:

Debugging techniques:

\Users\Username\AppData\Local\UiPath\app-17.1.6435, by setting the Log parameter from 0 to 1 inside the section.

• We have two activities that can be used for logging and these are the Log message and WriteLine activities.

Server logging

If you have configured the UiPath server, then all logs generated by the execution are also sent to the server. You can take a screenshot anytime by pressing Ctrl + PrtScrn. There are various techniques provided by UiPath Studio for debugging in order to check whether the workflow is running successfully or to find out errors in order to rectify them. At the top of the UiPath window, we can see various available methods of debugging inside the EXECUTE block, as shown in the following screenshot:

When we click on Step into , the relevant part will start to execute; after we click on Step over , execution will jump to the next part, and so on

Slow step:

This is an activity in the EXECUTE block through which we can reduce the execution speed of a particular process or activity. This way, we can identify each and every process and keep an eye on where to find the error. In the Output panel, all activities or steps can be viewed. The following screenshot shows how to use the Slow step activity:

As indicated by the arrow in the preceding screenshot, when we click on Slow step the execution time for this particular step increases.

Highlighting:

Highlighting is used to highlight the steps we have taken during automation and to identify each and every step in the workflow. It is very useful while debugging and its panel can be found in the Options menu of the Execute section in the Ribbon:

Break:

The Break activity is used to break a process at a certain point. Suppose we have a sequence performing seven activities together and we want to break the execution at a certain activity. For this, we can use the Break activity, as shown in the following screenshot:

Collecting crash dumps basically refers to collecting information when your UiPath Studio crashes. We can enable and disable crash dumps. These dumps provide us with information regarding the UiPath crash. Memory dumps are of two types:- full dumps and minidumps. Full dumps provide us with complete information about the encountered crash while minidumps provide us with just the main information regarding the crash. When a crash is encountered, we first have to identify the process which has crashed. Usually, a dialog will appear on the screen indicating the nature of the crash and the application involved. A UiPath process could crash, such as UiStudio.exe, Uiexplorer.exe, or Uilauncher.exe, or the target application you want to automate may crash.

Enabling crash dumps:

The following are the steps to enable crash dumps:

1. To enable crash dumps, we first have to download the EnableFullDump.erg file for full dumps from https://cdn2.hubspot.net/hubfs/416323/QuickAnswers/EnableFullDump.reg?t= 6308120 or the EnableMiniDump.erg file from https://cdn2.hubspot.net/hubfs/416323/QuickAnswers/EnableMiniDump.reg?t= 26308120
2. Double-click the file and click Yes. Administrator rights are needed to access the registry settings
3. The dumps folder is %TEMP% whose complete path is like C:\users2;username\AppData\Local\TEMP
4. When the application crashes, you will find the .dmp file in the TEMP folder. For example, if UiExplorer crashes then a file such as UiExplorer.exe.7429.dmp will be found in the TEMP folder

Collecting crash dumps

Disabling crash dumps:

To disable crash dumps, perform the following steps:

1. Download the DiasableDump.reg file from https://cdn2.hubspot.net/hubfs/416323/QuickAnswers/EnableFullDump.reg?t= 120
2. Double-click the file and click Yes to disable crash dumps, Administration rights are needed for this action.

Error reporting:

A user may encounter an error in UiPath and want to report it.

Enterprise Edition customers

If you are an Enterprise customer, then you can report the error to the UiPath community in a very simple way:

1. Just go to this link: https://www.UiPath.com/contact-technical-and-activations.
2. You will be re-directed to a page where you have to fill out a simple form containing some basic details and then upload the file in which the error is encountered, as shown in the following screenshot.
3. After uploading, just click on the Submit button. UiPath will respond to you with the proper solution: