Hi there. Winter is coming, just not today. Because today it's raining cats, dogs and gators; High Florida season is on his way and I have time for the another little trinket. It's based on the same data types we have played around with
apples and oranges. It's not exactly related. but I've reused XML Schema to show you a little side effect of the XPath selector. You have run into that if you use strict type validation for each and every activity in your process, but I bet you don't. It's pretty normal to validate data on the edges, in the BPEL case - check the service input and make sure that you produce the response, that composite's clients expect to have.
This minimalistic composite has only a few steps, but can simulate behavior we need:
- Check Incoming XML document (using partner link property)
- Perform XPath query by attribute value
- Validate output variable
- Return response
The one truly interesting activity here is the assign SetResponse. Let's take a look into source code:
<assign name="SetResponse">
<copy>
<from>
<literal>
<GroceryList xmlns="http://mmikhail.com/sample/xml/Orchard">
<Item Name="Apples" Type="bushel">1</Item>
<Item NMame="Pears" Type="pound">4</Item>
</GroceryList>
</literal>
</from>
<to expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0">$VariableWitthAttributes</to>
</copy>
<copy>
<from>$VariableWitthAttributes/ns2:Item[@Name="Apples"]</from>
<to expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0">$outputVariable.payload/client:response</to>
</copy>
</assign>
Activity populates variable with the array of the element Item. You can select Item from the list either by index or by attribute name. That's exactly what the second copy does. It selects Item value with the attribute
Name equal to
"Apples". Nothing fancy so far, good old XPath expressions and assignments. The
CheckOutput activity validates output message against XML Schema. It's a string and we do not expect any traps here. Le'ts compile, deploy and test the process.
Ouch, validation failed with the error message:
<bpelFault>
<faultType>0</faultType>
<invalidVariables xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable">
<part name="summary">
<summary>Failed to validate bpel variable.
Validation of variable outputVariable failed.
The reason was: Attribute 'Name' not expected.
Please handle the exception in bpel.</summary>
</part>
</invalidVariables>
</bpelFault>
And if you check the assign activity you'll see that all element attributes have traversed to the target variable. I bet it's not exactly what you have expected to see, but you do and it's the same for 12c and 11g. The solution is quite simple, just slightly modify selector for instance:
<from>string($VariableWitthAttributes/ns2:Item[@Name="Apples"])</from>
Now composite works exactly as expected.
It looks like nothing, but think about it:
You have selected something by one attribute, but in fact, you have exposed not only this one but
all of them and they may contain some sensitive information, like dates, user names, entity IDs and so on.
Hope it will help you to build more reliable and secure applications. Good luck with that.
