Building reusable bots

Review the guidelines to gain a better understanding of how to develop bots or subtasks for reusability, from designing and creating through reusing.

Define prerequisites, input, output, and variables
When you build bots for reusability, define the following:
  • Document all necessary prerequisites on how to use your bot either on its own or as a subtask.
  • When creating your bots, define values as input, output, or local. Input and output variables are used when your bot is designed to be used as a subtask, allowing it to receive and pass back values to or from another calling bot.
  • Provide meaningful variable descriptions when defining input and output variables so that other developers know how to interact with your subtask.
  • Adhere to an established standard for variable naming guidelines. Review the Automation Anywhere user-defined variables for variable naming guidelines. Your variables (user-defined)
Follow single-responsibility principle
Bots developed for reusability should follow the single - responsibility principle which states that each subtask or component should have responsibility over a single part of the functionality of the overall bot and that responsibility should be entirely encapsulated by that subtask or component.

Other examples of single-responsibility:

  • A subtask that processes a single transaction, but can be called multiple times for each transaction on a list.
  • A subtask that collects screen display data on a single page of a website, but can be called multiple times as a bot goes through pagination.
Bot design considerations
Consider the following patterns based on which templates must be developed for use:
  1. Primary, Main, and Sub bots
    • Primary bot: This bot is called directly to begin the process, through mechanisms including scheduling through the Control Room or API call. Include the following major process steps in the TRY section:
      1. Initial setup for the process.
      2. Validation that the setup was successful. For example, check whether all required files and folders exist or initial variable values are populated as required.
      3. Run the desktop PRE-PROCESS CLEANUP.
      4. Call the main bot to run the business logic of the process.

      In the FINALLY section, run the desktop POST-PROCESS CLEANUP.

    • Main bot: This bot calls the sub bots as required to run the business logic of the process. Include the following major process steps in the TRY section:
      1. Validation of any input. For example, input variable values from the primary bot.
      2. Execution of sub bots.
      3. Validation of any output.
      4. Ensure population of any output variable values based on the execution of main bot, to return to the primary bot.

      In the CATCH section, log the error, and ensure population of any output variable values, for example, oStrResult to pass back to the primary bot.

    • Sub bots
      • A sub bot is called by the primary bot or main bot to run the actual business logic required for the automation. They are also referred to as helper tasks or utility tasks because their only purpose is to assist the calling task.
      • Use output variables to return a result indicator to the calling bot either main, or another sub bot. For example, outStrResult. The value contains an error message if the processing was not successful due to an error or exception that had occurred.
  2. Main and Sub bots: This pattern includes the primary and the main bot in an single main bot. The design pattern of the Sub bot is similar to the design pattern explained above.
Opening and closing applications
Any applications, files, or windows that a bot or subtask opens must be closed by the same bot or subtask.
  • For example, when a bot opens Microsoft Excel to perform a spreadsheet operation, verify that the spreadsheet and Excel are closed when the bot finishes processing.
  • Close applications when the bot execution is successful or unsuccessful.
  • Use the Finally block of the Try/Catch/Finally operation to ensure applications are closed regardless of success of the task processing.
  • In the case that applications do not respond during testing, consider using the command prompt to forcefully close (kill) the applications. For example, to forcefully close power point, the command-line operation would be:
    Taskkill /IM powerpnt.exe /F
Error handling
After completing the task, verify that the bot successfully handles any failure or exceptions.
  • Each task or subtask must handle its own errors.
  • An unhandled exception in a subtask can cause issues in a parent task.
  • Use Try/Catch/Finally blocks at the root level of every bot.
  • Use Try/Catch blocks inside of a loop if you want to try an operation multiple times before reporting a failure.
Event or exception handling
Other than action errors that are captured by Try/Catch, you must perform code checks for other processes such as events or exceptions. If a certain process condition occurs, notify or log these conditions for additional analysis.
  • Develop a configurable event handler Task Bot that minimizes the requirement for code changes if the actions change. For example, maintain an XML file that contains a definition of all the possible events or exceptions and any notification requirements when those events or exceptions occur.
  • In the code, when such events or exceptions occur, write the information to an event log. You can also add memory usages and capture a screenshot.
  • Run the event handler Task Bot to process the event or exception. For example, issue a notification using parameters such as email recipient, CC recipient, or subject from the XML file.
  • If the notification requirements vary for each environment, or change over time, the configuration file can be updated without having to change the code.
Running bots on other computers
When designing a bot, enable it so it runs on computers other than the computer on which a bot was created.
  • Use variables for local file paths, network shares, or window titles so that your bot can successfully run from other machines.
  • Consider using global values for environment markers or network shares that multiple bots need access to.
  • Use wildcard characters for window titles where appropriate to enable bots to run regardless of specific environment or version of the target application. For example, instead of using
    Salesforce - Professional Edition - Internet Explorer
    use the following:
    Salesforce - * - Internet Explorer
Using prompts, message boxes, and infinite loops
Prompts and message box actions stop the bots from running when waiting for a user input. Unless a user input is required, design the bots without using prompt statements.
  • When using loops, ensure all loops have a definite end by clearly defining their number of iterations or specifying where break loop actions need to exist.
  • If your bot is intended to run as an unattended bot, remove or disable any prompts or message box actions.
  • If you are building bots for an attended automation scenario, message boxes and prompts are often reasonable or required for bots to run as expected. Use message boxes to display different variables, such as, responses, outputs, or values.
Storing sensitive data in the Credential Vault
The Control Room includes the Credential Vault that can be used to store sensitive information, such as user names, passwords, API keys, and tokens.
  • When building a bot, create a locker in the Control Room using the Credential Vault to store credentials and retrieve them as required by referencing the credential and the attribute. This allows users to create bots that consume APIs or perform logins without the need for bot builders to directly hard-code the required credentials within a bot.
  • Do not hard-code sensitive credentials into a bot, or a subtask, because hard-coded storage in a bot introduces a security risk.
  • When Credential Vault values are required to be used in a bot, verify that all locker names and credentials are clearly defined in the bot documentation. If required, include details on how to obtain credentials, for example, an API key or a token.
Testing independent tasks
When creating bots for reusability, design them in a way that they can be tested independently of other subtasks.
  • Practice the test-driven development (TDD) approach: When adding a new bot, or a new feature in an application, write a test case for it.
  • In a test case, define the specific function that validates that feature or functionality.
  • For single-responsibility principle and reusability, create many smaller tasks that can be tested independently.
Using comments and steps
Comments enable developers to provide descriptions within their bots so that bot other bot developers can better understand what each section, block of code, or subtask is designed for. Include clear comments to allow developers to understand the purpose of the function of a given code block.
  • When bots are submitted to the Bot Store, commenting demonstrates how to customize the bot.
  • Using comments makes code maintenance easier because section descriptions help identify where changes might be required to enable developers to work towards quicker issue resolution
  • Comments on bots that are a work in progress can be helpful when creating placeholders for future work. Consider using a TODO command as a reminder to add logic to the bot, but update the comments when the work is completed.
  • Automation 360 includes the Step action, which provides the capability to organize the code into logical groupings to improve readability and the flow.
  • Create an outline of the major objectives of your bot by using empty, labeled step actions. When that is completed, go back to each step and complete the logic for the step.
Creating logging files
Identifying problems without logs can be difficult when bots are running unattended on any number of Bot Runners. Software developers, support teams, and bot owners rely on logs to understand where their automations have issues and how to diagnose problems. Bots must log errors to get error details.
  • Use error handling and screen captures to better understand when a bot or subtask encounters an error.
  • Use the A2019 Bot Store template that contains basic error handling, logging, and snapshot capabilities with the customizable root logging location for maintaining older log files.

    Bot Store bot template

  • If required, create additional logging files and include a full audit history of everything a bot or subtask has done. The additional log files can include audit, debug, and performance information about the bot, as well as the following:
    • Main bot start and end time.
    • Subtask start and end time.
    • The completion time of specific milestones defined within the bot.
    • Number of transactions received in an input file.
    • Number of successfully processed or failed transactions.
See also: Best practices: Building reusable and secure Automation 360 bots and packages