When developing complex workflows, finding mistakes is pretty difficult.
UiPath Studio comes with a debug component that helps you find problems more easily.
This is useful for viewing the execution of each activity to verify what data it gets
and in checking if there are errors in producing outputs.
UiPath has a real-time engine that checks for errors while you are working with your
workflow.
Whenever an activity has errors, UiPath Workflow Designer notifies you and gives you details
about the issue encountered.
Also, it will not allow you to run the workflow if you have an existing notification error.
In our sample workflow, We have this red dot with exclamation point.
This lets you know that somewhere in the workflow an activity has an error.
Hovering over it will provide you a message about the error.
In this case, it gives an error, "One or more children have validation errors or warning".
This means that one of the activities inside this container generates the error.
To quickly find the source activity you can go to the Outline panel and click the red
dot.
This will show the activities with errors or warnings.
So the activity that generates the error is the message box activity, which is highlighted
in a red box.
There are two possible reasons why we could get this error.
First, the variable used isn't declared or not present in the variables panel.
Second, if it is declared, it is not available in this sequence.
Meaning, the activity doesn't have access to the scope of the variable.
Let's double click the message box to open it.
First lets check if the variable is declared.
Let's go to the variables panel.
As can you see the variable result1 is not declared.
We have the variable "result", but what we've used is result1.
This is why the activity is giving an error.
Next thing we need to check is the Scope of the variable.
In this case it was set to Main so that means we can use this variable anywhere in our workflow.
Let's correct the error and change it into a proper name.
As you can see the notification error disappeared.
Next, lets debug our workflow.
When running our workflow in debug mode, we have 3 execution speeds : slow, normal and
fast.
These specifies how fast you want each activity to be executed.
Lets select Slow.
We can also run the workflow step by step using the "Next" button.
This allows us to carefully inspect each activity during the execution.
It runs from the outside container into more specific ones, from top to bottom.
Lets click it to see how it works.
There.
It started from the Main, to the Recorded Sequence and went to each of the activity
starting from the top.
Let's stop for now.
You can stop debugging anytime using the stop button.
and it gives you this message box.
That's OK.
Next, you can pause the workflow’s execution while debugging by setting up breakpoints.
We'll just need to click the activity where we wanted to stop and Press the "Toggle Breakpoint"
button.
You can also press Ctrl+F9 as shortcut.
[Video: set breakpoint at Edit menu]
During debugging, you can check the real-time logging of the activities in the Output Panel.
Lets put this back to normal.
Lets start Debugging by clicking "Start Debug" and see how it works.
Execution stops each time it encounters a breakpoint..
This is very useful when you've created a complex or long workflow.
So instead of running the entire workflow, you can set a breakpoint to where you wanted
it to stop.
We can continue the debug by pressing the Continue button or by pressing F6.
Debugging is handy when you receive runtime errors.
These are errors that don’t appear during workflow design, they appear when you are
executing the workflow.
If you have a big workflow, debugging is the quickest way of finding the activity that
generates the error.
Lets find "close application" and drag it here all the way at the bottom.
Then lets specify the application we wanted to close.
That will be our calculator app.
This should work.
Lets remove the breakpoints and run the debug and see what happens.
So yes it works.
Let's go back to the "Close Application" activity.
This activity will execute successfully only if the selector will successfully identify
the Calculator app.
Now, let's move it inside the "Attach Window" container.
Let me go back to the Output panel and lets debug once again.
Now the workflow gives the following error message.
We don't have the notification error in our workflow designer, but an error still exists
and is shown only after running the workflow.
So the best thing we can do is to find out what is this error about.
Lets close this error message and the calculator, then let's go to the output panel.
In our Output Panel, we got an error after executing the "Close Application" activity.
And we got the "Invalid UI node."
That means our activity cannot correctly identify the Calculator application while placed inside
the container and having the current selector.
Here's the reason why.
When we place something inside a container, UiPath tries to identify first the container
and then the element or activity inside it.
But when we clicked copy the menu window has vanished.
UiPath tries to find it first and only then it moves to what is placed in the container
So how do we fix it?
We need to move this sequence from a container that doesn't exist anymore.
Lets also move the message box here.
So it closes the calculator app first and afterwards displays the message.
[Video: move the Close application out, move the messagebox after it]
OK.
lets debug again.
Cool.
So there.
Our workflow is running correctly and in our Output panel, all activities have been executed
successfully.
Now that you know the basics of debugging your workflow, in the next video, we will
learn how to run specific automation based on user inputs.
Stay tuned.