We are going to explore the Web Automation Package, again.
Because I failed to address the topic properly last time.
I got distracted (no surprise there) and rambled on about my department hopping journey.
Storytime is supposed to be short and sweet, not long and salty.
Web Automation Package, Revisited
I have to say, you won’t use 90% of the actions present in the Web Automation Package.
The bulk of your RPA automations consist mostly of clicks and type intos, which is why I have dedicated this series to that 90% you won’t use.
What can I say, I love throwing people off.
And yes, this is a series.
Gotta please that algorithm, don’t I?
Always Chasing After the “Advanced Stuff”.
Clicks and Set Actions are easy to grasp.
90% of your automations consists of clicks and type intos, which is why 90% of the Web Automation Package is never used.
In fact, when people come across slightly complex scenarios, they panic and start abusing the Simulate Keystrokes Action.
I won’t lie, I’ve also been in an abusive relationship with Simulate Keystrokes when I first started working with Automation Anywhere, but I’ve grown out of it ever since.
There are plenty of Actions in the sea, so you’d better learn to let go and explore other options.
De-Jargonify for Better Understanding
As I got into the habit of answering questions on technical forums, I slowly realized that it’s better to put things in context instead of explaining abstract concepts and hope people magically understand them, and where they ought to be applied.
Not everyone understands technical jargon, or is born with a sky high IQ, which is why it’s always a good idea to stitch those abstract concepts into a fabric that people are comfortable putting on.
Also, people like stories.
Scratch that, people LOVE stories, so try to narrate your answer instead of shoving it into their faces.
But make sure that you stay on topic or else people will get fed up and leave.
I’m Still Exploring It
Which is why I’ve only been able to compile a list of useful tips so far.
I didn’t get time(read: was too lazy), so I compiled a list of interesting tips for you to gawk at instead.
Tip #1: Reuse, Recycle & Reduce
Are you sick and tired of having to launch and close multiple sessions while using the Web Automation Package?
Of course, you could simple end the session using the End Session Action, but what if you wanted to test a particular scenario that is 10-50 steps into the automation?
Running the same process over and over again until it reaches the step you are interested in is a waste of time isn’t it?
But you don’t have to worry about any of that, because you can reuse the same session by passing in the Localhost ID into the Existing Remote Session.
You can either figure this out from command prompt, but I found another way which is to deliberately fault the automation and nab the Localhost ID from the error message.
This way you don’t have to keep closing each session manually before starting the others (which is done to prevent they from multiplying like rabbits and munching on that juicy RAM during testing).
We have effectively reduced the manual effort involved, which is pretty smart if I say so myself.
We weren’t able to do any recycling today, but that is alright.
Tip #2: You Can Use XPaths, Ya Know.
Most Web Automation Package Actions support XPaths, and you can toggle over to them from the dropdown shown in the screenshot below:
You know what?
Follow along with me.
Head over to your Control Room and replicate the Actions you see in the screenshot below:
Make sure you toggle the options over to “Search by Element XPath” for each interaction.
Once you are done, run it and watch as the magic unfolds.
See how fast all that happened?
Usually you have to include short static delays for the webpage to load when you are using Capture Actions, but the Web Automation Package is smart enough to wait for the page to load before proceeding onto the rest of the actions.
Tip #3: Wait, But Not Indefinitely
In addition to the inbuilt wait, there are two actions you can use when you want to reinforce, lengthen, or make the waiting period more dynamic.
They are the Wait Page Load and Wait Element Loaded Actions.
I prefer using the Wait Element Loaded Action, since it does a better job of waiting, than the Page Load does, because even if the page loads, there is no guarantee that the elements on the page that you are about to interact with have loaded completely.
Of course, it would make sense to use the Wait Element Loaded Action targeting any of the elements you are about to interact with, instead of any random element.
Both Actions output a Boolean Value, either after it detects the element, or if the timeout period has been breached.
This makes error handling a lot easier since it enables you to fashion your automations like so:
I’d recommend adding a 1-3 second Delay right after the Actions just to ensure that the elements really did load.
This is far better than having to rely on just static delays alone, and then start scratching your head wondering why the bot failed at a step which it “didn’t”.
Tip #4: “Focus” Is What Separates the Wheat from the Chaff
Nothing like a little bit of platitude to kick off our fourth tip.
It isn’t necessary to use this action, but back in my MetaBot days(R.I.P) I always made it a point to focus in on the element I was about to interact with before interacting with it.
This was especially useful when automating SAP applications, and the same can be applied to Web Automations as well.
Seems unnecessary, doesn’t it? Well it isn’t always.
This comes in handy when the web application you are automating consists of incredibly dynamic elements, like drop down fields which only populate with values after you interact with them.
No, not the ones where you can set values into them, followed by an enter keystroke. Those are the easy ones.
I’m talking about those dropdowns which only accept inputs when it’s selected from its “list” of options which can take anywhere from a few seconds to half a century to populate with data.
Yes, that wasn’t something I pulled out from my *censored*(keeping it family friendly here), elements like those really do exists.
You don’t have to worry about the performance penalty because it is insignificant and as always, make sure you don’t fact check any of that.
Tip #5: Use Send Keys, Instead of Simulate Keystrokes
This might not seem like that much of a big deal, and that is because it isn’t.
It is more convenient to use actions from the same family than it is to mix and match.
Take a close look at both actions and see if you can spot the difference:
In Simulate Keystrokes, you have to provide a Window Variable as well, and it doesn’t identify the element it ought to interact with whereas in Send Keys, you don’t have to provide any Window Variable and you have the option of specifically telling it which element it ought to interact with.
Interesting Stuff TCT, But It All Seems a Bit…Random?
I started this article with just the idea of reusing the same session, and figured few tips along the way. This is what happens when you take breaks (I didn’t post last week), your brain muscles become weak.
Maybe this is why my manager forces me to work on weekends – he doesn’t want me to lose my edge.
He was looking out for me all along and I thought he was abusing his authority just to make himself good in front of his manager.