Are you sick and tired of performing manual and repetitive tasks every day?

Hire a RPA developer and kiss your problems goodbye!

Are you sick and tired of automating manual and repetitive tasks, only to retrofit those very same manual and repetitive tasks each time the application receives an update?

Yes, I’m Sick of It (And No I Don’t Want an MBA).

You might not like it, but our sales team love it since they get commission when the support contract is extended.

Also, do you know what makes the sales team so special?

Enough With the MBAs!

Alright, so you don’t want an MBA, but instead you want to reduce repetitive labour each time the application receives an update.

Believe it or not, this is possible, and sometimes advisable especially when you are tasked with automating incredibly dynamic and responsive applications like Wolken.

It’s hard for RPA to work with dynamic web elements, especially when it takes its own sweet time to prepare itself.

That is where APIs come into the picture.

Application Programming Interface

Unfortunately, Google only panders to the sky high IQ audience. I have yet to see a definition which I’ve googled up that doesn’t require a fair bit of mental Kung Fu to decipher.

Simply put, APIs allow you to communicate with applications. You can perform CRUD operations with them, and for now that is all you need to know.

Also, the APIs used to interact with Salesforce will not be the same as the APIs used to interact with Wolken or ServiceNow.

Each application has its own set of specifications and protocols which are documented on their official websites and made available on the world wide web.

While testing and using them is relatively straightforward, searching for the right API calls is a headache…for those without the patience to search for them.

Benefits of an API-First Approach

APIs let you interact with an application’s core functionalities in few steps.

If a button provisions users into Workday, and tomorrow that button turns into a radio button (because UI Developers like to mess around with us), the application will still use the exact same API to perform the operation.

In short, even if the UI changes, the API won’t since it operates in the backend.

That being said, APIs do undergo patch updates, but they are minor modifications so they are easier to retrofit provided you have a good grasp over the documentation i.e., know where to look or how to search for the things you want, or if you have an integration team to assist you.

The only time you can’t use an existing API is when it gets deprecated, which is pretty rare and doesn’t happen that often.

I’ll show you a short example, just to show you how useful it can be.

What is This Wolken You Speak Of?

Wolken in an ITSM application, just like ServiceNow.

The UI is incredibly dynamic because UI/UX designers have made it their life’s mission to piss off Automation Developers.

If I had to develop an automation for this back when I was fairly proficient with XPaths, I’d probably end up in a mental asylum from all the retrofitting I’d have to perform to make it work.

I was comfortable using XPaths, which is another way of saying “all I knew were XPaths”.

I was reluctant to learn anything else because it was around that time that I started blogging and was fixated on writing whatever I could to increase my post count for Google.

That obsession has subsided and now I write when I feel like it, mostly because my love for Google was one-sided.

Querying Open Cases on Wolken

I will show you how we can query open service requests in Wolken using APIs, but before I show you how that’s performed, you have to understand that the API documentation may or may not contain a swagger portal for you to test out APIs.

Luckily Wolken has one, which you can visit here.

Automation Anywhere also has a swagger portal which can be accessed by appending a swagger/ to the end of your Control Room URL.

I’ll admit, it won’t be easy for you to follow along with the example since you need a Wolken Instance to try them out, so I’ll try my best to guide you.

Explaining What Comes First in Layman Terms

Before you can access resources within an application, it must grant you access first.

We don’t just head over to Facebook and automatically log into our accounts. You have to let FaceBook know that you have registered an account with it before it lets you in.

The way that’s done, is by sharing something that only you and FaceBook knows…that something is what we call a username and password.

That sensitive data is then sandwiched into a request which is then delivered to FaceBook.

If all goes well then FaceBook lets you in, and if not, it will reject your sandwich and ask you to prepare another one.

Similarly, your APIs are essentially a “request” laden with some “information” and the application will validate whether the request contains whatever is required before proceeding.

A cryptic answer, but that is because authentications these days are not what they once used to be.

If the Application uses OAuth 2.0, you will require more than just an authorization token/bearer. You might even require a Client Id, Client Secret, Domain and God only knows what else to proceed.

According to the Docs, these are the ingredients we need to authenticate.

This is an example of what I had to use to authenticate.

Well, not exactly an “example” since this is exactly what I used to Authenticate.

I would recommend testing them in Postman before moving them to Automation Anywhere.

Once thats done, we can shift our focus towards the main task which is to filter out the items you are interested in.

To understand how that can be achieved, let’s head over to the Service Request page under swagger and browse through them.

Looks like we found just what we were looking for!

The items shown as required are a combination of path or parameters and headers. In Postman, both have their own place that they can call home, whereas Automation Anywhere’s GET request has yet to provide Parameters with a home.

So, if the Parameters have nowhere to go, then were exactly do we place them?

There is a reason parameters are also termed as path. When the API request is made, the parameters will snuggle their way into the URI like so:

And there you have it.

With this, we can retrieve all the items corresponding to the itemId that was passed in. The next question will be “Where did you get this mysterious looking ItemId from?”

That is a really good question.

You have to get a little fancy and use the Dev Tools to procure some of that information.

Lets see how that’s done in another article.