This article is the third Developer Portal blog post authored by Zeth Baker previously from Republic Airways, and the first in a mini-series of Automation 360 Top Features documenting Republic Airway's perspectives on Automation 360 features.
If you’ve read any of this series of articles or briefly looked into upgrading to Automation 360, you’re probably wondering is there really a benefit to upgrading or wondering if you should continue to build in v11 until its end-of-life date (RIP v11). Well then, this article might just be perfect for you - speaking as a developer and someone who went through this exact same thought process.
From the time I first saw the web-based version of Automation 360 back at the Imagine 2019 conference in New York, I was excited and curious for what was to come. Then – to be perfectly honest - I got my hands on a beta version in late 2019 and mostly gave up on touching it for over a year due to how long the bot launcher was taking, bot execution times, and how different everything felt. In this post, we'll take a look at one of my, surprisingly, favorite new features: Variables.
Bot Variables
Initially, I had mixed feelings about the new variable types. There is a slight learning curve to understanding the new types and how they work, but once you get comfortable with them, they are a very positive improvement. After using them in several builds, I find the new variable types increase accuracy, improve reliability, and in some cases decrease the number of lines of code. Long gone are the days of assigning a date to a value variable and then having the v11 bot mistakenly perform a math calculation until you add a character to convert it to a string. Hallelujah! The new types also help to improve overall development speed, in my opinion, since the variables are intended to contain a specific data element for a specific use.
Global Values
Taking variables one step further though, there is a feature I have been requesting for a long time that has now been built into Automation 360: Global Values! In our migration effort, global values have become something all our bots have been heavily reliant upon for systematic continuity.
For example, let’s say your infrastructure team is migrating SQL servers and they have decided to change the server name (something out of your control, but it does happen from time to time). If you built your bots using a global value to represent the server name, then all you would need to do is edit the global value in the Control Room and everything should continue running as designed. No longer do you have to check out the bot change the values, test, and re-import the bot. Hopefully, you weren’t doing this though, because this would mean you hard-coded some values and that is a risk in a production bot. Global values can have lots of use cases – from environment-specific markers/shares (as in different file store locations for test vs dev vs production) to variables that many bots may need to reference for their processing (URLs, central log file locations, etc). I’m even exploring the concept of storing some DOMX paths as global values so that I don’t have to modify recorder steps across multiple bots when web applications change their page structure (I haven’t proven this out yet, so take that last idea with a grain of salt).
Conclusion
There's a lot to love about the new variable types and the addition of Global Values once you start to get more comfortable with the concepts and their applications. Ironic that an area of initial trepidation has turned out to be a feature that actually speeds up development time and enables us to do more with fewer lines of code and fewer weird dependencies on data files stored out in certain locations to replicate the functionality of Global Values.