Working with Match rules
Every time an application runs, a new user interface is rendered by the underlying program. Pega Robot Studio uses Match rules to identify the user interface elements across multiple application instances.
To automate an application, a Studio developer must distinguish between unchanging or persistent data that should be used to identify an element and the changing or transient data that should be ignored. Robot Studio provides an advanced matching system that uniquely identifies user interface elements across multiple instances of an application using a set of rules that capture the necessary persistent data. You can customize matching behavior by adding, removing, or modifying these Match rules.
- Controls, targets, and match rules
- Matching behavior
In Pega Robot Studio, controls and targets are organized into trees. For example, the Windows Calculator can be represented with the following tree:
- Understanding the control life cycle
When a Studio project is started, all of the automations, adapters, and controls within the project are instantiated and populated with data. This process is known as deserialization. At this point, all of the controls within an adapter exist, but have not been matched. Because the controls exist, they are available for use within automations.
- Using RefreshMatching
All controls within Studio provide a RefreshMatching method. This method lets you enable developers to rematch a control’s children. RefreshMatching takes a single Boolean parameter, detach, that determines if it destroys all of the children (and grandchildren) before rematching, or if it simply looks for new matches.
- Matching triggers
- Matching optimizations
- Match Rule best practices
To use Pega Robot Studio effectively, you must understand the application you are interrogating and automating. For matching, this means paying attention to where controls are used and when they match.
Previous topic Interrogating cloneable targets Next topic Controls, targets, and match rules