Hi Sam,
First I want to echo my colleague Sam's reply and advise you to try to reconsider the API. I have some suggestions below, but the processing time will take longer.
I just had a similar problem on a different web application, and here is what worked for me:
Look up the tree structure of the HTML from the target element. There is usually a nearby element that you are able to match on unique attribute(s), often Web text in combination with one or two others. Let's call this the label element. Compare the Web path of this label element with the Web path of the target element. If one element is dependent on the other, there will be a pattern.
When the page loads, you can read the path of the label element and use it to calculate the path of the target element based on the pattern you observed. Use the new path to dynamically match on the target element (Test to make sure the pattern is correct and consistent). Here is a mockup of what that could look like:
Another suggestion is to take a closer look at the URL structure. What looks like a random string can sometimes be a unique/persistent identifier that can be useful. Part of your Salesforce URL is probably the unique ID for that record, for example.
------------------------------
Patrick Aucoin
Senior Product Consultant
Blue Prism
------------------------------
First I want to echo my colleague Sam's reply and advise you to try to reconsider the API. I have some suggestions below, but the processing time will take longer.
I just had a similar problem on a different web application, and here is what worked for me:
Look up the tree structure of the HTML from the target element. There is usually a nearby element that you are able to match on unique attribute(s), often Web text in combination with one or two others. Let's call this the label element. Compare the Web path of this label element with the Web path of the target element. If one element is dependent on the other, there will be a pattern.
When the page loads, you can read the path of the label element and use it to calculate the path of the target element based on the pattern you observed. Use the new path to dynamically match on the target element (Test to make sure the pattern is correct and consistent). Here is a mockup of what that could look like:
Another suggestion is to take a closer look at the URL structure. What looks like a random string can sometimes be a unique/persistent identifier that can be useful. Part of your Salesforce URL is probably the unique ID for that record, for example.
------------------------------
Patrick Aucoin
Senior Product Consultant
Blue Prism
------------------------------
Hi @Sam Assaf
I realise your post was quite a while ago, but perhaps you or others will get value from this in the future.
I completely agree that the API approach is the way to go, but in the event that the real world intervenes and you're forced to use traditional spying, this is what worked for me. BTW, I'm using the Lightning interface - I guess you are too - so I've no idea if this works for SF Classic too.
It seems that issue with Lightning is that every time you click on a different object (eg: from Account #1 to Account #2 to Account #3) it appends the new view to the original DOM. Presumably, this is so that it can quickly navigate back-and-forth between the various objects that you've selected. For BP robots though, it means that the field you're trying to spy/retrieve is never at the same path in the DOM. Nightmare!
You can see this from the screenshot below. This is the XPATH to the same field in three different accounts. The only difference is line 14.
Hence we end up creating dynamic paths, looking up parent URLs, modifying that offending <DIV>, and stuff like that which becomes completely unwieldy.
The solution that's worked for me is to refresh the browser each time you go to a new SF screen. The browser refresh resets the DOM and therefore the Line 14 DIV is always #1 and the XPATH to the field is always consistent.
So, at design-time, I goto a page, I refresh the page, I spy the page controls; at run-time, I goto a page, I refresh the page, I read the page controls. Something like this:
I'm only writing my objects now (I discovered this thread 'cause I was tearing my hair out) so perhaps some other problem will crop up, but thus far this approach is working for me.
------------------------------
Dan Ternes
CTO APJ
Blue Prism
Asia/Hong_Kong
------------------------------
I realise your post was quite a while ago, but perhaps you or others will get value from this in the future.
I completely agree that the API approach is the way to go, but in the event that the real world intervenes and you're forced to use traditional spying, this is what worked for me. BTW, I'm using the Lightning interface - I guess you are too - so I've no idea if this works for SF Classic too.
It seems that issue with Lightning is that every time you click on a different object (eg: from Account #1 to Account #2 to Account #3) it appends the new view to the original DOM. Presumably, this is so that it can quickly navigate back-and-forth between the various objects that you've selected. For BP robots though, it means that the field you're trying to spy/retrieve is never at the same path in the DOM. Nightmare!
You can see this from the screenshot below. This is the XPATH to the same field in three different accounts. The only difference is line 14.
Hence we end up creating dynamic paths, looking up parent URLs, modifying that offending <DIV>, and stuff like that which becomes completely unwieldy.
The solution that's worked for me is to refresh the browser each time you go to a new SF screen. The browser refresh resets the DOM and therefore the Line 14 DIV is always #1 and the XPATH to the field is always consistent.
So, at design-time, I goto a page, I refresh the page, I spy the page controls; at run-time, I goto a page, I refresh the page, I read the page controls. Something like this:
I'm only writing my objects now (I discovered this thread 'cause I was tearing my hair out) so perhaps some other problem will crop up, but thus far this approach is working for me.
------------------------------
Dan Ternes
CTO APJ
Blue Prism
Asia/Hong_Kong
------------------------------
