1 of 1 people found this helpful
1 of 1 people found this helpful
So a quick solution is //line[@index="5"]/text() which basically means
1) search through every element in the XML document
2) when you find an element whose name is line check to see if it has an attribute called index whose value is equal to "5"
3) Pull the text value of this element using the text() function, otherwise you will get the value wrapped in <line> tags.
So for all customers and partners out there the above is a very lazy way to do things. Its the sort of thing that we do in Sales on POC's for temporary non-production code.
Because it is inefficient, you are going to look at every element in the XML document and make the BAO engine check to see if the element name is called line. If you like buying more BAO Peer licenses please continue to use the fist syntax above.
For production code you should always try and fully path as much as possible the element/document level you are going after, thus we get:
In the second example you have just made your variable assignment operation approx 10 to 15 x more efficient by specifying a full path.
10x to 15x more efficient -- that's some interesting numbers you throw out there. I am sure there is some efficiency involved in doing it your way; but I would think the XML parser would still have to parse through the complete XML structure to get those branches. If you have any actual metrics on this, I would love to see it.
I can definitely see how you could get some increased efficiency by specifying an extended path, but I too would have to question 10x on a return value so small...wouldn't your XML response need to be many hundreds of lines long to see any real gain from narrowing your search?
You and Richard had to go do it, and call my bluff .
OK so I did a very scientific deployed process test involving 30 runs of 1000 iterations on a Control, the lazy path'd XPATH, and the fully path'd XPATH transforms
The control transform passed in the sample XML you provided Tony and issued the XPATH statement of "1". (as in go to the trouble of setting up an XPATH with the input document but just return the string value of 1.
The results are that the lazy transform will run almost twice as slow as a fully pathed transform given the sample document you provided (the fully pathed transform ran in 54% of the time as the lazy method).
This ratio could obviously get better or worse based on the specific lazy XPATH statement being used and the size (# elements) of the source document being evaluated.
This is a real world BAO result which falls short of my original ratio . I would still argue however that doing it right will get a customer more bang for the buck from a Peer performance perspective.
Hey, I really appreciate you taking the time to run some actual performance tests. Even though (by your own admission) the results fall short of your estimates, I am still surprised there is almost a 2:1 ratio. Amazing.
I do agree that striving to make it as efficient as possible is definitely the right way to go, but I think it is a naturally evolving process. Someone new to the product -- especially if he/she is new to XML -- will probably go the easy route to get an immediate ROI. However, as he/she progresses and becomes more comfortable with the product and/or XML, the transformations will shift towards more efficient (and sometimes complex) transformations.
This of course is what makes this product so great. There is something for everyone. :-) I am actually rewriting a lot of my workflows and incorporating "lessons learned", which amongst many things includes better transformations.
Talking about improvements; let me run something by you. I used to do a fair amount of logic with switches, however I have recently started to shift to if/else like functionality within XSLT transformations. I assume this is much more efficient? What is your take on that?
I personally use lee switch statements. I have less icons on my workflow and be much faster via xslt. Unfortunatley, not everyone will understand what's going on until the look at the xslt. So for documentation and teaching purposes, the switch statement helps much more ... after all, one picture = 1000 words.