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.
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
Accepted Solution
Updated: 30 May 2021 14:44 EDT
QBE European Operations
GB
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)...
EDIT: For any future readers of this post, unfortunately we did not find the desired solution and effectively needed to create our own 'WaitForCreate' method as an automation for each navigation/refresh. A support request was made for some more hands-on assistance but found that way we handled the issue was ultimately the best way for our use case. That was automation of Guidewire ClaimCenter v10 using Internet Explorer 11 - our existing bots worked on ClaimCenter v6 and needed to be upgraded to v10, as rebuilding all of them in Chrome would have taken much more time. That said, we will actually be moving our existing automations to either Edge or Chrome over the next year now anyway due to Microsoft's announcement that IE11 will be disabled by June 2022. Feel free to send me a message if you encounter similar issues and would like some input or advice
Pegasystems Inc.
US
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.
QBE European Operations
GB
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
Pegasystems Inc.
US
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.
Accepted Solution
Updated: 30 May 2021 14:44 EDT
QBE European Operations
GB
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)...
EDIT: For any future readers of this post, unfortunately we did not find the desired solution and effectively needed to create our own 'WaitForCreate' method as an automation for each navigation/refresh. A support request was made for some more hands-on assistance but found that way we handled the issue was ultimately the best way for our use case. That was automation of Guidewire ClaimCenter v10 using Internet Explorer 11 - our existing bots worked on ClaimCenter v6 and needed to be upgraded to v10, as rebuilding all of them in Chrome would have taken much more time. That said, we will actually be moving our existing automations to either Edge or Chrome over the next year now anyway due to Microsoft's announcement that IE11 will be disabled by June 2022. Feel free to send me a message if you encounter similar issues and would like some input or advice