Welcome to The Coding Theory’s first article on Automation Anywhere!
I have written several drafts based on the solutions I have provided on the AA Forum, which no one seems to give a hoot about.
It didn’t gain as much traction as I thought it would, so I brought it up here, onto my blog which no one seems to give a hoot about either.
In the world of programming, you have to define everything.
What Do You Mean By “Everything”?
The confusion you are facing right now is the sort of confusion our machines face when we assume it understands what it should do, just because it seems obvious to us.
Machines are logical, in fact too logical. It lacks any sort of reference or intelligence with which it can operate on, hence relying entirely upon the logical networks you have programmed it with.
Simply put, they lack awareness.
English Please Señor.
Alright, I’ll give you an example.
If you program your bot to open a file that is already open, it will fail to execute that line of Action.
It will come running back to you and whine about the file being open.
You might respond, “So what if the file is open? Doesn’t that make your work easier?” To which the bot will respond, “But you wanted me to open the file, and it’s already open. My life has no meaning anymore…I can’t continue living like this…I have decided to terminate myself. Goodbye.”
So The Bots Are Dumb?
No, not dumb, they are logical.
If you command the bot to open a file, or create a folder, it will operate accordingly without asking questions because it has no intelligence.
If what you are trying to achieve through the bot has already been achieved, like the file being open, or the folder already present in a given directory, our bot will not automatically skip over to the next step because it isn’t smart enough to realize,
“Oh! The file is open, now I can move onto the next step and automate the rest of the process!”
It instead, throws a hissy fit before crashing back to sleep.
So The Bots ARE Dumb.
I guess they are, but that is a very crude way of putting it.
Software have their limitations, which is why developers have worked diligently to develop a framework which provides them with some much needed support – a crutch, of a sort.
That framework is called the Try-Catch-Finally Block.
To handle situation where our Automation Anywhere Bots run into errors, we use something called a Try-Catch-Finally Action.
Back in the good old V10 and V11 days, Automation Anywhere termed their automations as “Commands” before switched it to “Actions”. That was a smart move, since Actions speak louder than Words.
Now that I’ve caught you off guard, lets get back to our Try-Catch story.
We first “Try” the problem prone set of actions, then “Catch” the error if our bot runs into any, and “Finally” plug in a set of actions that always have to be performed, regardless of the outcome of the actions preceding it.
As an added bonus, Try-Catch Blocks prevent our automation from automating things it isn’t supposed to, and logs the resulting errors for us developers to crack our heads wide open over.
Say you program a bot to create a Folder that already exists, but this time you have wrapped it up inside of a Try Block.
The resulting error gets “Handled”.
Whenever your automation runs into an error, the automation will either halt or it will trigger another process to notify developers about the error(s). Few error handling strategies include logging details to notepad, taking screenshots, drafting a mail with the necessary attachments which is then sent across to whomsoever is concerned, so that “Mr.whomsoever” may dig their nails into our skulls for developing a sloppy automation.
All in all, the software doesn’t crash, while safeguarding sensitive information undergoing automation. It isn’t left wide open for the world to peer into and snatch whatever they want from it.
This is why I say the errors are “Handled”, because the program doesn’t terminate abruptly, leaving the crime scene without a trace.
Try-Catch behaves much like a detective who is busy monitoring and collecting evidence which helps us pinpoint issues and develop suitable resolutions.
What About Finally?
Finally houses a block of code that is always executed.
Say you’re automating Google Chrome to retrieve the latest stock prices, and the network goes down, causing the website to go down along with it.
The Finally block will contain actions such as the Window: Close Action to close our Google Chrome browser once it is done reporting the issue back to the concerned users in the Catch Block.
It wouldn’t make sense to keep the browser up and running either if the automation fails or succeeds, which is why we place it inside the Finally Action.
Try, Until You Succeed
I mentioned earlier about our bot automating things it ought not to.
Here is one such example.
Say your automation involves a lot of Simulate Keystroke Actions. If the window that our precious keystrokes ought to be sent into is stuck hovering about in the background, the keystrokes will be sent elsewhere, triggering things it shouldn’t.
Instead of pulling out the report you were looking for, it will pull out the photos you weren’t looking for, and send it across to end users, who will use it to end your career.
Can the Try-Catch Fix this? Nope.
Refining the Window Variable helps.
The Simulate Keystrokes Action requires you to specify a Window Variable that the keystrokes ought to be sent into.
If you simply clear everything out and replace it with a wildcard, hoping that will make your Window Title much more “Dynamic”, the Keystrokes will be sent to God only knows where.
Dynamic is fine, but only Dynamic is not. It has to zero into the right window.
But not everything can be resolved with refining Window Titles. What if the Application being automated crashes during execution?
When that happens, you have –
A Lot of Catching Up To Do
The error prone actions are put into the Try Action, which then transfers the flow over to the Catch Action, where the error details are recorded.
You can either draft a mail containing the error details, or you could include the image generated from Screen: Capture Window Action set to “Currently Active”.
Under error details, you have the Error Description, as well as the Error Line Number, both of which come in handy when debugging automations. The Catch Action automatically records them for us. Pretty neat, ain’t it?
While developing, I add the $sErrorMessage$ and $nErrorLineNumber$ into a Message Box and pray to God that I never see it pop up. But for the actual process, we have to log it to a file so that the business users can keep track of what’s going on.
I forgot to mention something, when using the Try Action, it is required to add a Catch Action as well.
When you drag it into the development platform, both come together, and its better to keep it together.
There is no point in Handling errors, without knowing what those errors are. They whole point of handling errors is so that we can piece them apart and formulate a resolution, which is what the Catch Action does for us.
You’ve Finally Made It!
We’ve looked at this before.
I rarely use it, because the exception has already been handled in Try-Catch Action.
Also, it isn’t compulsory to include the Finally Action. The program works just fine with or without it.
Actions that end up in the Finally Action are usually codes that close applications, or sends mails regardless of the automation’s status (success or failure).
You can get creative and use it however you wish to. Surprise me with something unique.
I think by now you might have an idea of how the Try-Catch Block works.
I’m proud of you.
Now go and practice what you’ve learnt so far or you will forget and run into countless errors that could have easily been prevented had you learned to use Try-Catch Action.
You’re still here?