Best Practices for Bot Building
Document your bot
When building bots, use Comments and/or Steps. This isn’t just for others reading your bot, it’s for the
future-you when you look at your bot in the future.
Keep your Step names short but descriptive so that the text is fully visible. Keep your Comments
descriptive, but don’t write too much in one Comment. Add a second Comment to break thoughts up as
you would do with paragraphs when writing.
Make your bot readable
Every year, there are contests for programmers to write the least-readable code. Don’t do this with your
bots. The Automation Anywhere software is user-friendly, but some programming techniques can
render your bot very difficult to read.
Type casting
Using “type casting” or “variable casting” can make your bot difficult to read. What type casting does is
to temporarily make the bot see a variable as a different type. A number variable could be type casted
as a string variable to be used somewhere where only strings are accepted.
If you are trying to take a value read from an Excel file and add 5 to it, it’s best to use separate actions to
(1) convert the string to a number, (2) perform the math, then (3) convert the number back to a string.
Can this be done in a single action? Yes. Is it easily readable? No; it is not best practice.
Casting of variables must never be used with floating point values. The values are truncated to zero
decimal points.
Use the correct actions for the situation
Automation Anywhere’s software is very flexible and makes it possible to write bots in a near-infinite
number of ways. For example, when retrieving XML from a web service, it is possible (for a REST web
service using the GET method) to use the Browser: Download file action. This creates a file with the XML
message contained within. However, this is not best practice. It creates a file which needs to be cleaned
up at the end of the bot run. Instead, use the REST web service actions.
Don’t use counters when Loops will do
The Loop and If actions are very flexible. We can use both in several ways. If you have several items to
loop through, it might be tempting to use Loop to repeat an action the specific number of times for each
item, using a counter to keep track of which item you’re working with. It might be a better idea to
specify which items you’re Looping through and let Loop do the heavy lifting for you.
Use variables for filenames and paths
While this isn’t always necessary, using variables for this purpose helps make easier-to-read bots.
Additionally, it is best practice to use a String: Assign to set the values rather than setting the values as
defaults in the variables themselves. While this isn’t always the case, using this for filenames and paths
makes for bots that are easier to manage.
Use variables names that make sense
One naming convention used is to set the first character of the variable to the type the variable is
defined as (e.g., string, number, Boolean, etc.). For a field containing someone’s first name, that would
be a variable named “sFirstName”. (Using “camel case” for variable names also makes them more
readable.)
Another naming convention would be to use 3 characters to spell out the type, such as “str”, or “num”.
You could also use “int” or “float” to allow others to understand these number variables will have a
specific precision assigned to them.
Using poorly-named variables or reusing variables when unnecessary makes bots difficult to understand.
Convert number to string when using dynamic DOMXPATHs
It is tempting to cast variables when using a dynamic DOMXPATH. Functionally, there is no issue with
this, but making readable code is what you must focus upon. Compare the following two dynamic
DOMXPATHs:
//ul[1]/li[$nItemCount.Number:ToString]/a[1]
//ul[1]/li[$sItemCount$]/a[1]
The second one requires an extra action – Number: To string – but it makes an already-confusing
DOMXPATH a little less confusing.
Separate your bots into logical parts when it makes sense
While not all bots can or should be broken apart, many can. For example, if you have a business process
where you log into a site, perform an action, then log out of the site, it might make sense to separate
those three parts into separate bots. This makes the bot modular and should you need to add another
function to this business process, it’s easy to do so.
Some bots really should stay monolithic: Where the bot performs a specific task only, such as creating a
report daily, it many times does not make sense to break the bot into multiple pieces.
Using nested IF actions for multiple conditions
In Automation 360, we can add many conditions to a single IF action. Sometimes that makes sense:
If ($sName$ != "" and $sAddress$ != "") then do something…
Other times, it makes sense to make those IF actions nested. Look at the conditions you’re testing for. It
they are all the same type of data or related to each other, putting those in a single condition may make
sense. If they are not directly related, it may make logical sense to put them into nested IF actions.
Also, keep the number of conditions you’re testing for 3 or fewer conditions per best practice. Mixing
the “and” and “or” within a single IF statement is also asking for trouble. Use nested IF actions instead.
Don’t make overly-complex XPATHs to filter data; use IF actions instead
It is possible to make XPATHs that are incredibly complex… and difficult to read. Using IF actions helps
people understand what you’re filtering a little clearer than a complex XPATH.