Disclaimer: This is a watered-down approach of building frameworks. If you want a proper end to end article detailing each and every aspect of building a robust and dependable framework, go write one yourself.

If you though this article was about implementing structural frameworks to avoid fire hazards…

.

.

.

Then don’t click away just because I led you astray.

Fate has brought you here on my website to reveal a new career opportunity that has been booming in the market recently. It’s called Robotic Process Automation, and we are about to dive deep.

Well, maybe not deep, since this is just an introduction but deep enough for you to know understand why we need them.

Why Use Bot Frameworks Anyway?

Like with most programming languages, developers don’t build code from scratch. We adopt the “Rome was not built in a day, but its already built so why not move in?” mentality while developing solutions.

To put it in layman terms, we survive by relying on the wisdom gleaned from the great ruins of StackOverflow. Sure, the documentation helps a lot, but our attention spans are too low and none of us have the grit to plough through the arid deserts of technical documentation. We search for boxed up solutions online and throw a temper tantrum when we don’t find any.

While these snippets of code work well on their own and nothing prevents us from directly implementing them, but it’s always best to build an infrastructure around it – which is essentially boilerplate code that takes care of most of the development for us.

This boilerplate code takes care of various activities like loading configuration details, initializing applications and handling exceptions etc. just to name a few.

That’s Right, Frameworks Help with Exceptions Too.

“Woah, why are there even exceptions in the first place?”

You’re asking good questions, which means you’ve been paying attention!

This one is slightly off topic, but no matter what you build, you can’t predict every roadblock the automation will encounter once its deployed. Problems can range from access issues to improper setup or even network instability.

Were the right set of credentials stored in the credential vault, or were the credentials…*Trigger Alert*

.

.

.

.

hardcoded?

Did the application stop responding due to a network issue, or did it fail because the developer did a brilliant job of automating the webpage?

We use frameworks to answer these hard-hitting questions. “Use” because we are far too lazy busy to build our own. Hard-hitting, because that’s how it feels when we receive a barrage of error mails from an automation that worked fine…until now.

Frameworks help us capture execution details which give us a clear picture as to what went down which in turn helps us analyse and retrofit the automation. Bottomline is – we won’t have to code as much and can devote our attention to building the business process.

Lay it Down for Us

Imagine that you’ve been tasked with automating a business process that involves a CRM application, Excel and Microsoft Outlook. Your task is to automate data entry from Excel received by mail, into the CRM. The mails might also contain PDF files, and sometimes Word documents which should be ignored.

You also notice that they occasionally include text files, but no discussion took place over what had to be done with them.

.

.

.

.

.

Confused?

If you’ve ever had the misfortune of gathering requirements, then I bet you are fairly acquainted with this.

Requirements Gathered, Now What?

Schools have taught us to rely more on the stuff that’s jammed into our heads, and less on the creative potential that Mother Nature has bestowed upon us. Let’s not do that anymore – or at least for the duration of this exercise.

Now that we have our requirements, we must imagine that the automation has already been built.

It’s easy – our managers do this all the time.

This might sound silly, but it helps to play out scenarios in your head before putting anything into action, and that’s done by developing the automation with your imagination.

What’s that?

You think its also silly for someone to expect you to deliver a process right after gathering requirements?

Oh you sweet innocent child~

What Must Happen First?

Should we head over to our mailbox, or open the CRM? Wouldn’t you say that it only makes sense to open the CRM if there are items to process?

Regardless of which application must open first, we need a component to initialize applications. But in order to initialize programs, we must know which application to initialize and which credentials to use in which environment.

To keep it simple, the bot must load up on some configuration data before it automates business processes. If the bot is deployed onto a test server, it shouldn’t log into the application using production credentials.

If the bot is supposed feed data into Oracle CRM, it shouldn’t open up TheCodingTheory and like and share all the posts…

Although I wouldn’t complain if it did.

You can read more on how all of that is set up here.

To reiterate, the bot must be configured before deploying it anywhere.  Deploy a bot without configuring it, and the client will deploy you into the afterlife.

Configuration Block Thingy

Here is what the configuration component is supposed to look like on a high level:

The data is mostly stored in XML. Excel and flat files are alright, but I prefer using XML because its easier to maintain complex structures within it. Some would say that it all boils down to a matter of preference, and to that I say:

Bot Configured and Ready for Deployment!

Hold your horses! we aren’t done yet.

Before the bot tries to log into any application, that application should be running right? Sure, the bot could simply launch the application, but we must take care of one more scenario.

What if the application is already running?

It could fail, since the application is already running. Yes, yes, we can use conditional logic or get a little fancy with the Window Titles to handle this, but it’s always better to start off with a clean slate.

To do so, we first kill the applications the bot is about to use – for several reasons.

If there are multiple active sessions, and you want to design the bot to intelligently use the right one, good luck with that.

If there are multiple active sessions and you happened to develop something that intelligently detects the right window to work on, then you are smarter than I am, and I hate you for it.

Also, having too many applications open can lead to high RAM usage which can interfere with the application’s performance which is why its better to…

Just Kill It.

This is the only place where you can do some killing without getting arrested for it. No, saying that doesn’t make you a psychopath – its the context in which you say it that matters. Just tell everyone that you are following best practices.

Now where were we?

Ah yes, we can kill applications by using the Application: Open Action.

The files you want to kill go into the parameters, and if you aren’t sure what the application names are then head over to Command Prompt and type in Tasklist.

You can search for the application name there. Also, its better if you include the user profile while killing the application, or else it will kill applications across all user profiles, and we don’t want that now do we?

/F /FI "USERNAME eq $str_userProfile$" /IM excel.exe /IM chrome.exe /IM OUTLOOK.EXE

That’s it Folks!

It seems like I rambled across the thousand-word mark which is also known as the “no one is reading this anymore, you’re wasting time go be useful elsewhere” mark.

We will dig a bit deeper next week without going off topic too many times.