MetaBots are highly reusable, create it once, and use it everywhere functional subtasks.

They are DLL or screen-capture based – and enable organizations to create highly reusable components that can be called from the bots that are created in Automation Anywhere Enterprise v10/v11. Because they can serve as reusable “library” style automation components, Metabots are also used to swiftly accommodate newer versions of apps and services utilized in an enterprise organization.

Regardless of whether your MetaBots being DLL based or screen-capture based, at some point – you’ll need to migrate them to Automation 360. In this tutorial we’ll go through the process of migrating a bot that references a DLL-based Metabot to demonstrate what these assets look like as you migrate them to Automation360!

For some background on the bots we’re working with, we're using an Automation Anywhere Enterprise v11 bot that was designed to complete this challenge.

In this process, the Metabot is responsible for calling the “employee data” API to get some employee details: a phone number and the start date, using a DLL.

For demonstration purposes, the Metabot contains two logics: one for each piece of data we’re gathering from the API.

Side Note: For all of you Bot Games super fans, we’ve broken this call up into 2 logics for demonstration purposes only, you wouldn’t necessarily need 2 logics here based on the specific challenge used, but we’re demonstrating how a MetaBot with 2 logics converts to Automation 360…so hang with us here).

Pro-Tip: If you want to learn to build your own DLLs to use in a MetaBot, you can follow this tutorial on how to build DLLs for Automation Anywhere Enterprise v11, otherwise, feel free to download the files used for this walkthrough and follow along!

Migrating

The whole migration process consists, simply put, consists of three stages:

1. First, your migration compatibility will be evaluated with the assistance of the Automation Anywhere Documentation and the Bot Scanner Utility;
2. Next, your control room and data will be migrated to Automation 360 – either done manually (for on-prem implementations) or through the use of the Cloud Migration Utility.
3. Lastly, your bots will be migrated (converted to an Automation 360 compatible format) and validated.
   1. Building a bot specifically for the purpose of migrating bots is one of the strategies for doing so and this is accomplished with the help of the Bot Migration package. This approach works best for one-off migrations, while you’d typically use the Bot Migration Wizard for atmx/mbot files that have already been migrated to your Automation 360 Control Room.

For additional information about approaches to your Automation 360 Migration – check out the Upgrade Launchpad – designed to guide you through the process of completing a successful migration.

For the purposes of this demo, we’ll be taking the Bot Migration Package approach - which can be helpful for times when you need to migrate a small number of bots or one-offs.

Before creating the bot to migrate Enterprise v10/v11 bots, think about the repository structure in place in your Automation 360 Control Room - especially if there's a specific structure where this process (atmx + mbot files) should go or if a new repository structure should be created. one. Make sure to create a folder with the process name so all Tasks, reusable Subtasks and dependencies can be found in the same place. It's better to start organized from the start than try to clean this stuff up later

Setting up the Migration bot, in A360:

Configure the Bot Migration: Migrate action pointing to the legacy bot (.atmx file) as well as the Metabot file (.mbot) and run it.

Since we're migrating a Main Task, a sub Task and a Metabot, we're using 3 actions - with one action hard coded for each atmx/mbot file we need to migrate.

You could also loop through each file in a folder, but if you do use this approach for a larger number of files, make sure to add conditional statements in place to only grab atmx/mbot files along with some Error Handling.

Once you run the Migration Bot, our legacy – now Automation 360 - bots will be output into your root Bots folder:

A new folder with the name of the Metabot will be created:

This matches the name of the Metabot used previously in v11:

These legacy bots were all linked together in v11. Now that we have migrated them, we have a bit of tidying up to do to restore their relationship and get them up and running. Inside the Metabot folder, you'll find a Task Bot for each Logic contained in a Metabot. In this case we have 5 items in total: two Task Bots (GetDate, GetPhone), the main DLL which calls the API (HROnboardingAPI.dll) and two DLLs dependencies.

This is the before and after of each logic. The new Task is pointing at HROnboardingAPI.dll since that is the DLL which contains the function this bot is using.

• GetDate Logic:
  • In v11:
  • In A360:

• GetPhone Logic:
  • In v11
  • In A360:

This is what the legacy bot looks like in comparison with the migrated bot before cleanup.

• v11:

• A360:

After some cleanup on the Master and LegacyApp Tasks (such as references to directories that don't exist anymore and legacy variables – see the video above for one approach to doing this cleanup), we also must point the Tasks to the correct path they are now according to the folder structure in place on your Control Room:

• Before: Standard folder structure from v11
• After: Correctly pointing to where the task is now

In this case each Logic outputs one variable only, and we can then use each method of the DLL easily with the reusable Task bot, while mapping the output directly to a new variable.

Don't forget to fix the path for the dependent DLL according to your new folder structure.

That’s it! You should have reusable Automation 360 task bot for each Logic that was previously defined in your Metabot. You can now safely call these subtasks in Automation 360 from any other bot as needed.

Conclusion

Using subtasks enables your bot to use a wide range of “helper bots”, making your automation easier to maintain, reducing redundant logic and providing for easy reusability. You simply call the Task that you need to reference, when and if you need it. The compartmentalization of the logic is the benefit that comes from having separate task bots - one for each logic. This is the reason why other programming languages include things like functions and objects... You only want to write it once, and if you want to use it again, you invoke it.

Take this a step further and consider creating a “library” of helper bots/reusable subtasks and/or assets that can be used by other bots multiple times.