Short answer: Yes.
Long answer: This article.
Variables, and Why We Need Them
When manipulating data, it makes sense to organize that data into individual containers with labels. This makes it easier to identify the data while also speeding things up as memory allocation happens according to the “container” it is assigned to. Data isn’t simply being jammed into one big container – it gets compartmentalized into containers of appropriate sizes which as a result, consumes less RAM during execution.
“Window” is one such variable that Automation Anywhere has introduced into the A360 family, and we are about to dive into its functionalities.
But Why Tho?
Why introduce a window variable in the first place?
What purpose does it serve?
How does it impact development?
We will answer them one by one.
Benefit of Having a Window Identifier
In Automation Anywhere, web automation is very much similar to Selenium, in that Xpaths are used to identify UI Elements.
You don’t necessarily have to craft an Xpath for each and every web interaction since the Recorder: Capture Action is capable of recording object properties – one of which contains the Xpath.
The auto-captured object properties might require few tweaks, especially if you wish to make your automations robust. This is achieved by checking and unchecking object properties, and maybe refine few properties.
But this only covers half of it.
Before the bot starts analyzing items on a screen, it has to first detect whether it is on the right screen or not, and the bot was developed to operate this way for a very good reason.
Imagine you had several browser tabs open, there is a good chance that the object properties for a UI Element you wish to interact with in the first tab, may coincide with a UI Element present on another tab.
To avoid this confusion (which often happens with Selenium, or at least when I used Selenium), the bot first checks the Window Title, before validating the Object Properties.
Has it started making sense , as to why they decided to create a separate variable to identify windows?
Can’t They Simply Convert the Window Into an Object Property?
They could, but that would be a waste of time.
You’d have to assign the window title (which is a string) to the imaginary WindowTitle Object Property for each UI interaction which sounds like a pain.
And what if the titles are dynamic?
The Object Properties only accept strings, so you won’t be able to replace segments of the window title with wildcards.
You see the complexity we end up having to delve into?
A360’s Window Variable
To create a Window Variable, first navigate to the Variables panel and click on the plus icon as shown in the screenshot below:
You can create a window variable by selecting it from the dropdown from the highlighted option as shown below:
After that, you are presented with two options, with Browser set as Default.
Is Browser Any Good?
I have never used Browser in any of my automations so far, because of what seems to me, like a massive drawback.
Shown below are the parameters that show up once the window is selected under browser:
From the parameters provided above, only the Window Title is editable.
That is a major issue especially when dealing with dynamic web pages, where the URL is also subject to change.
We can’t modify the URL, which is why I’ve termed it as a massive drawback.
Who knows, maybe they are working on a resolution for this, but as of today, you cannot edit the URL.
Also, this can only be used to automate web elements present in the same browser, i.e., if you open your control room in Google Chrome and have two other tabs open, the Browser can only detect three tabs within Google Chrome itself(and not the other active applications).
Application is Meant for “Applications”
Here is what the Window Variable toggled to Application looks like:
This contains the Window Title as well as the Application Path, which is common across all devices, so you won’t face any issues there.
The window detection is based entirely on the Window Title, which makes things super convenient for us!
In addition to that, the Application can toggle between “Currently Active”, “Desktop”, “Taskbar” or the variable containing the Window Title.
Currently Active is pretty useful, and I have yet to use the other two.
But You Can’t
Access windows present in the same browser thought.
They ought to make some sort of universal Window detector right?
While it’s easy for us to sit here and complain, they have to slog it out to make things work.
Let’s cut them some slack and appreciate the effort they have invested so far.
Assigning Window Variables to Actions
You will mostly assign the variables to Recorder: Capture Actions, since most interactions are achieved easily through the Recorder Package.
There are times however, when Simulate Keystrokes ends up squeezing its way into our automations when the Recorder: Capture Action isn’t capable enough to perform an operation or two.
Then there are Delays, but you get the point.
Wait a Minute, We Have to Assign The Window Variable to Each Action?
Then…Why Not Convert It Into an Object Property?
As much as I love playing devil’s advocate with myself, you do raise some pretty good points, me.
It does soften the impact of one of my talking points, since we have to assign the Window Variable for each UI Interaction, however, the task isn’t as tedious.
You don’t have to expand the object properties for each Capture Action and assign it there.
The main selling point of window variables as highlighted above is the fact that we can toggle between Browser and Application as well as manipulate the Window Title either by adding wildcards to omit parts that tend to change (are dynamic), or by leveraging the Regex Functionalities of Window Variables.
And with that, we have answered all the questions posed towards the start of this article (not in order, but I think I did a pretty good job).