When it comes to migrating from Automation v10/v11 to Automation 360, there are actually a few different options that developers have to get their bots on to the newest platform. One option is running the Bot Migration Wizard from the Automation 360 Control Room when logged in as an administrator. For atmx files that have already been uploaded to the Automation 360 Control Room, this is a great option as it will detect dependencies and ensure that all subtasks (dependent atmx files) are migrated as well.
Another option for bot migration is creating an Automation 360 bot that leverages the Bot Migration package. In this tutorial, we’ll take a look at a sample v11 bot, and look at the process of migrating it to Automation 360. So that we’re all seeing the same screens/experience, you can download the sample v11 bot that we’ll be using for the remainder of the tutorial from the Automation Anywhere GitHub repo.
Examining the Bot
Opening the bot we’re going to be migrating to Automation 360, we can see it’s pretty straightforward. It opens with some error handling, launches chrome to a CSV-lab webpage, downloads a csv file, then reads data from that file to enter into a web form. In a production use case, we’d want to run this bot through the Bot Scanner Utility to validate its compatibility with Automation 360, but since this tutorial is focusing on the Bot Migration package, we’ll skip over that part for now.
You may optionally run the bot once or twice if you want to see how it executes and you have a v11 environment available to you. Regardless, the image below demonstrates the bot in action.
Building the Migration Bot
Over in your Automation 360 environment (Enterprise or Community Edition both work for this) – create a new bot. For the purposes of this tutorial, we’ll be naming our bot MigrateBot. Once your version of MigrateBot has been created and opened, follow the steps below to get it set up.
- In the Actions pane on the left-hand side of the bot building interface, click the Bot Migration package to reveal its Migrate bot action.
- Click and drag the Migrate bot action into your bot flow to add the action to your newly created bot.
- In the step configuration pane on the right side of the screen, we’ll need to provide some details regarding where we want to import from, if/where we want to store output from our migration and make a determination of overwriting in the case of a file by the same name already in existence.
- For the Select task bot file field, select Desktop file and navigate to the directory in which your atmx file for conversion is stored. This will be specific to your situation as you may be using the downloaded file provided above or your own atmx file
- For the Output folder path, we’ll be using a temp directory to store the output. The Migrate Bot action will save out an XML with recap details of the conversion upon completion. This can be helpful to review if you’re running into issues during the conversion or you’re working with support who may need more information on an issue you may face.
- For the Overwrite the file if exists option – we’ll be leaving this checked for this demo – obviously its up to you if you want to leverage this capability or not when migrating a larger number of bots.
- Tip: Be careful – as bots that previously existed in different subdirectories may have identical naming and could cause issues upon migration.
Reviewing Migration Results
Pressing the Run button, we can now execute our migration. If you haven’t previously used the Bot Migration package, the Control Room will first make sure that a copy of the package is loaded locally for execution. Once that dependency has been satisfied, the bot will begin the process of migrating the v11 bot we selected – converting it into an editable Automation 360 bot.
Note: Directory structure is not something that is replicated when using the Bot Migration package in conjunction with the Desktop file approach like we’ve taken here. As an alternative, we could have replicated the intended folder structure and imported the atmx file to the Control Room prior to migration.
Pro Tip: Unless you’re really happy with the organization of your atmx files in v10/v11, use this migration as an opportunity to revisit the organization of your bots. For federated CoE’s, that might look something like Bots (folder) > Factory Name (folder) > Bot Name (folder) > Master Bot (bot).
Once your bot has finished executing, there are 2 things we have as an output for review:
- If you provided a path for the optional Output folder directory, you should have an XML file that essentially is a log of each evaluated command in your bot, as well as some note about its migration to Automation 360 equivalent actions.
- If your migration failed, you can review this XML to see what command conversion failed – and you can see additional details about what caused the failure and how it may be resolved. Again, we’d want to make sure to use the Bot Scanner utility prior to beginning the migration so we aren’t surprised by the results when attempting to migrate.
- If your migration was successful, this XML is still worth checking out as it highlights some specifics of the migration process. For example, in the sample bot we’re uploading for this tutorial, it mentions that in error handling, the ‘Take Snapshot’ action will not migrate unless a file path was previously specified in the v11 bot.
- The second, and most important, outcome of our migration is the new bot itself. As mentioned, because we’d migrated an atmx file that was on our Desktop, our migrated bot will be in the root of the Bots directory on our Private tab.
- The first thing you may notice is that we have a yield/error sign on our bot. Lets open it up and see what still needs fixing before we can start with our testing.
- If you’re following along with the tutorial, we have 2 actions that need correcting – and both are actually related to date – located on lines 2 and 43.
- When creating the v11 bot, a $Date$ variable was used for saving out the snapshot in the case of error as a part of the bot’s error handling.
- In our Automation 360 migrated-version of this bot, we need to specify the date format for use in our snapshot naming.
- Instead of the provided Custom Format, select the Formats radio button and select the ISO_LOCAL_DATE option to correct each of the 2 error lines:
Running the Bot
With the 2 error lines resolved, we can now go through the process of reviewing the bot logic and doing our first test run.
The Migrate Bot action really does well at converting logic from v11 to Automation 360. For example, we’d used a system environment variable to reference the location for saving the ‘MissingVendor.csv’ from the tutorial web application – and validating if the file was already downloaded locally or not. While it’s not done exactly that same way in Automation 360, we can see that on line 6, an action was added to get the system variable ‘USERNAME’ and line 7, that same system value (stored as a variable) is now referenced as a part of our conditional statement.
We can also see that our error handler from v11 was migrated to Try-Catch-Finally blocks now. This is a much more flexible approach to error handling, and a point we may want to revisit after validating the state of this bot as an Automation 360 bot. Speaking of which, let’s run it and see how it works.
Couple of things you may notice upon running the bot:
- At the beginning of the bot run, you may notice that you’re prompted for input values (something you may not have seen before – even as an Automation 360 developer if you hadn’t previously mapped input values). We see this as a result of the migration because in v10/v11, ALL variables were global in scope – to say that they could be mapped in/out when calling the bot as a subtask.
- Because this meant all values in v10/v11, that’s why you’re seeing the option to map input values here when starting the bot run. The mapping in our case can be ignored as no input values are needed for our sample bot to run.
- When first executing a bot run in Automation 360, the local bot agent (on either the dev device like we’re showing here or an unattended bot runner) is in communication with the Control Room to be sure that it has everything needed locally to execute the required automation.
- For our sample bot, that means that things like the Error Handling package, Datetime Package, Excel Advanced package, etc must be loaded locally to the bot runner/dev machine before that device can execute the bot run. Most importantly – this only happens if the package has not already been downloaded to the bot agent. If it’s already there, the bot agent validates that with the Control Room and can start executing.
- So this is the long explanation to say that if this is your first time running an Automation 360 bot, you may notice that it takes a bit longer from the pressing of play until the bot starts executing the first time you run any bot.
Conclusion and Next Steps
In this tutorial, we went through and executed the migration of a v11 bot to Automation 360. We reviewed the output of that migration and validated that everything worked as expected. As mentioned previously, there are multiple ways to migrate bots, but if you don’t have access to an account that has admin rights on the Control Room, using the Bot Migration package is a great way to get started.
As for next steps, we created a bot that used a hard-coded path to import a v10/v11 bot. Consider creating a bot that can loop through a directory to migrate multiple bots at once if you have many bots that need to be migrated. Finally, also consider how you might modify some of the bots post-migration. This could include using some of the new Automation 360 variable types and reviewing some of the new Automation 360 packages to expand on our bots capabilities.
Good luck with the migration of your v10/v11 bots and Go be great!