Some Automation Anywhere dos, don'ts and bewares
RPA is an emerging technology and Automation Anywhere is a market-leading vendor with products that continue to improve... so we all need help with tips and tricks.
I lead one of Extra Technology's RPA teams, working with global customers and gaining new Automation Anywhere experience on a daily basis. I certainly appreciate any chance to learn new things and to share my experiences.
Here are some dos, don'ts and bewares that I would like to share to start the ball rolling (this advice may change as the product changes, my experience grows, and subject to the tips of my fellow forum members):
Excel Macros – when they fail with a debug message they block the automation with no way to capture the error and get past it!
Wait Loops for Object Cloning – it is a total waste of time, I see it time and time again (and they still do it at many Automation Anywhere customer sites!), a single object cloning timeout set to a high enough value is as effective as having a loop of short timeouts and is less misleading.
Screen Recording - MetaBot screen recording at higher screen resolutions than the production system.
Use differing variables between tasks – specifically this relates to calling a task from another task and mapping a variable or variables, the “Quick Map” feature will not work if the variables do not match exactly.
Use Excel where CSV or XML will do – especially true for config files, reading a CSV or XML file requires less resources and does not need to open an application.
“Wait for Window” command – but please keep in mind that it will only wait for the window title to exist, not for the window to load, always follow it up with an object cloning or similar method which waits to find an element on the page which proves it has loaded. This is relevant to many applications, not just web sites.
Use short-cut keystrokes – this is much preferred and much more reliable than searching for a button to click on. Beware though, some applications do not use standard shortcut keystrokes and some even change dynamically depending on content (e.g. Microsoft Dynamics). Always test in every scenario possible.
Copy & Paste - Copy and paste lines and even entire sections between task scripts (it does work flawlessly, although I have heard rumours to the contrary).
Local database Consider using a local MS Access database for storing information regarding the status of a process and other info – this is much faster than more convenient than using Excel files, despite the inconvenience of setting up the table format initially.
Export form tables to CSV files – very fast and easy to access afterwards.
Use Error Handling extensively – This is a huge subject all on it’s own and detailed education is highly recommended (Extra Technology runs various AA education courses if you are interested http://www.extratechnology.com/services/training/automation-anywhere-courses - Remote training is an option. More courses are planned). Wherever you can get training, it is essential to understand how to make your RPA delivery robust - a failing robot is a very poor advertisement for RPA and should not be tolerated.
Mapping variables between tasks – Running a task (e.g. sub task) from another task (e.g. main task) and mapping the variables means the variables are always bi-directional, it is not possible to select a one-way direction and so not possible to avoid a modified variable coming back to the calling task (main task) from the called task (sub task). This is where “Quick Map” can catch you out, despite it’s apparent ease of convenience.
The system variable “AATaskName” does NOT return the task name alone!_ - AATaskName returns the complete path to the task which then needs further processing to cut it down to just the task name. It would be so much more convenient if there was a system variable which returned only the current task name in short form.
Avoid the system variable “Date” where possible – instead use “Day” “Month” “Year” etc. – This is because the returned format is inconsistent depending on the environment settings.
Consider sub-task failure detection/feedback Called tasks (sub tasks) do NOT pass back their failure state to the calling task (main task) so it is impossible to detect a failure without adding Error Handling in the called task and somehow feeding it back to the calling task via a mapped variable.