The new norm of frequent application updates
In the current form of the world, applications and systems in general are dynamically changing all the time allowing up-to-date systems in a permanent way. However, at the same time, it has the tendency to bring some challenges. This means that they are evolving at a very fast pace and technically speaking, this is reflected by new versions released more often. As a result, elements and objects on the screen may change purposely from time to time.
As users, we all most likely have experienced at some point that confusing feeling when one or more of the fields that we usually enter the data into have changed their name, moved to another section of the screen, changed their functionality or even disappeared. As human beings, we are in a position to take the time to understand the situation and make decisions around it as to whether we ignore the fields or assume which ones are correct or even contact support for help. The question is, how do robots handle this?
How do robots behave when facing new UI layouts?
In general, robots locate UI elements based on unique key identifiers such as name, title, ID, amongst others. Sometimes, these identifiers are randomly generated creating a security layer for UI. However, even under these circumstances, robots are capable of finding those objects through the use of anchors and positions of related elements. This is if the RPA developer implemented those at development time.
However, there is a particular situation where element identifiers are configured by web developers without compromising the element’s purpose. In this scenario, robots are unable to locate the elements and the process will either fail with an exception referring to a UI selector not found or will continue if the RPA architect considered a recovery process. This is by ignoring that particular element if not found but triggering notifications to relevant staff. The former is the most common situation as the majority of use cases are around fields that have to be filled out because they are needed.
This will require a rework and the automation will have to be updated. This will involve a potential downtime, as well as development time, to go through all the steps that are consuming those elements and update the selectors. There are some workarounds to overcome this very quickly, but they are not the topic of this article because as expected, workarounds come with a price and some caveats are involved.
The challenge when fixing broken UI automations.
Now, let’s imagine that there are multiple bots deployed consuming the same application. The selectors used when developing the automation are locked to the application in the state that it was when the automation was built. As developers, you will have to go through all of them and update the selectors as many times as needed involving the mentioned downtime and several hours for rework.
Is there a permanent solution?
UiPath had a solution for this issue in the roadmap for some time and released a first version of the Object Repository in October 2020. This is as a resilient way to find elements on the screen but also to allow minimum disruptions when elements cannot be found allowing a very quick recovery. In the latest release, 21.4, Object Repository has finally become a strong feature available in UiPath which differentiates UiPath against other RPA competitors.
What is Object Repository?
Object Repository is a centralised platform acting as a middle layer independent of the workflows. This is where UI elements are stored after being captured as objects in a DOM-like fashion. Object Repository quickly captures elements needed in the automation through the Capture Elements wizard. This then incorporates automatically the use of anchors to ensure the reliability when slight UI changes occur. The elements captured are reusable across projects when packaged as libraries. This ultimately allows a fast upgrade of workflows in one go with UI libraries.
Object Repository transforms some of the existing concepts from the classic design into a robust solution for reliability. Selectors are now part of a superset called UI Descriptors which along with the UI libraries, they have become the bread and butter of the Object Repository.
In summary, the Object Repository ensures the following advantages for UI elements across automation projects:
Ultimately, those above are key in ensuring a more reliable automation for customers and minimum disruptions when UI changes occur.
Written by Carlos Perales, Senior Automation Consultant
With over 15 years of experience in Australia and South America providing exceptional technical analysis and design in process automation. His experience ranges from design to implementation of data processing systems, data integration, process automation solutions and digital transformation. He brings an innovative spirit and strong attention to detail to this role.
Our team call on years of industry experience to create end to end improvements that achieve real efficiencies where it counts most. Entrago is dedicated to delivering solutions that drive positive outcomes across the enterprise. Contact Us about how we can improve your business processes with ServiceNow, AWS or UiPath entrago.com.au/contact