This topic provides an introduction to common bot design guidelines and standards. Avoiding these common mistakes and including these processes and considerations in your bot design standards, creates bots that are clean, easier to read, test, and maintain, and are stable. Most of the guidelines improve either efficient use of production resources or reduce maintenance time and errors.

Bot design considerations

• Best practice

  Generally, keep a Automation Anywhere Task Bots to less than 500 lines of code, preferably only a few hundred lines.

• Break out processes: Giant business processes > giant bots

  The key to the successful bot development of a business process is a well-defined, well-thought-out strategy. If a business process is so large that it requires more than 8 or 10 sub-tasks, or any one task contains thousands of lines, then reconsidered the bot approach to the process.

  Evaluate your business processes. Use this understanding when creating your associated bot approach.

  • Can the business process itself be simplified? Identify any redundant or circular steps.

  • Identify logical, contained breaks or splits in your processes.

  • Can parts of the business process be split into separate bots?

• Reduce repetition

  Do not repeat yourself principle (DRY) and Rule of three, both basically mean, reduce repetition.

  Create a loop that contains a single call, rather than calling a same small number of steps separately.

  Use variables where appropriate.

  Break out repeated bits of logic or commands into sub-tasks. If a set of commands is repeated multiple times across a task, it makes maintenance difficult. If it needs an update, all instances need to be located and correctly updated.

• Plan for maintenance

  When a rule is encoded in a replicated set of tasks changes, whoever maintains the code has to change it in all places correctly. This process is error-prone and often leads to problems.

  Contain the set of command and rules in one location. If the set of commands or rules exist in only one place, then they can be easily changed there.

• Test-driven design

  Smaller tasks can easily be tested alone, in a unit-test fashion. Tasks without dependencies can use automated testing. Tasks split into sub-tasks by separate functions, even tasks that are performed one time at the beginning of a sequence, increase maintainability and ease of testing.

• Network fault handling

  When creating bots that rely on network connectivity, ensure to include steps for gracefully handling networking delays. For example, when a bot requires a web page response, such as opening a Save As dialog, and the network has an outage. What do you want the bot to do, try again or exit out with a message?

Sub-task overview

A sub-task is called by the parent task that needs the service. They are also referred to as a helper tasks or utility tasks, since their only purpose is to assist the calling task.

Benefits include:

• The production task code is shorter.

• When changes are needed, only the subtask needs to be located, analyzed, and edited. This makes bot maintainance easier.

• Make sub-tasks as reusable as possible.

  If factored out properly, sub-tasks can be made to be reusable, making them even more productive. The subtask can be called by any number of other tasks, including other bots.

• Make sub-tasks as standalone as possible.

  Sub-tasks do not stand entirely alone. They should not run one their own. They should be called by a parent task. But remove as many other task dependencies where possible.

Sub-task considerations

• Single responsibility principle

  Apply one task or responsibility to each sub-task.

  Splitting large tasks into sub-tasks is useful, but pulling all similarly related small tasks into one sub-tasks is still prone to maintenance errors. Making a change to one small task might affect the other small tasks contained in the larger sub-task.

  Better to make multiple sub-tasks, each with a single, specific purpose. For example, if you have a large sub-task that handles printing a PDF, moving a file, and saving a file, split these sub-tasks out. Give each sub-task its own responsibility – One for print to a PDF, another for moving the files, and a third for saving files.

• Decoupling dependencies

  When possible, define sub-tasks so they do not require the calling task to provide information. The required information is a dependency. Identify the dependency and include it in the sub-task. This makes the sub-tasks stand-alone, enables unit-testing, and allows it to be called by other tasks without adding dependencies.

  For example, if a login sub-tasks can only be called if the calling task provides a URL, it has dependency. All parent tasks calling the sub-task must provide a URL. If the URL changes, more than one task must be change. If the login sub-task includes the URL, it is decoupled from the parent task. If the URL changes, only the one sub-task needs an update.

• Bi-directional dependencies

  If sub-tasks cannot change without calling tasks changing, they are dependent and not truly decoupled. If calling tasks cannot change without all sub-tasks changing, they are not truly decoupled, and have bi-directional dependencies. These interwoven dependencies make unit-testing nearly impossible.

• Avoid too many sub-tasks

  While all of the above principles are excellent principles for designing bots, too many sub-tasks also becomes prone to maintenance challenges and confusion. The number of sub-tasks needs to be a manageable amount.

  A bot that has 30 sub-tasks, or would be thousands and thousands of lines without using sub-tasks, probably indicates a business process that is too large for one bot. Break down large processes into pieces, then encapsulate each of the separate pieces into their own bots.

Sub-task example

For example, suppose a bot has the need print a notepad document as a PDF file. The task might look like the following:

In this example, there is a need to print a file as a PDF document three times. On the example development machine the PDF print driver is called Pdf995.

Recommendations:

• Because there is likelihood that the PDF print driver in production has a different name, investigate if using a variable is practical.

• Because there is the potential for this task to promoted to production, and possibly repeated multiple times, recommendation is to turn this into a sub-task.

The example seen as a sub-task:

If any changes are required to this specific set of commands, only this helper task needs to be edited, and only this helper task needs to be retested.