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):

DON’T:

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.

DO:

“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.

BEWARE:

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.

Comments

  • Any functionality in "automation anywhere" like "Work-Queue " in "Blue-Prism"?

  • Hello, Work Queues will be available in the 11.x release which is schedule for this year.

  • Regarding the 1st Don't, Excel macro, I have some concern.
    Actually in most of our automation projects, more or less we are using the macro.
    the main reason is we have very complex excel requirement, and AA only provide the limited excel command.
    even we can use the IR, keystoke to complete the automation but it will cost huge effort to do the AA coding and test, compare to use the VBA (macro)
    so for this case, do you think Macro is not a better option?
    Similar if we have some other requirement and AA don't have the command, then we cannot use any 3rd party components becuase it's hard to capture the error?
    BTW, when we are writing the macro, we have the execption handling mechanism and till now we didn't find any issue in all our AA automations with Macro...
    Pls share your thoughts...

  • @zhenxiang said:
    Regarding the 1st Don't, Excel macro, I have some concern.
    Actually in most of our automation projects, more or less we are using the macro.
    the main reason is we have very complex excel requirement, and AA only provide the limited excel command.
    even we can use the IR, keystoke to complete the automation but it will cost huge effort to do the AA coding and test, compare to use the VBA (macro)
    so for this case, do you think Macro is not a better option?
    Similar if we have some other requirement and AA don't have the command, then we cannot use any 3rd party components becuase it's hard to capture the error?
    BTW, when we are writing the macro, we have the execption handling mechanism and till now we didn't find any issue in all our AA automations with Macro...
    Pls share your thoughts...

    Your points are valid zhenxiang. In principle there is no problem with robust code that is correctly documented. In my experience, calling external macros or programs can present a number of issues as well. In the case of an AA Robot, calling an external piece of code, such as a Macro, makes the Robot harder to support, because it is no longer apparent what the Robot is actually doing at that point. Supporting and maintaining external code also presents further challenges and requires additional skills.

  • Hi,

    About "Use Error Handling extensively", would you recommend using it from start to end and just stop the task logging the error message in a log file? or in what specific cases would error handling be more useful/recommended?

    Kg,
    Angello

  • 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.

    @adrian.woffenden, Couple of questions regarding this point.

    Shall we use XML instead of MS Access ?
    Retrieving from MS Access is faster than XML ?

Sign In or Register to comment.