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
- Master, Main, and Sub bots
- Master 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
- Initial setup for the process.
- Validation that the setup was successful. For example, check whether all required files and folders exist or initial variable values are populated as required.
- Run the desktop PRE-PROCESS CLEANUP.
- 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:
- Validation of any input. For example, input variable values from the master bot.
- Execution of sub bots.
- Validation of any output.
- Ensure population of any output variable values based on the execution of main bot, to return to the master bot.
In the CATCH section, log the error, and ensure population of any output variable values, for example, oStrResult to pass back to the master bot.
- Sub bots
- A sub bot is called by the master 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.
- Master 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:
- Main and Sub bots: This pattern includes the master and the main bot in an single main bot. The design pattern of the Sub bot is similar to the design pattern explained above.
- Master, Main, and Sub bots
- 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
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
- Develop a configurable event handler TaskBot 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 TaskBot 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
use the following:
Salesforce - Professional Edition - Internet Explorer
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.
- 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
- 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.