In this fifth article as part of the Robotic Process Automation (RPA) Implementation Lifecycle article series, continuing our focus on the Design phase we will discuss the topic of selecting the technology interface for RPA as either the User Interface (UI) or the Application Programming Interface (API)
UI vs API as Automation Interface
While RPA as a technology predominantly uses UI to quickly develop Software bots with a low-code approach, a UI as an interface for automation has its own set of limitations especially when it comes to execution, speed, resilience, and scalability of the automation solution.
Due to many such limitations, the use of UI automation has reduced over the years in Software testing within Agile development environments, where quicker feedbacks are important as part of continuous application delivery pipelines. As such, more API level integration testing is preferred for rapid application development iterations as they can be executed quicker and provide more reliable results.
But achieving RPA automation via an API requires higher technical skill sets to leverage, as well as higher implementation costs. This becomes a problem with the low-code citizen developer-led development approach. The below table compares some of these arguments for RPA automation when choosing between a UI and API as the interface for an automation solution.
Shifting demands from UI to API with Technological Disruption
In this era of fast technological disruption, the use of UI as an interface is being significantly impacted. With the advancements in AI technologies such as Speech recognition and Natural language processing, the use of Conversational assistants is on the rise which will overtime reduce the use of UI’s as an interface for computer programs. With 5G being rolled out to drastically enhance internet speeds on mobile devices, the end-user behaviours are expected to change, to demand faster execution of computer programs on the go. Acceleration in the adoption of IoT will create a greater number of connected objects in the globe within just a few years. These everyday objects with embedded IoT sensors will inevitably need to send data over the internet as the API calls to the backend servers. More and more application platforms are now hosted over Cloud infrastructures which are API enabled by default to allow scalability and ease of integration with other systems.
The Case for a Robotic Interface
Given the low-code, citizen-developer led, UI automation centric implementation approach, we have witnessed RPA become one of the fastest-growing software markets in recent times. But the same implementation approach also makes it difficult to scale and a more tactical automation solution for enterprise customers than a strategic one. Although RPA software’s are increasingly making the use of APIs, the industry struggles with the definition of RPA being labeled as a UI automation solution only and the argument shapes up into an RPA vs API debate.
Both UI and API as an automation interface have their pros and cons. The use of APIs are gaining momentum with the advent of newer disruptive technologies. The question is, how do you bring about the best of both worlds? i.e. From a development perspective how do you keep the automation approach low-code, quick and low cost, while from an execution perspective making the automation faster, scalable, and more robust? There is a case for an intermediary interface, between a UI and API, that one can call a Robotic Interface. A Robotic Interface would allow us to achieve this at least for applications that support mature APIs. The below model conceptualises the problem.
A Robotic Interface (RI) would fulfil the below requirements-
- An interface that acts as a low-code wrapper solution to access APIs of underlying applications and allows RPA robots to execute actions on those applications by exchanging information at an API level
- An interface that provides for a minimal, lightweight, and simplified UI, meant for development and maintenance of a specific automation requirement only and does not act as a generic interface for the end-users for the whole of the application
- An interface that can be developed quickly as a low- code app component to fulfil an automation requirement
- An interface that can be called by a software robot or from a variety of other 3rd party integration points such as a IoT device, Chatbot, Conversational agent, etc.
- An interface that can be executed as a headless solution, without needing to interact with the UI of the interface app
Read the other articles in this series from here:
RPA Plan Phase- Benefit Assessment
RPA Plan Phase- Process Identification
RPA Implementation Lifecycle
RPA Design Phase- Attended or Unattended Robots
Contact us at SQA Consulting, to see how we may assist you in developing the necessary skills needed for implementing RPA projects.