This tutorial is a guest post from Ashwin A.K from Speridian Technologies - a global business and technology solutions provider. Speridian's business and technology experts help clients modernize their businesses through Digital Transformation.
If you have an idea for a blog post or tutorial that you think would benefit the Automation Anywhere developer community, let us know at developer@automationanywhere.com.
Developing robust automations doesn’t have to be a challenging task. You just need to understand what to use where.
If you are comfortable working with just RPA, chances are you will develop entire automations with whatever is currently available at the RPA workspace. If that is your approach, then you might not be too keen on exploring solutions that require a bit of scripting.
On the flipside, if you love coding then you would be inclined to rely on scripts more, even going as far as to drench the entire automation with code.
The problem with this is not everyone understands code or even wants to code.
Some would argue that it isn’t necessary for an RPA developer to learn scripting at all, but there are instances where it’s convenient to use scripts.
For example, complex data manipulation such as grouping data or generating pivot tables is easily achieved through VBA or Python.
A module in Python called Pandas is tailor-made for data analysis. A lot can be achieved in a few lines of code and lesser time using Pandas, whereas achieving the same through RPA will lead to lots of complexity and longer execution time.
In a way, scripts complement RPA by reducing the development time while also optimizing the solution.
Similarly, there are tools out there that complement RPA and we will explore one such example.
Introducing Workato
Workato operates purely on the basis of APIs.
Automations built using Workato are incredibly robust since it communicates directly with the backend. The only time things go wrong is when the network goes down, if too many requests have been sent (status code: 429) or if you don’t know what you are doing.
Automation Anywhere can work with APIs right?
Automation Anywhere is an incredibly versatile RPA Tool, but it wasn’t developed just for API automation.
Sure, we can send and receive requests and easily parse the payload with the JSON Package which was recently introduced, but Workato was specifically built for Application Integration so it would only make sense to leverage that instead of building everything from scratch (and end up in scratches).
Let’s dive into today’s example.
Raising Incidents in Wolken Wolken is an ITSM tool used to organize and streamline IT services. It’s through this that we request access to various applications, raise service requests and/or incidents.
ITSM tools are configured in such a way that the tasks are assigned to the right team at the right time with the right amount of information (for the most part).
Raising Incidents for Automation Anywhere?
Bot failures aren’t anything to lose sleep over, but they have to be taken care of ASAP.
When you raise incidents, they are assigned to the appropriate team with an SLA tagged to each incident.
This also provides the manager with some much-needed insight into which bots are in dire need of a retrofit, how many tickets the support team receives on a day-to-day basis, and how many developers are required to provide adequate support.
This, in turn, keeps them productive and improves their operational efficiency since there isn’t any confusion as to who has to work on what.
This is what makes ITSM tools invaluable to an organization.
How do I know?
When must incidents be raised for RPA?
Automation failures are roughly classified into Exceptions and Errors.
Exceptions are minor issues mostly related to data inconsistency, and for the most part, can be ignored. A mail is usually drafted with details of the exception to business users and they can decide whether to involve the developers or if it’s something that can be taken care of, from their end or if it’s insignificant and can be ignored.
Errors are more serious and often refer to system failures.
If the bot is unable to interact with the application, then you will be unable to interact with your family until you resolve the issue at hand.
To ensure that the team responds swiftly, we can “integrate” ITSM into the loop, and Workato will help us with that.
Creating APIs with Workato
Most Workato recipes operate on the basis of triggers or schedules, but it also lets you create your very own APIs.
Given below are few screenshots of the Workato Recipe that was developed for this process:
For this API to work, we have to pass in some information for it to work on. Fun thing about it is we get to decide what that information gets to be.
The logic is embedded in a flowchart with data from one step being used in subsequent steps:
There's a lot more to it so think of this as an introduction.
If we were to head over to Automation Anywhere, we will send a request to this Workato Recipe once the bot encounters an error.
In the Error Handler Action or child bot (if you use frameworks, chances are you will delegate this to a child bot), an API call is made and the appropriate payload/parameters are passed:
It's best to create a Child Bot to call the Workato Recipe since it remains common throughout
The next step would be to drag in a POST Request and pass in URI, Authorization, and Payload like this:
The URI and Authorization are obtained from the API Platform > API Collection in Workato:
If all goes well...I mean if all doesn’t go well, then an incident is created in Wolken and it will get assigned to the respective team:
This might seem like simple automation that is very much doable with just RPA, but it’s not as doable as you think it is.
There is a fair bit of complexity involved, which is easily achieved with Business Integration Tools. Here is the flowchart to give you an idea of what the recipe actually takes care of:
What If I Wanted to Develop it Completely With Automation Anywhere?
Instead of leveraging Workato, you can design workflows using Wolken APIs and get creative with it.
If you’ve studied the lucid chart, you might have noticed that we don’t raise the same incident over and over again, instead send reminders if the incident was raised within the last three days.
The logic for that is pretty straightforward, and you can use MS SQL, SQLite or even Oracle DB for storing Incident details, like when it was raised, with what subject and exception message, along with its ticket ID.
How you go about designing the solution depends on the tools you are comfortable working with.
Here is how I would go about developing the solution.
When an incident is raised, the details are stored to Database. So at the start, the bot will check if the incident had been raised before using a Select Statement.
SELECT * FROM [Active_Wolken_Incidents] AS inc
WHERE
inc.[PROCESS_NAME] = '$Api_Process_Name$' AND
inc.[TASK_NAME] = '$Api_Task_Name$' AND
inc.[ERROR_DESCRIPTION] = '$Api_Error_Description$' AND
inc.[ERROR_LINE_NUMBER] = '$Api_ErrorLine_Number$i' AND
inc.[CREATION_DATE] > DATEADD(DAY, -3, GETDATE());If the data table’s row count is zero, that means the same error was not reported for more than three days and the bot will proceed to raise an incident.
Once the incident has been raised, all that’s left is to create an entry so that if next time the same bot runs into the same error, it won’t create duplicate incidents.
INSERT INTO [Active_Wolken_Incidents]
VALUES(
'$TicketID$'
,'$Api_Process_Name$'
,'$Api_Task_Name$'
,'$Api_Error_Description$'
,'$Api_ErrorLine_Number$'
,'$Api_Bot_Runner$'
,'$Api_Server_Name$'
,GETDATE()
);Then towards the end of the automation, or in the finally block, the bot will delete incidents where the Creation Date is greater than three days from today.
If this is not performed, then it will keep sending reminders for tickets that have already been closed. Yes, you can also add the ticket status to DB and add few more conditions to prevent that from happening, but we don’t have to complicate things any further.
Let’s keep it simple.
Here is a portion of the workflow just to get you started:
While Workato is great at working with APIs, RPA is incredibly versatile and can perform frontend and backend automations with ease.
Conclusion
You can achieve a lot with RPA, but don’t shy away from learning other tools as it will open up a whole new world of possibilities as it did for me.
Ashwin A.K
RPA Developer @ Speridian Technologies
Ashwin A.K is an RPA enthusiast who spends his free time helping people out on the APeople forum, while also keeping his blog updated with new RPA content every Monday and Wednesday.