Welcome.
Today we’ll look at one of the fundamental elements of automation, and programming in
general: Debugging and Exception handling.
You’ll learn how to identify bugs and other misbehaviours in your automation, and the
steps you need to take in order to resolve them.
UIPath has a few tools that will be familiar to those of you with some coding experience
– things like execution logs, break points, and try/catch blocks – and a few special
interaction ones, like element and activity highlights.
But before we jump right in, one quick but important note: an often ignored aspect of
debugging automation projects is Naming The Actions and Flowcharts in your workflow.
We mentioned it in previous training videos, but today you'll see its importance, beyond
just having an easy-to-read workflow.
And that is because in the process of tracking down & solving different issues, UIPath will
show you where an error occurred, by name.
As you can see, while both error messages show the problem, the one on the right gives
you a much better idea of {where the failure happened}, which in turn helps you understand,
pinpoint and solve the problem faster.
So it’s a very good habit to have that will pay dividends later, when your workflows & debugging
jobs get increasingly complex.
Right, with that noted, let’s move on to our main focus, debugging.
For exemplification purposes we have here a straightforward workflow that enters some
data into this sample app right after clearing all the fields.
The debugging tools are here in the Execute tab, and we'll kick off the debugging process
by pressing the StartDebug button. There are a few things going on at the same
time so, breath in, and let’s take a closer look.
The most obvious one is the yellow highlight.
It shows which action is currently being executed.
It provides a visual feedback that is especially helpful in solving input & output issues,
specific to automation.
These yellow activity highlights work even better in conjunction with the red element
highlight, which can be activated in the options here.
The red highlight indicates the effect of
the current action on other applications’ elements.
Obviously, it only works for input or output activities because other actions have no effect
outside of UIPath.
Next, one of my favorite tools, the properties inspector.
Besides various relevant properties for the
active action, more importantly, it shows the current values of all variables
declared in the current scope.
In our case, these two dummy variables.
This feature will be very useful for solving more delicate, programming-logic issues.
And the third thing that is going on (along with the others) is the detailed log of
all the actions that took place in the workflow.
It provides an informative context for your WriteLines and Log Messages, like this one.
Most of the time, this debugging log, along with various WriteLine or Log Messages, should
be your first line of defense in trying to resolve unwanted behaviours.
If at any time you feel all this goes a bit too fast, you can slow it down with this handy
Slow Step option, that can be activated & deactivated even while the workflow is running.
This way you can examine the workflow better: how your application responds to UIPath commands,
how variables update, and so on.
But most of the time you will be interested in a particular part of your workflow.
The technique for those situations is to add breakpoints, using this toggle breakpoint
button here.
It marks a specific point in your workflow where the execution will pause.
Once stopped, you can check the state of your application, the current value of variables,
printed messages, and whatever else you might need.
Then, when you're done, you have a few options for how to continue:
you can choose to resume at normal speed by pressing continueDebug, or take a step-by-step
approach, by pressing the StepOver button.
And of course resume whenever you want.
Right, so these are the debugging tools UiPath puts at your disposal, so make sure you try
them out the next time your workflow is not behaving as it should.
Since software automation involves interacting with other applications, besides the debugging
tools we just mentioned, I’d like to show you a few techniques for how to actively solve
the most common interaction challenges.
The first issue you might encounter is when the element you are trying to interact with
cannot be found, or is wrongly identified.
Either UiPath cannot click on it, or cannot get its value, or not doing it correctly.
In order to make our workflow fail, we intentionally covered it up with a mediaplayer window
that is set to be always-on-top.
The other actions are unaffected by the obstruction, but the {Clear-Fields menu item} cannot be
clicked on the {FileMenu} that is opened, so it fails.
For these types of errors, there are 2 things you should try:
First, make sure the window you are trying to interact with is visible.
UIPath can interact with apps even when they are in background, but that is explained better
in the next step.
So we'll just move this window out of the way.
This solves our problem, but for situations where you don't have that option, u can change
the input method for the offending action down here, in the Action properties.
You can even box-select multiple actions to modify their parameters at the same time.
As you might remember from the Input Methods training video, the default method – active
when both SendWindowsMessages and Simulate are unchecked – uses the hardware mouse&keyboard
drivers to imitate a human using them.
That means this method should work every time IF the application is in foreground.
Basically, if a human can perform the action, the default method should work.
But make sure you also try the other methods because they work in background and that might
be a viable solution.
Like our example here that works if we switch
to SimulateClick, and manages to clear all fields even when hidden behind another app.
If after these 2 steps your automation still doesn't work, the next thing you should take
a look at is the selector for that action.
There is a whole in-depth episode dedicated to selectors, so make sure to watch that if
you are having issues with them.
Two possible quick fixes are Indicate On Screen – to “refresh” the selector.... and
Attach to live element, here in the expanded SelectorEditor window.
It solves a set of issues with selectors that are too specific, or that slightly change
over time.
It works by finding common properties between the two instances of the same element.
So these few simple steps should be enough most of the time to ensure your automation
runs smoothly: • make sure the application you're trying
to automate is visible; • change the input methods; starting with the
default; • then check the selector to make sure it
is correct.
You may find that your workflow works most of the time, but sometimes fails.
That could be a different type of problem.
It’s probably a timing issue, like some elements that are not yet loaded when UIPath
tries to interact with them.
Could be on web-pages or desktop applications.
The approach and solutions for these kinds of problems are very similar to the ones discussed
in a previous video – Advanced Image-based Automation.
So have a look at that episode if you’d like a more detailed description of the technique.
We’ll use the same example now too, but not in a virtual machine: the login on the
SAP homepage.
When this little icon is clicked, the login window pops up, but with a slight delay; not
not sure if intentional or not, but doesn’t matter.
And here is a very basic workflow that automates that: clicks the login button and types the
email and password.
Now, this runs flawlessly because UiPath actually waits for the element to appear.
As you should know, all click & type actions have this timeout property which specifies
how long to wait for the element to appear, before giving up and throwing an error.
And the default, while not shown here, is 30 seconds.
We’ll go ahead & change that to 0, essentially
disabling the waiting period for this Type activity.
It's an artificial way of producing an error so I can show you how to solve timing issues
in an uncomplicated environment.
So now if we run, the type activity will give up looking for the text-field before the popup
actually opens, and will fail.
Good, now how do we fix it?
Well, these are the 3 main tools you can use.
And keep in mind that these have 3 identical counterparts for image-based automation.
ElementExists is a bit different from the
other 2, in that it doesn't affect the running of the workflow in any way.
It just returns a true or false value, depending on the existence of a specific element.
It can be anything: a window, a button, a popup message, or any other component of an
application.
ElementExists will tell you if that element is on the screen or not.
So if (we come back to our workflow and) we insert Element Exists activity right after
the click, to check for the email field, it should return a false value.
We just need to create an output variable to see the result.
But it will actually try to find the element, for 3 seconds to be exact, it’s default
timeout.
And in our case it will succeed, because the popup opens a bit faster than that.
But if we shorten its timeout to, let’s say, 10 milliseconds, it will return false
because the element doesn’t exist yet.
It will also fail because, as you can see
in the output pane, the email field does not exist when the Type command is being executed.
If we watch a slow replay, we can even see the error message and UIPath window appear
before the webpage login pop-up.
Now with the ElementExists information, we
could use an If-else decision or DoWhile loop to evaluate if the popup exists, and either
wait for it, or do something else entirely – if it’s never found.
And in general, you can use this method to choose your next actions based on how an application
responds: maybe it will show a certain message, or maybe another, or maybe nothing at all.
Now you can act accordingly.
The other 2 activities differ from ElementExists
in that they stop the running of the workflow until a special condition is met: FindElement
stops the automation until an element is found, and WaitElementVanish - obviously - waits
for an element to disappear before continuing.
So for a different approach to our little
problem let’s reset the workflow to its most basic: a click & 2 type actions.
If we insert a FindElement after the click action, it will hold the running workflow
and wait for the element to appear;
And when it does, it fires off the rest of the workflow.
The default timeout is 30 seconds, after which it will throw an error if nothing is
found.
I'm sure that by now you have a pretty good idea of how WaitElementVanish works too, so
I will let you experiment with it yourself.
In more critical automation projects you will want to be able to detect errors as they happen,
and perform various actions when they occur; sometimes even recover gracefully from specific
failures, instead of crashing and terminating the whole workflow.
A special activity for this purpose is the try/catch.
It is made up of two main blocks – try & catch – and a 3rd optional one, called Finally.
In the Try block you will put the actions that might throw an error, and the Catch block
is for the actions to be executed when an error occurs.
And the third one, Finally, is just for actions to be performed after the try&catch blocks.
You might notice that the catch block Is actually called catches, plural.
That is because multiple catches can be added, to catch different types of errors, or exceptions.
SystemException is the one we’ll use most often because it catches all types of errors.
But if you want to take different measures for specific errors, you can use any additional type.
And to find the specific type of an error, simply look at the Exception Type field
of an error message.
To see how that works in practice let's look at the previous example of logging in to the
SAP homepage.
If some action in our sequence fails, we want to automatically recognise that error and
log a message with the circumstances surrounding that exception.
So let's drag in a try/catch activity.
Now, select all your existing actions and drag them inside the Try block.
Next, add a new catch, and for the exception type choose “system Exception” to catch
all exceptions. (and press enter)
The try block automatically collapsed to make room for the actions in the Catch section.
Here, you can start adding relevant actions to take place when an error in the main workflow occurs.
We can add a message box, to give a warning
of the error, but that also stops the workflow and maybe we don't want that.
the writeLine action prints a message to the output pane without disturbing the running
of the workflow so we could use that.
But a more appropriate solution is the Log command because that has the added advantage
of writing a log file, which is more practical if you are debugging a workflow that ran unattended,
and want to see what happened.
For the Level we’ll choose Warning, and for the message we’ll say... “an error
occurred while logging in”.
For testing purposes we’ll go in the Try section and give the click action a timeout
of half a second, instead of the default 30 seconds.
Now all we have to do is close the browser tab to make it fail and run the workflow.
And pretty quickly it finished with the error message that that we gave it.
In other situations though, continuing the workflow may not be the desirable behaviour,
and after logging the exception you may want to actually display the error message and
stop the execution process entirely.
To do that, simply add a Rethrow action that will pop-up the error.
You might notice that this error message holds a bit more information than our log
in the output pane.
Actually, we do have access to that data.
So let’s delete the Rethrow, since we don't need it anymore, because we’ll write its
contents in the log.
Just add this special keyword at the end of the log string: exceptionMessage.
So now when we run, we have a much more helpful message here in the output, and also in the
log files.
So that is how the try/catch activity works.
Simply place a set of actions in the try block, and if an error takes place, the catch block
gets executed.
Pretty easy.
But the really interesting part comes when you try to diagnose and find possible solutions
for recovering from failures.
Let’s say you analysed the logs and determined
the issue is the browser application itself: it randomly crashes from time to time, taking
down your automation workflow with it.
One of the nastiest problems to come across.
Well, the easy fix for that is simply starting the browser again, going to the correct address,
and resuming the workflow.
So Let's copy the log activity, and delete this whole Catch sequence.
Then add an Open Browser action, that will serve as a recovery for the one that crashed.
And paste the Log command back in, since it’s always a good idea to log what is happening.
Then, go to the Try block and select all the actions in it, copy them by pressing control-C,
then simply go to the Catch section and paste them in the openBrowser activity.
All that’s left is the URL to go to, and we’re done.
Now this whole sequence is executed when an error appears in the main Try block
first a new browser is opened then a message is logged , and
finally the login sequence is performed.
Oh, this failed because we copied the click action with the intentionally short timeout,
and it takes a few seconds for the new browser to open and load the webpage.
We’ll just delete it.
And while we’re here, let's update the Log message to reflect what is going on.
Let’s see if that worked.
Great.
You could actually go and make it even more robust by checking if the login was successful
and decide what to do next, and so on and so forth, but I will leave you to experiment
with that on your own.
Because I want to show you a nice trick that we’ll cover more in-depth in the next video:
the Invoke command.
It's very useful in keeping the, let’s say, “master” workflow cleaner, by running
smaller independent workflows.
Going back to the Try block, right-click the SapLogin sequence, and choose Extract as Workflow,
and give it a name.
The whole section was replaced with a call to an external workflow, SapLogin, located
in the current project folder.
In the Main workflow, this single Invoke block now contains the same functionality as the
sequence it replaced; so we can reuse it in the Catch section too.
As you can see this makes for a much tidier workspace, while being equally effective.
And it works too!
This brings us to the end of today’s video.
It was pretty dense, but featured techniques that should prove valuable in everyday automation
projects, as well as in more advanced, unattended automations.
You're getting close to becoming a pro!
I’ll see you for the next video, Project Organisation.
Good bye!