Dont use Xsl For-Each with InsertAndUpdateNodes - Alternatives

[CathyC]

I came across this example when working with another developer and wanted to outline this to explain why you would never use a service level xsl for each with the InsertAndUpdateNodes service

all services have this button to turn the for-each on at the service level. showing in an insertandupdatenodes service.

insertandupdatenodes icon.png (14.53 KiB) Viewed 1226 times

all services have this button to turn the for-each on at the service level. showing in an insertandupdatenodes service.

insertandupdatenodes icon.png (14.53 KiB) Viewed 1226 times

First of all an explanation of Insert And Update Nodes.

This accepts a parent node path, which is the repeating node. So if there is an inquire, the result is the repeating node, so we put WorkData/Inquire/Output/Result as the node path.
It then iterates through all the child nodes and does something (adds some property to the child node or changes something)

So an example of this is a shopping cart with items. If I am iterating through the items in the shopping cart, for each Item I could edit a property of it (like quantity) or add a new property (like a valid flag when performing some check).

Here is a drawing showing how insert and update nodes works for an inquire with 5 results

But this is something we are familiar with. This is what a xsl:for-each does.
We know that when we're within one xsl for each, if we have an xsl:value-of within it, it is a continuation of the path. So for example:

Code: Select all

<xsl:for-each select="WorkData/Inquire/Output/Result"/>
    <xsl:value-of select="WorkData/Inquire/Output/Result/ItemNumber"/>
</xsl:foreach>

Here that inquire is actually referencing:
WorkData/Inquire/Output/Result/WorkData/Inquire/Output/Result/ItemNumber

Which we know doesnt exist.
So

Code: Select all

<xsl:for-each select="WorkData/Inquire/Output/Result"/>
    <xsl:value-of select="ItemNumber"/>
</xsl:foreach>

This is referencing WorkData/Inquire/Output/Result/ItemNumber of the current Result we are iterating through.

To exit the for-each loop, we would need to add a slash in front of the workdata:

Code: Select all

<xsl:for-each select="WorkData/Inquire/Output/Result"/>
    <xsl:value-of select="/WorkData/SomeOtherService/Output/Result/VariableToUse"/>
</xsl:foreach>

IMPORTANT: So in thinking about InsertAndUpdate Nodes, it becomes obvious that this service is doing an xsl for-each behind the scenes. So if we want to reference things within the service, we also need to use these rules of continuing or exiting the xpath specified in the for each
FEATURE SUGGESTION: when viewing a service, at the service level, it should show in the xml viewer that it actually is placing it in an xsl for each xml

So if we continue and turn on the xsl:for-each for the InsertAndUpdateNodes, we are saying we will do this process multiple times - once for each node in some other parent we are looking. So if we look at the diagram again, it becomes something like this

Now, for each Result of AnotherInquire, we are going to run the entire InsertAndUpdateNodes, which itself is running a foreach.

The first difficult is that we might need to put a slash in front of the parent node in the InsertAndUpdateNodes so we can say "I am leaving the loop, I want to start this xpath at workdata again". But this is possible if you wanted to, so its not a big deal, just something extra to think about.

Then you want to think about why you would want to do this. The most common way I have seen this set up is when a developer has two sets of data and wants to give information from one to the other

Merge Use Case.png (11.44 KiB) Viewed 1226 times

Merge Use Case.png (11.44 KiB) Viewed 1226 times

But this is actually the perfect use case for Merge services.
Merge will give all the child nodes from the result on the right side to the left side once they are matched up.
MergeTargetedNodes will ask the developer to specify what child node you want to give from the right to the left once they are matched up

And if you wanted to use the InsertAndUpdateNodes service still, you could use an xsl:variable to help you. See below an example where we used an InsertAndUpdateNodes like a MergeTargetedNodes:

[CathyC]

But lets say you actually wanted to use InsertAndUpdateNodes in a for each to accomplish this:

Code: Select all

<xsl:for-each select="WorkData/AnotherInquire/Output/Result"/>
	<xsl:for-each select="/WorkData/Inquire/Output/Result"/>
    		<xsl:value-of select="ItemNumber"/>
	</xsl:foreach>
</xsl:foreach>

You could do it.. but there wouldnt be any reason too unless you could do something like this:

Code: Select all

<xsl:for-each select="WorkData/ApprovedBranchPlants/Output/Result"/>
	<xsl:variable name="BP" select="BranchPlant" />
	<xsl:for-each select="/WorkData/ItemsReturned/Output/Result[BranchPlant=$BP]"/>
    		<ItemToDoSomethingWith><xsl:value-of select="ItemNumber"/></ItemToDoSomethingWith>
	</xsl:foreach>
</xsl:foreach>

which basically says "look at AnotherInquire, grab some value and do something with it in that array over there"
In the above the first query is returning the approved branchplants list, then for each of those you are checking the itemsreturned list and saying to print it out if they have a good bp. the end result will be items that you are approved to use.

Conclusion: but the point is that with the service level for each, there is no room to add a variable. I dont think there is anything valuable you could do with that outer for-each (adding a for-each to a insertandupdatenodes)

[CathyC]

and thinking about this more..
there is no reason to have a binary decision in a service level xsl for each loop.

Because the binary asks a question and returns an output. But its that output on the canvas (going to Yes or No) that is valuable.

Since there is only one answer, there should be only one question. If we ask more questions, the answer becomes useless as it is less obvious which question it is the answer to

with some thinking you could figure this out:

if it was set to overwrite itself, then the last one that ran is the only one in the logs and its the answer to that one
If it wasnt, then xpath is always taking the first it encounters, so its the answer to the first one


it requires that thinking though to arrive at the conclusion: its a silly thing to do because the other questions took processing time (although very tiny) and served no purpose

[CathyC]

I talked about this with a few other developers. Steve and Jeff brought up that any service that accepts a node path isnt going to work with the service level for each. This excludes probably all of the node workshop