Robotic Process Automation
Robotic Process Automation (RPS) is an interesting area of integration and one that has kind of been around for years but has also been taking off again.
Back in the day there were screen scraping technologies which companies would sometimes use with mixed results but sometimes good success. RPA is the latest reinvention of that approach but taking advantage or technology changes which can help make those problems more successful. There have been significant advances in the GUI testing tools and also application virtualization technologies which have all combined to recreate the interest in Application Automation.
The idea of RPA is that the combination of Artifical Intelligence and virtualization can create a robotic workforce which can use your applications to execute business processes.
Probably 2 of the most likely use cases for RPA are:
- Burst scaling your workforce
- Exploratory integration scenarios
Burst Scale Workforce
The burst scale of the workforce is a really obvious and good RPA candidate. Lets imagine you are an office and you receive paper work which you have employees that key in data to process an application. Normally you have 5 users who do this but at seasonal points you get a huge growth in demand.
Using an RPA tool here combined with an OCR tool would allow the scanning of the paperwork and the RPA tool to be able to work with the interpreted scan to automate the use of your application to key in the application form.
This is a common use case and there are cases of organisations scaling on demand their workforce by many multiples to meet peak demand.
Exploratory Integration Scenarios
One of my most recent experiences with RPA was around a use case where we wanted to integrate Dynamics into a legacy application for the transfer of some data. We had a development team who could write API's to integrate with the legacy application to make this automated but it is expensive and time consuming to build these API's and there were also some resource conflicts at the time.
An alternative option we considered was the use of an RPA tool we already had which could be used to key in the data. The value of this was it could prove the business value of the end to end process without having to spend much money implementing a technical solution. The RPA tools is often intended to be managed by business users and in this case we started by getting a user to use the Data Export features of Dynamics to download a spreadsheet of data and to then use the excel spreadsheet as an input to the RPA tool.
The tool was then able to drive the user interface of our legacy application and to input all of these transactions. The below picture shows what this looks like.
Now this solution on its own could have been deemed successful enough and low cost that some organisations may choose to keep this as their destination solution to the problem. Other companies may choose to then go to an additional step and do some partial automation.
In the below diagram you can see that we choose to use our existing BizTalk investment to extract data from CRM on a scheduled basis. BizTalk would deliver the file to an SFTP server or folder from where the RPA bot could process the data into the legacy system as before.
Now at this point we have a solution which could just work and is fully automated. We may choose to just keep the bot and not move to an API. There could be a significant argument for this is the lifecycle of the legacy application was limited.
One of the benefits of the RPA bot was that there is also options to take data back the other way too. The bot could extract data via the user interface or alternatively it could be adding response data to the file we originally supplied. The bot could then put a response file back for BizTalk to load into CRM again. The below picture shows this.
Some RPA tools even offer more advanced functionality than just file based input and output and you can take an RPA process and expose it as an API. In our scenario we had considered that rather than a batch based approach which was arguably simpler, we could have considered an event based approach where in CRM an event was published to Service Bus. We could then have used an Azure Function or Logic App to enrich the data and make a call to the RPA API which would then drive the user interface of the legacy app and give us a response.
RPA on Microsoft & Azure
Hopefully by this point I have given you some food for thought on what kind of things can be done with RPA and how it could play into integration use cases.
The next question is if your a Microsoft customer how do you take things forwards. Well when it comes to RPA and automation of applications at the user interface level Microsoft dont directly offer a product themselves, but via the Azure Marketplace you can be introduced to two partners who have very interesting products: