In the UiPath automation Debugging is the process of identifying and removing errors in the application. It is done to make sure the applications are error-free. Breakpoints are used to pause the project execution to check the state at a given point.
Debugging of a single file or whole project can be performed by using a debug option.
The Debug ribbon tool contains the following wizards
Debugging of a single file or whole project can be performed by using a debug option. However, the debugging process is not available if project files have validation errors.
The Step Into is used for debugging one activity at a time. When this action is triggered, the debugger opens and highlights the activity before it is executed. The Step Into will execute all the activities present in an activity(Container).
When Step Into is used with Invoke Workflow File activities, the workflow is opened in a new tab in read-only mode, and each activity is executed one by one. The keyboard shortcut for Step Into is
Unlike the Step Into action, The Step-Over does not open the current container. When Step Over is used, the action debugs the next activity, highlighting containers such as flowcharts, sequences, or Invoke Workflow File activities without opening them.
This action comes in handy for skipping analysis of large containers, which are unlikely to trigger any issues during execution. Step Over is available using the
As the name suggests, The Step Out is used for stepping out and pausing the execution at the level of the current container. Step Out completes the execution of activities in the current container, before pausing the debugging.
This option works well with nested sequences. Step Out is available using the
Shift + F11keyboard shortcut.
Retry re-executes the previous activity, and throws the exception if it's re-encountered. The activity which threw the exception is highlighted, and details about the error are shown in the Locals and Call Stack panels.
The Ignore action can be used to ignore an encountered exception and continue the execution from the next activity so that the rest of the workflow can be debugged.
This action is useful when jumping over the activity that threw the exception and continuing debugging the remaining part of the project.
Restart is available after an exception was thrown, and the debug process is paused. The action is used for restarting the debugging process from the first activity of the project. Use Slow Step to slow down the debugging speed and properly inspect activities as they are executed.
Please note that when using this option after using the Run from this Activity action, the debugging is restarted from the previously indicated activity.
Focus Execution Point helps you return to the current breakpoint or the activity that caused an error during debugging. The Focus button is used after navigating through the process, as an easy way to return to the activity that caused the error and resume the debugging process.
Alternatively, when debugging is paused because a breakpoint was reached, Focus can be used for returning to said breakpoint, after navigating through activities contained in the automation process.
A third case is when the debugging is paused either after using Step Into or Step Over and then navigating through the process. In this case, Focus returns to the activity that paused the debugging process.
The breakpoints allow you to pause the debugging process at any given moment. The activity which is being debugged remains highlighted when paused. Once this happens, you can choose to Continue, Step Into, Step Over, or Stop the debugging process.
It is recommended to use Breakpoints along with Slow Step so that you know exactly when debugging needs to be paused.
An alternative to using Slow Step in this situation is to keep an eye on the Output panel and use Break on the activity that is currently being debugged.
Slow Step helps you to take a closer look at any activity during debugging. While this action is enabled, activities are highlighted in the debugging process. Where the containers such as flowcharts, sequences, or Invoke Workflow File activities are opened.
This is similar to Step Into, but without having to pause the debugging process. Slow Step can be activated both before or during the debugging process. Activating the action does not pause debugging.
Although called Slow Step, the action comes with four different speeds. The selected speed step runs the debugging process slower than the previous one. For example, debugging with Slow Step at 1x runs it the slowest and fastest at 4x. In other words, the speed dictates how fast the debugger jumps from one activity to the next.
Each time you click Slow Step, the speed changes by one step. You can easily do it by clicking on the icon, which updates accordingly.
If the Highlight elements are enabled, then the UI elements are highlighted during debugging. The option can be used both with regular and step-by-step debugging.
If the Log activities are enabled, debugged events are displayed as Trace logs in the Output panel. Note that Highlight Elements and Log Activities options can only be toggled before debugging, and you can access when reopening the automation project.
This is not applicable for invoked workflows unless these files are opened in the Designer panel. Logs are automatically sent to Orchestrator if connected. Still, you can have them stored locally by disabling the Allow Development Logging option from the Settings tab in the Add or Edit Robot window. Disabling Log Activities can be a way to send smaller log files to Orchestrator.
Clicking Open Logs brings up the %localappdata%UiPathLogs folder where logs are locally stored. The naming format of log files is YYYY-DD-MM_Component.log (such as 2018-09-12_Execution.log, or 2018-09-12_Studio.log).
Once you click on Log activities, you can see the log files as shown below
Create a new Project called UiPath_Features_Example
Once the Process Opened in the UiPAth Studio, add Sequence and then add Assign Activity inside the sequence. In this example, we are going to write a program that is going to print numbers from 1 to 100.
Create a variable called
Count inside the Assign activity and assign it to
1 as shown below.
Next, add While activity inside the sequence and write the expression(
Count<=100) for the same. And then add Write Line Activity inside the body of the While condition and enter the variable name inside the Write Line Activity.
To increment the value of the variable count, add assign activity inside the sequence and the increment Count value by 1(
Now, the while loop executes till the condition becomes false and prints the numbers from 1 to 100 in the output console.
Now let us see how the debug works in this program:
In the ribbon tab, you will find a tab called Debug tab, which is having options called Step Into, Step Over, and Step Out. And also, we can find options called Breakpoints and Slowstep options.
Place the cursor on the Write Line activity and right-click on it, you will find an option in the drop-down list as Toggle Breakpoint. By selecting the Toggle Breakpoint option, we can add the breakpoint at Write Line.
After adding Toggle Breakpoint at the Write Line activity. Clicking on the Debug option will take you to the debug mode and stops at the point where the breakpoint has applied.
In the below image, you can see that the program execution has stopped at the Write Line Activity, where the BreakPoint has applied.
On the Leftside, you will see some of the pane's called Output, Locals, Projects, Activities pane if you click on the Locals, you can see the variable , and if you click on the output, you will find which activity has executed.
Now, Click on the Step Over, it will execute the program step by step. Now, if you observe the count become 2.
And on the right side, if you click on the Outline, it will show you what has been executed step by step.
This is how the debug helps to execute the program step by step. Clicking on continue will execute the again, jumping to the breakpoint only.