13-11-23 12:37 PM
Having recently upgraded to 7.2, I've noticed extreme slowness when trying to read an HTML element that is not actually there.
Process is looking to read a dynamic element, using a specific path that is fed as an input parameter to the read stage (using a loop counter to update the dynamic path). When the element is present, no problem. When the element is not present, it's taking 6-10 seconds to throw an exception.
Previous versions of BP were pretty much instantaneous for this, given it's looking for a specific path...
Any suggestions on how to speed this back up again?
14-11-23 08:18 AM
Hi Rob - are you using other attributes as well as Path. Try using Path only.
I've also found using an Xpath expression (eg something like //input[@id='FirstName']
) can perform better than a normal path. Xpath takes a bit of getting used to but there is plenty of material (eg https://www.w3schools.com/xml/xpath_intro.asp) and it's well worth learning the basics. Xpath can do things that are not possible with standard BP attribute selection, such as travelling up and across the HTML structure.
14-11-23 01:57 PM
Thanks John - To clarify a bit, I'm using Path only as the matching parameter for the element. The issue isn't that it's slow to identify elements when they're present, but it's very slow to throw an exception when that element is not present. Not sure if there's somewhere this timeout can be configured in a similar way to a wait stage? If so, I'd guess it's somewhere in one of the environment config settings maybe?
14-11-23 03:30 PM
Hmm that's odd then. As you know, Path is an exact 'address' for an element, so there should be no searching - it's either there or it isn't. Match Index shouldn't make any difference for the same reason. Are there wildcards involved?
Maybe try raising a ticket to see if Support can suggest something.