The Object Repository ensures the management, reusability, and reliability of UI elements by capturing them as objects in a DOM-like repository, sharable across projects. It allows for creating and reusing UI taxonomies inside and across automation projects. With Object Repository you can build a UI API for your application and share it with your team within minutes.
The key features of the Object Repository are:
- UI elements across the project are managed, updated, and modified from a centralized place.
- view a list of all your UI activities inside your process by using the UI Activities tab inside Object Repository panel.
- quickly capture elements you need in your automation with the Capture Elements wizard.
- increased selector reliability with the help of the Capture Elements recorder that captures elements, together with their anchors.
- with the help of anchors, objects keep their reliability in case the application received a slightly new UI.
- drag-and-drop elements from the Object Repository panel.
- objects are reusable in local project or across projects when packaged as libraries.
- upgrade application and process UI elements in one go with UI libraries.
The Object Repository works with UiPath.UIAutomation.Activities package versions 2020.10 and above in projects that use the Modern Design Experience. Note that UIAutomationNext package has been deprecated as of 20.10. The activities from UIAutomationNext are now found in the UIAutomation package. The Object Repository is not available in cross-platform projects.
The Use Modern for new projects toggle controls the default design experience for new projects. Modern experience is a new way of designing automation with wizards, recorders, and activities part of the packs enhanced for Object Repository support. This toggle is on a global level, meaning that if enabled, all new projects are created within the context of modern design experience.
When the Object Repository enforced toggle is set to Yes, activities part of the UIAutomation pack need to reference elements from the Object Repository.
There is also a "Modern Experience" toggle at the project level. If enabled, the current project operates within the context of modern design experience. In a modern design experience, the classic UI Automation activities are hidden by default. They can be enabled by using the filters inside the Activities Panel. Alternatively, you can always switch to Classic Experience for a particular project from project settings. Or you can switch the behavior for new projects from the backstage Studio settings.
A UI Descriptor is a superset of selectors. It holds information for uniquely identifying elements on the screen.
UI Descriptors are extracted from activities in the workflow and added to a structured schema that groups them by Applications, Application Versions, Screens, and UI Elements. Out of this taxonomy structure, only Screens and Elements hold descriptor information. The rest are used for grouping and their role is to ensure upgrades between versions of an application.
UI Descriptors can be part of:
- one project for wide reuse.
- snippets repositories for testing purposes.
- UI Libraries for global cross-project sharing.
UI Elements contain full or partial element selectors, anchor selectors, screen and element image capture context, and other metadata that describes the element on the screen.
Screens are UI Scopes that are either extracted from activities inside the workflow or are generated at element capture time. A screen groups together multiple elements belonging to the same screen.
A UI Application is a targeted application that can have multiple versions and each version can have multiple screens. Applications can be of multiple types:
- Desktop / Web Application
- Mobile Application
For defining mobile applications, you need to use UiPath.MobileAutomation.Activities package.
The structure of UI libraries created with the Object Browser has the following hierarchy: Application > Version > Screen > UI Element.
A UI Library is an encapsulation of elements grouped by applications, application versions, and screens. Elements you define can be extracted as a UI Library, and after publishing can be installed in other projects as a dependency.
A UI Library may contain several applications but can contain only one version of a certain application. This mechanism ensures that when you upgrade a dependency, you also upgrade the application version you were using inside your projects.
Note that when creating a new version of an existing application, you need to reuse the existing elements. Elements have unique identifiers that are used when referenced from activities. You can always change the contents of an element (descriptors and other metadata).
The Object Repository enables you to reuse your UI elements across projects:
- all locally stored elements can be reused at project level
- for testing purposes you can use Snippets panel to save into and pass applications between projects. From Snippets you can add applications to your local project repository.
- extract elements into UI libraries and install them as a dependency into your projects when you want to reuse at a global level. You can also take a reusability-first approach and start by creating UI Libraries with the elements you will need across all your automation projects.
The object repository has a tree structure where each node is an object representing screens or elements, all hierarchical under the application. The structure is the following:
- Application - can be one of 2 types: mobile or desktop/web, depending on what technology is used for UI Automation.
- Version - applications can have multiple versions
- Screen - top-level window of an application version that can only be created under an app version.
- UI element - an object on the screen with a descriptor and metadata. It can be of multiple types.
UI elements can be freely rearranged in the tree structure, as long as they remain under their designated screen. To move, simply drag and drop the element to the desired location inside the tree.
Elements can also be part of other elements and they can also be grouped under containers with no UI specific role. This allows defining a UI structure that is as close as possible to what the user sees on screen.
Updated about a month ago