This article is part of a series authored by Zeth Baker from Republic Airways documenting their experience and decision to migrate to Automation 360. Should your organization be on the fence about upgrading from v10/v11, hearing from customers in their own words can be a great way to see yourself in their story.
In his most recent article, Zeth covered how new variable types and global values have been game-changers in Republic Airways’ ability to find performance and ease-of-development benefits in Automation 360. In this article, he’s back to talk about how Subtasks and Steps have improved their automation development experience.
In mid to late 2020- Automation Anywhere’s developer evangelist, Micah Smith, was hard at work trying to convince me to give A2019/Automation 360 a try again after I’d had some frustrating A2019 experiences upon initial release. He’d explained that, as a fellow v11 devotee, he was now doing all of his automation development in what was then A2019 (now called Automation 360) even though he had the choice to develop on either v11 or A2019/Automation 360. Admittedly, I was very hesitant and dragged my feet a little… he was right, the platform had come a long way. Wait times between pressing “Run Bot” and seeing it execute had significantly been reduced, processing times were vastly improved, there were now quite a few enticing Bot Store packages, and the overall experience felt much more polished. Now, mid-early 2021 – we have only a few bots left to finalize for our migration and I can’t wait to get them off v11! So what are my thoughts now that we’re most of the way converted? I want to highlight 2 key features that have made developing bots on Automation 360 easier and faster than what we were previously doing in v11.
Before you finish saying to yourself “Yea, this is already available in v10/v11” – hear me out. The way that subtasks are handled in Automation 360 is a huge improvement to the way that multi-bot processing works in this new platform. For some quick level-setting for those who may not be familiar with the term, a subtask is a bot that gets called by another bot to do some work. It then reports back to the original bot that called it with some updated values/status. Developing bots with subtasks enables developers to modularize their bot logic, as well as provides for easy re-use across similar automation opportunities.
The most obvious change in using subtasks is the new method of variable mapping. When creating a subtask, developers can now define variables as input and/or output variables. This capability replaces the sometimes-confusing functionality of having all sub-tasks contain bi-directional variables…which was cumbersome to maintain and essentially treated EVERY variable as having a global-scope within the bots in v10/v11. More recently, mapping for sub-tasks was improved even further – giving developers the flexibility to read subtask outputs from either a Dictionary variable or specific 1:1 assigned mapped variables for easy consumption of input values.
Beyond the ease of use in variable mapping, we have also noticed a significant performance improvement in the main task transitioning to run the sub-task in this version as well… so much of an improvement, in fact, that I’ll be diving into those performance improvements in detail in an upcoming article. For now, though, suffice it to say that the new subtask integration has taken on a hybrid approach of a mix between a v11-taskbot and a v11-metabot to become a powerful tool for building modular, reusable, and scalable automation solutions…that, when put together, considerably outperform their v11 counterparts.
A surprisingly useful feature that is a net-new addition to Automation 360 that we’re using quite a bit is the Step package. At first, I admittedly thought “who would ever use this? It seems like a waste of a command package or line of code”, but upon trying them out, I quickly changed my mind. If you are unfamiliar with the Step package, then I think it’s time to get familiar. The Step package is essentially a container that can be used to group/separate bot logic together while having no impact on how the bot itself runs. Steps are great for several reasons:
Beyond the consideration of “What will my bot look like once it’s converted?” – it’s also really important to keep in mind that you will be greeted by a host of new functionality/features that you’ll have access to once your migration is completed. While I, admittedly, originally only saw reasons not to migrate and what felt like the daunting task of learning how things work on this new web-based platform – once I dug into it more, I started to see lots of benefits to us migrating and benefits that could be gained.
I like to end all of these with at least 1 actionable takeaway – and for this article – it’s “get hands-on with Automation 360”. Even if that means just registering for Community Edition and trying out building a sample bot – get hands-on so you can see what possibilities there are for you and your organization as you consider migrating to Automation 360.
A-Lister, RPA Developer, CoE Lead @ Republic Airways
Zeth is a self-taught RPA Developer working in the RPA space for 2 1/2 years using Automation Anywhere. In his free time, he enjoys hanging out with his 3 rescue dogs, cooking, and playing cornhole (bag toss).