Automation 360 brings with it the ability for anyone to create and run their own bots. If you’re brand new to the concept of robotic process automation (RPA) and looking for a place to get started – this is a perfect place to start. In this tutorial, we’ll be building a bot to automate logging in to a website. We’ll look at how the bot can be built out and tested, and even look at an alternative building approach that enables users to build out repeatable actions very quickly.
Machine Setup Video Referenced: https://www.youtube.com/watch?v=6Rvhln_RFys
If you’re brand new to Automation Anywhere, there are a couple of steps you’ll need to follow to properly get set up:
Once you’ve got the setup stuff out of the way, we can get into actually building a bot. Upon creating a new bot, you’ll be taken to the Automation 360 workbench. The Automation 360 workbench exists solely on this web interface, so you have absolutely everything you need to build out your bot directly in this web application.
The Workbench is divided into 3 areas.
On the far left, we have the Variables, Actions, and Triggers panes. For the purposes of building your first bot demo from the video above, we really only made use of the Actions pane, but here’s a quick breakdown of each:
Variables: Variables enable you to create and reference dynamic placeholders for your data. Let’s say you read some data from a webpage and wanted to copy that to an Excel spreadsheet. That data would be saved to a variable and then referenced when writing to the spreadsheet. Variables enable the bots you create to be more dynamic in the way they handle and process data.
Actions: The Actions pane shows a collection of packages. Each package is a collection of actions. Actions are the “tools in the toolbelt” for an RPA bot builder. They represent all of the individual actions that your bot can do – from clicking on a link or entering data on a form in the Recorder package, to modifying and updating a spreadsheet or CSV file in the Excel Basic and Excel Advanced package. These actions represent the building blocks that make up bots.
Triggers: Triggers enable bot builders to determine when, and under what conditions their bot should “wake up” and start running. These triggers can run after files show up in a monitored directory, after a keystroke command is given, after an email comes in to a particular mailbox, etc. In addition to the triggers seen on this tab, bots can also be run on a repeating schedule or can be executed as part of an AARI process.
The middle (and largest section) of the Automation 360 Workbench is the bot editor. The bot editor displays the actions that any created bot is using, as well as their order of execution. This area can be displayed as a flow view (which looks like a visual diagram flow of the bot logic), a list view (which displays each action in a list – similar to previous versions of Automation Anywhere) or a dual view (which is a split combination view showing both flow and list views side by side).
Also available in the bot editor area is access to the recorder, device selection, and common operations like cut/copy/paste that can be used when one or more bot steps are selected.
To the right of the bot editor, we find the action details section. If no action from the bot editor area is selected, the Action details area will be blank or hidden. When an action is selected in the bot editor, the action details area will dynamically display the configuration details of the selected step. From the tutorial above, this area was used to fill in the username/password used for the login, and to configure the final step of the bot to be a click of the mouse on the login page.
Once built, we tested the bot by clicking the Run button on the top right of the Automation 360 Workbench. At this point, the Control Room (the central hub of Automation 360) sends a request to the Bot Agent (the utility we installed as a part of our setup) to execute a bot. The Bot Agent validates that it has all the necessary dependencies (downloading any missing dependencies from the Control Room) and begins the execution of the bot. As mentioned in the video, the first time a bot runs – it may need to download several dependencies – all of which are stored as local temporary files on the bot runner. As subsequent bot runs occur, those dependencies would have already been loaded, so future runs won’t take nearly as long to start executing.
One final note about running our bot: These bots can be run locally on your own machine (referred to as attended automation – similar to what we did with this tutorial) or they can be scheduled and run on virtual machines running on a server within your organization or even in the cloud (referred to as unattended automation). Dependent on the use case, and the conditions under which the bot should execute, you’ll likely find use cases for both attended and unattended automation.
Giving in to the cliche, building bots is a lot like riding a bike. You can start small with automating simple tasks like website automation and CSV/Excel manipulation and move on to automating more advanced processes. If you had fun with this tutorial and want to continue learning more about bot building, consider following one of the Developer Portal learning journeys or heading over to Automation Anywhere University to take some of the freely available RPA training courses.