We’re preparing to launch Object Repository in 20.10. I made a quick demo around this here. In the demo I used a naive example to explain the basics and get the message through but we’ll promise to come with a more robust demo example soon.
Please share your thoughts with us around Object Repository. What works, what doesn’t, what’s missing and how can we make this better.
If you want to get the latest 20.10 beta build, download from cloud.uipath.com or flip the Studio channel to Preview updates and we’ll automatically upgrade you.
Note: 20.10 Object Repository is not backward compatible with 20.4 and 20.8 Object Repository.
While the intention of Object Repository is not to treat “Browser Change” scenarios, we have seen it work in practice internally. I recommend you try this current version and let us know your thoughts. Thank you! PS: For future releases, we are working on a more elegant solution for “Browser Change” scenarios.
I think object repository for elements and publishing as library is great . I tried my hands on the same .I also tried the upgrade from chrome to edge for "https://www.rpachallange.com " . while saving the Edge elements as library ,the descriptors did not get recognized .
But overall drag and drop feature for descriptors and adding activities is awesome .
publishing the descriptor as library is awesome too
PFA the project file . I have added descriptors for both chrome and Edge. For Edge the workflow is not recognizing the Descriptors while adding as dependency .
Does this work for browser, the era we are in most apps are browser based on cloud, we need this solution to work in robust manner for browser, please confirm as i heard in the video saying “it was not built necessarily for browser based”
Firstly, thanks for the great demo. It will benefit the RPA developers who are building bots using the same application. It will be even better if the object repository can be exported together with the element name for offline discussions with the application SME (subject matter expert). Before upgrading the bot, the SME may be consulted about the UI changes. The Lead RPA developer would then update the UI library for the application and then advise the various CoP RPA developers to test and re-publish their respective bots.
The time saving will be realized on the second and subsequent upgrades after the bots are first upgraded to use Object Repository. That is for existing production bots, it will still required re-training the bot… will there be an easier way to identify, match or migrate to the Object Repository…
Of course it works for browser based apps. Desktop, Web and Mobile apps are all supported. In the video, i mentioned that switching processes descriptors to work from browser type A to browser type B, for example from IE to Chrome, was not the main scenario we intended the feature for. Object Repository aims at solving a reusability issue and then an upgrade issue. While the reusability issue is more obvious, the upgrade issue is about updating processes when the underlying application (lets say Sharepoint) was upgraded and some selectors now fail. In this case, the only change needed is to build a new version of your selectors, publish them as a library, update your process dependencies.
Yes. The feature to migrate from classic UIA to modern will shorten the bot upgrading time. So that production bots can quickly be usable again. Thank you.
Thank you for the demo! This is an exciting feature that helps us reduce a lot of redundancy.
What will make a transition to the changes even smoother is if a library version within a process automatically chooses the latest version available on the package stream. That way, if my library is used in 5 projects, I would not need to go and upgrade each one of them.
Is it possible to add a feature that lets sub-element inherit the selector of the parent element inside the repository?
Use case:
Suppose I have a Citrix app that I need to automate using images. Since it is Citrix, I essentially have a single ‘Window’ despite navigating to different windows/links/menus/etc.
I would like to make a repository of image selectors with the following structure:
Application
1 Screen window for the main portal of an app
→ A bunch of images to click on
→ An unofficial ‘sub window’ here
→ -> Additional links.
2 Screen for a subportal with new forms, links, fields etc
→ Elements that can be click as above.
→ Link to an even deeper WIndow (but from Citrix point of view the same window)
→ -> More Clickables and images
Hopefully that is clear. At each level I am in some sense navigating to a new window, but with the same selector in Citrix (main window). So each window/subwindow/form box that I highlight as an element is really the exact same selector.
However, in the developer’s mind there is some distinction. So many of the sub elements in the repository are really just there to help a developer understand the hierarchy of the application rather than ‘official new windows’. Yet each element MUST contain a selector which means I end up having numerous identical selectors in this approach. This is fine until the selector changes and I have to go through and update each and every element based on the selector.
Anil_G
ashokkarale
jinal.shah
Gautham_Pattabiraman
postwick
chandreshsinh.jadeja
vrdabberu
Ajay_Mishra
sven.wullum1
Vyshnavi_Nalumachu