Web Adapter Rematching
We are using Pega Robotics Studio & Runtime 19.1 and are attempting to amend our existing automations for a web application that's being updated to new version. This new version essentially changes the user experience to a single-page web application but, other than that, all of its controls and processes are the same. So, we believed our task should have just been a quick and easy update to the match rules for each WebPage we'd interrogated previously.
Although we were able to update the matching, Studio & Runtime no longer perform a rematch at the WebPage level whenever there's a navigation/page change. The child controls do rematch, but the WebPages themselves do not. As such, the Studio & Runtime believe they are still on the previous WebPage unless we use a 'RematchChildren' method at the Adapter level above.
It has meant that we're unable to use 'WaitForCreate' or 'WaitAny' methods. We have been able to create a workaround to do the same job but, as a result, the automations are slow and less reliable.
We have tried disabling the 'EnableMatchInProcess' property but this didn't resolve the problem. We have also reviewed the below article from the knowledge base, however this solution would require us to completely re-interrogate the web application and rebuild all of our automations from scratch.
https://community.pega.com/knowledgebase/documents/working-single-page-web-applications
Given that Studio & Runtime are recognising events firing on the WebPages and then performing the rematch process for their child controls, we figure there must be a way to force this to happen for the parent WebPage too. In the properties of the Adapter, we have noted the 'IeRematchEvents' property ("...a comma separated list of events that notify a WebPage to rematch..."), which sounds like it may be a possible option, but we could not find any documentation on how to configure this.
Any suggestions would be appreciated. Thanks
Thank you sasnt, we tried this method also but still encountered the re-matching issue. The software simply won't rematch at those parent levels when navigating, only the child controls.
For instance, as suggested, we tried a single page interrogated with various containers/parents (as substitute for the web pages) and each had a 'control children match rule' set on it to only match when the specific child controls for that parent were present (e.g. the username/password boxes on the login page, or the title bars of the home/summary/transactions pages, each of which had a unique element ID, etc). On navigating from one to another, the children became unmatched as expected but the parent stayed matched despite the match rule then being broken. It wasn't until we manually re-matched that it would become unmatched and allow the correct parent to then become matched. Even in interrogation mode, we had to hit refresh on the previous parent and then the current parent. Hitting rematch/refresh on the target parent didn't work until we un-matched the previous one.
I'm sure there will be a way to do it. We just haven't found it yet
Generally, I have found that when controls are not un-matching, it is either because they really are not going away, but are instead changing, or it is because something like the text is changing, but not triggering the matching process. In either case, if you have an event that you can use to rematch from (such as the children getting destroyed), you might be able to use to call rematch manually.
Yes, as I mentioned initially, this is how we've gotten things working but it's a lot slower and less reliable.
There are adapter properties that suggest Studio & Runtime can be told how else to rematch, rather than us programming the manual re-match for every navigation click. 'IeRematchEvents' seems like the right avenue to explore (image attached)...
I don't believe you necessarily need to re-interrogate everything, assuming all of the controls actually exist on one page. What you will need to do is move all of the controls to one page though. You can do this within the adapter OS file. It is standard XML. The easiest way to move things is to use XML Notepad 2007. I've found it to be the easiest way to move control hierarchy. I am attaching some screenshots of how I would move controls between pages. You can use any XML editor, but I prefer the drag-and-drop approach of XML Notepad 2007.
https://www.microsoft.com/en-us/download/details.aspx?id=7973
Once you have all of the controls on the page, what you'll need to do is interrogate parent controls that will substitute for the web pages. These will need to be identified and added you Select Element. These are likely DIV or SPAN controls that are added/removed as you navigate between "pages". Once you designate a control as a container, any of its children that you have interrogated and are matched, should move underneath it. If not, then you can manually move them in the OS file.