Question
CenturyLink
US
Last activity: 16 Jul 2021 14:24 EDT
Options for dealing with interrogated web controls with changing tag/node names
If I'm understanding correctly, when interrogating web controls via Pega Robotics Interrogator:
- Each step in the element hierarchy towards the target control that is represented by a non-standard HTML node/tag name must be represented as an interrogated control under the adapter
- Pega silently stores the node/tag name of the element and uses it as a sort of silent match rule
The combination of these behaviors lead to an issue for us when interrogating controls in a Salesforce Lightning environment. Some portions of the hierarchy of Salesforce Lightning elements have a tendency to change their tag/node name semi-frequently, which also causes all controls under that one to stop matching, even if none of the match rules we've set up specifies the node/tag name to identify the controls.
I would normally use Pega to send JavaScript to the page to achieve the desired functionality, but Salesforce Lightning obfuscates almost all web elements from the 'document' object. I considered trying to pass the web element represented by an interrogated control to one such JavaScript function, but I have not found a way to access the actual web element represented by a matched control from Pega Studio. I expected it to be in the interrogated control properties, but was unable to find anything that looked to fill the part, and, as expected, passing the interrogatedWebControl.This property value to use as the represented web element in the script does not work.
If I'm understanding correctly, when interrogating web controls via Pega Robotics Interrogator:
- Each step in the element hierarchy towards the target control that is represented by a non-standard HTML node/tag name must be represented as an interrogated control under the adapter
- Pega silently stores the node/tag name of the element and uses it as a sort of silent match rule
The combination of these behaviors lead to an issue for us when interrogating controls in a Salesforce Lightning environment. Some portions of the hierarchy of Salesforce Lightning elements have a tendency to change their tag/node name semi-frequently, which also causes all controls under that one to stop matching, even if none of the match rules we've set up specifies the node/tag name to identify the controls.
I would normally use Pega to send JavaScript to the page to achieve the desired functionality, but Salesforce Lightning obfuscates almost all web elements from the 'document' object. I considered trying to pass the web element represented by an interrogated control to one such JavaScript function, but I have not found a way to access the actual web element represented by a matched control from Pega Studio. I expected it to be in the interrogated control properties, but was unable to find anything that looked to fill the part, and, as expected, passing the interrogatedWebControl.This property value to use as the represented web element in the script does not work.
Is there a way to disable the requirement for the node/tag name for interrogated controls? I've tried manually removing the relevant data from the target interrogated control in the adapter.os, but that just causes the control(s) in question to never match. If not, is there a way I can access the web elements represented by interrogated controls under a web adapter for use in a custom JavaScript function? Alternatively, are there any other suggestions for dealing with this sort of situation?
Pegasystems Inc.
US
@MatthewA4496I know that Salesforce Lightning has provided some challenges and that support for them has been added in recent versions. Check the build notes page to see if you are using a version that has support for them. I believe it was 19.1.62 where support was first added. What version of Studio are you using?
CenturyLink
US
@ThomasSasnett 19.1.71. The build notes from #62 only mention supporting the general ability to interrogate Shadow DOMs like Salesforce Lightning, and allowing the ability to unmatch a control when size and location values are 0. 19.1.67 mentions improved combo box support in Salesforce Lightning. Unfortunately, none of that appears to help with creating controls to represent Lightning-specific web elements whose generated tag/node name may be slightly altered between sessions.
Pegasystems Inc.
US
@MatthewA4496If you are using 71, then there have been no specific Lightning changes after that, so you are good there. To answer your original question, if you interrogate a button and then that control becomes a control other than a button (say a custom button type), then it will not match as it will be considered a different control. If the control is identified as a generic control type, then it would match as long as it doesn't become a control type that we can identify (although I have very limited experience with controls changing types). I don't have any recent experience with Lightning as my experience was before Pega had the ability to work with it at all.
With that being said, I imagine there is a way to make this work if we had access to your application to see what is going on. If you have not engaged our professional services team or one of our partners, then you might first start with opening a support case and seeing if they are able to assist.
Updated: 16 Jul 2021 13:37 EDT
CenturyLink
US
I do have INC-183165 currently open for assistance with this, but haven't received a response yet.
More detailed information below on what seems to be happening:
I have a lightning-button control that I need to interact with. Unfortunately, this button sits under about 10 levels of non-standard lightning-specific elements that I do NOT need to interact with. Interrogating the target button results in the above picture. I have tried removing the unnecessary controls between the top and the target button, but that causes the target button to fail to match. This leads me to the first point in my original post:
"Each step in the element hierarchy towards the target control that is represented by a non-standard HTML node/tag name must be represented as an interrogated control under the adapter"
In the above picture, the flexiAcctView[#] controls are the pain points whose tag/node name changes. The match rules I have set up for them tend to look something like:
I do have INC-183165 currently open for assistance with this, but haven't received a response yet.
More detailed information below on what seems to be happening:
I have a lightning-button control that I need to interact with. Unfortunately, this button sits under about 10 levels of non-standard lightning-specific elements that I do NOT need to interact with. Interrogating the target button results in the above picture. I have tried removing the unnecessary controls between the top and the target button, but that causes the target button to fail to match. This leads me to the first point in my original post:
"Each step in the element hierarchy towards the target control that is represented by a non-standard HTML node/tag name must be represented as an interrogated control under the adapter"
In the above picture, the flexiAcctView[#] controls are the pain points whose tag/node name changes. The match rules I have set up for them tend to look something like:
This is all that's necessary to uniquely and reliably identify the control at that stage in the hierarchy. However, if I look at what's stored to represent the same control in the adapter.os:
<OpenSpan.Adapters.Web.WebBase.Controls.WebControl Name="flexiAcctView2" Id="WebControl-8D92751BF66BF2D">
<DummyPropertyToDetectReplaceUndo Value="0" />
<ForwardObjectExplorerEvent Value="True" />
<MatchingIndex Value="0" />
<TagName Value="FORCEGENERATED-ADG-ROLLUP_COMPONENT___FORCE-GENERATED__FLEXIPAGE_-RECORD-PAGE___-C-C-C_-ACCOUNT_-RECORD_-PAGE___-ACCOUNT___-V-I-E-W" />
...
You can see that it's clearly storing the TagName of the control when it was originally interrogated, and it's a huge tag/node name. The changes to the tag/node name between sessions may be as simple as removing the "ADG", or going from "V-I-E-W" at the end to just "VIEW", but it's enough to prevent the match when it ends up being different. I have tried manually adjusting ONLY this value in the adapter.os, and the same setup with the same match rule does successfully match as long as the modified TagName matches the tag name of the element in the browser. This leads to the second point in my original post:
Pega stores the node/tag name of any interrogated element and uses it as a sort of silent match rule.
I believe having a toggle for the above behavior would be enough to resolve this issue, but I'd be surprised if such a feature was currently available in the product due to the uniqueness of the situation.
Does the extra data help bring anything to mind currently in the product that would allow dealing with this scenario?
Pegasystems Inc.
US
@MatthewA4496 This is interesting and not something I have not seen before. I now understand what you mean by tag name. Your analysis is correct, that is basically what we use to identify that type of control as well as where it is in the hierarchy on a page. Since that is changing, I am not sure if that is a situation that would be handled as I understand things. I would have to get hands-on to identify as way to accomplish this though. I do see that the INC has been assigned to a robotics person, with whom I have the utmost confidence in. I am sure that as soon as they are able, they will work with you to resolve the issue.