Best practice/suggestions to use Object repository libraries

Help Studio
, ,
1

We are currently evaluating the opportunities and consequences of using Object Repository library. We are comformtable using modern design expierence and the object repository functions and have reviewed the relevant academy courses.

We would love to hear how your team has standardized the use of Object Repository libraries within and across projects.

Some questions we are curious to know more about are:

  • What has been your positive experiences of using Object Repositories?
  • Has it added additional development processes for your Developers/Solution Designers?
  • What naming conventions have you used for Applications,Screens and Elements. For example, do you name a button a Button_Login, Input_UserName?
  • What hurdles have you met while updating elements in Object Repository and comsuming it in process?
  • How do you document / communicate which version of Object Repository library contains what kind of elements? so that developers know which ones to use in their processes. (Say version 1 has 1 Application, 2 Screens, 3 Elements and version 2 has 1 Application, 5 Screens, 13 Elements)

Thank you for your time. :vulcan_salute:

2 Likes
2

Hey @jeevith

It made our automation implementation a bit streamlined, whenever we got some new automation with the same application it was a cakewalk.

Iā€™m not getting this point sorry ?

I canā€™t disclose the standards used, but we have used something similar for easy identification of the elements and all the fields filled

One big challenge for us was not to create duplicates. Like two developers unknowingly creating two objects for same element.

We had object repository as a separate library project and it was maintained on a code repo which helped

Hope this helps

Thanks
#nK

1 Like
3

I know the thread is not fresh, but my question is similar:

  • how do people handle object repository libraries with differing selectors for the targeted application? Think ā€œslight differences between the application in its test and prod environmentā€.

I am currently exploring 2 approaches

  • maintaining each version in a separate Git repository branch, and build library-nugetpackages with a distinctive package name. I even merge between branches and do mass-updates in the .content files. Benefit: clearly named packages, also during (multi-year?) maintenance. Downside: I need to update the main projectā€™s dependencies and need to package separately for e.g. test and prod.

  • out of again 2 branches I have just 1 package name that I build not publishing to the Orchestrator feed but to a local folder. I then make sure that the package ends up in the correct Orcehstrator tenant. Benefit: update to the library in the dependency manager is easier, because I do not need to remove and add another dependency; I just need to update. Disadvantage: the package looks the same by name, but does potentially create confusion during maintenance.

A CI/CD pipeline can help in both cases, especially when manipulating the project.json (like on-the-fly modifications to the dependencies).

I am also looking into all the versionNumber options like build metadata Semantic Versioning 2.0.0 | Semantic Versioning (semver.org)

Would love to hear from others! Even a ā€œproblem statementā€ might help the community to learn fro each other.

1 Like
4

What Iā€™m seeing here @cprima is an opportunity to use Regex selectors :slightly_smiling_face:

Or an asset with values in different tenants of you like dev, test and prod

5

I find the whole object repository a bit ā€˜too little too lateā€™.
On paper it is a great feature, and the way UiPath has implemented it is not too bad either. But nowadays a lot of tools/applications are browser based, and content Ć”nd structure are way more dynamic than in classic applications. Especially when working with platforms that have dynamic form creation, dynamic layouts etc. Example SalesForce, or TopDesk and the likesā€¦

This kind of limits the usability of an object library, since itā€™s implementation is a bit too static. You can work around it a bit, but from a maintenance point of view, this costs more time than you gain developing.

So if your target app is very static in structure it can be a valuable tool, but if not, I recommend not using object libraries. If standardization is still desired, create reusable activities with dynamic selectors in a library instead.