Those new to Automation Anywhere aren’t sure how or where to start, which is why I penned this article right here. Now, why would I divert you to another article instead of diving into the topic at hand? That’s easy to explain.

The processes you develop won’t be perfect, because nobody’s perfect.

Unfortunately you can’t use that platitude to explain away bot failures, because your clients aren’t paying good money to hear you gloss over your incompetence critical issues. They are paying good money for robust automations that will not only operate efficiently but also handle exceptions just as efficiently.

This is why it’s important to test and debug processes before deploying them into production, but you won’t understand why there is a need to debug processes unless you first develop processes. There isn’t much to learn here, and I am only stretching it out into a 800-ish article for dem SEO brownie points. Don’t worry, I will keep you engaged throughout with flashy posters.

What is Debugging?

Debugging is what we do with processes which have either been developed or are in the process of being developed. It’s used to test out various scenarios, and pinpoint potential roadblocks.

In short, it helps you deal with errors or what may appear to be potential error.

Potential Errors?

Yup, potential errors are the roaches that hide in the basement. You are never really sure how many of them are there, but you know they are in there somewhere…

And the Debug tool is what is going to help you find them.

Ok, So the Debug Won’t “Debug”?

Nope.

Debug operates like a flashlight, which will shine those nasty roaches out. You have to take care of the rest, using whatever means necessary (as long as its legal…or you can point your finger at the intern).

You can either redesign that particular segment, or develop and inject another bit of logic which will take care of the problem. It all depends on how creative you are willing to get, and also on the timeline allocated to you.

So I Press Debug and Search for Errors, Got It.

Nope, that is step number one.

Step number two is adding Breakpoints at suitable locations.

You know for a fact that the entire house is not infested. Its only select few points around the house where the roaches tend to appear more often, that you ought to target. Those are the areas you have to station Breakpoints.

Why Should I add Breakpoints?

Breakpoints are the batteries to your Debugging flashlight. Not a good analogy, but you get the point.

No I Don’t.

Breakpoints are the points at which your Debug tool decides to take a break. The execution is paused at breakpoints, which is when you can have a closer look at the variables and see what values are present inside of them, right before the roaches come out.

In short, Debugging won’t work without Breakpoints.

What if I Run the Process in Debug “Without” Breakpoints?

Your process will run normally, before crash landing into roach territory.

Debug doesn’t know where to stop – it requires your input.

Alright Then, Can’t I Add Breakpoints and Run it Normally Instead?

Merely stopping the process at points you think are problematic won’t cut it. Errors are a result of faulty logic, but where does that faulty logic reside?

Let me put it this way, what exactly holds that logic in place before it comes crashing down?

Variables.

To study the logic, you have to study the variables, since the logic is stitched into them. This is why Breakpoints are ignored in normal process run.

The Debug platform has a Watch Panel where you can keep track of variables, and the values it assumes as it journeys from birth to death.

Ok, I Kinda Got It.

Good!

Now let’s debug a simple process on Automation 360, just to get a feel for it. We will try adding numbers together, and try to fault it by introducing a string into the loop.

First, create a new Taskbot.

Next, Create two variable – one will be a List and the other will be a Number variable to hold the sum.

Now, drag in a Loop and toggle it to For each item in List.

Create another variable by clicking on the create icon in the Loop Action.

Then drag in a Number: Assign Action. This will add up our numbers and store it into $nSum$.

In case you were wondering, the dollar signs are what tell Automation Anywhere that you are trying to reference variables. What if we ran the process right now?

Is Automation Anywhere smart enough to tell the difference between numbers and strings? Lets find out.

Seems like the bot isn’t smart enough to tell us what the error is either.

Doesn’t matter, since we have come prepared! Lets turn on the flashlight.To do so, press the Debug button as shown in the screenshot below.

Now, lets station our breakpoint.

Which would be an appropriate location? Well, there are only two Action here, so it doesn’t really matter. Sometimes you have to give some thought to that as well, especially when you are debugging large processes with multiple variables.

Lets run it with Debug!

As you can see, right off the bat Automation Anywhere allows us to view variables in the window panel, as well as the values they currently hold.

This is what makes Debugging useful. It allows us to peer into the logic our bot is operating on, which provides insight into potential pitfalls.

If you are still unable to detect errors, that means you haven’t added breakpoints in appropriate locations. Ideally, you ought to place them before the error prone line i.e., if the bot fails at line 10, station 2-3 breakpoints about lines 6-9, and pay attention to the values present in variables.

Of course, there are times when errors are a result of the applications you are trying to automate, such as access issues, or incorrect parameters details, but you have to be certain that they are issues related to the application, and not due to faulty logic, because then you have to relay that information to the end user.

If nothing else works, you can always point your finger at the intern.

And With That, Our Errors Are Handled!

Not exactly.

Handling errors is different from detecting them. Errors aren’t handled with Debug.

That is taken care of by the Try-Catch Action Package. Yes, I’ve written about that as well, and you can check it out here!

I hope this example has shown you the benefit of using Debug. I’ll try to come up with a complicated example for you to work with so until next time.