I recently had to do a BAM solution where the very limited functionality of TPE (Tracking Profile Editor) wasn’t enough.
The actual problem concerned EDI but for the simplicity of things, I’ve created a simpler XML example, but with the same principles.
The problem:
I receive XML (orders) from trading partners and needs to create a BAM activity for each order. An example:
<ns0:Order xmlns:ns0="http://xemmel.com">
<OrderID>22</OrderID>
<NAD>
<Type>BY</Type>
<Identifier>12</Identifier>
<Address>Beech Street</Address>
</NAD>
<NAD>
<Type>SE</Type>
<Identifier>665533</Identifier>
<Address>Oak Street</Address>
</NAD>
<NAD>
<Type>IV</Type>
<Identifier>1</Identifier>
<Address>Maple Street</Address>
</NAD>
</ns0:Order>
One of the fields (SellerIdentifier) is extracted from the Identifier element inside a “NAD” record, where Type = ‘SE’, and I cannot be sure that trading partners sends the NAD records in the same order.
The observations
This cannot be done out of the box with TPE. If I simply drag the Identifier element onto the SellerIdentifer column in my activity, the following will happen:
The XPath inside the .btt file will be:
/*[local-name()='Order' and namespace-uri()='http://xemmel.com']/*[local-name()='NAD' and namespace-uri()='']/*[local-name()='Identifier' and namespace-uri()='']
This of course is somewhat inconclusive since that will return, in this example, three nodes. So what happens if this TPE is deployed? Well actually that depends on whether it is deployed in the receive pipeline or in an orchestration!
In a pipeline:
No errors and the last Identifier (“1”) is inserted into the activity.
In an orchestration:
BizTalk processed the flow like it is supposed to, but no BAM is inserted and the following error appears in the event viewer:
The result set for the XPath expression '/*[local-name()='Order' and namespace-uri()='http://xemmel.com']/*[local-name()='NAD' and namespace-uri()='']/*[local-name()='Identifier' and namespace-uri()='']' contains more than a single node.
Well fair enough but why didn’t the Pipeline interceptor react the same way? (I don’t know yet)
The solution
So it seems that I could perhaps fix this by doing my own custom XPath inside the .btt file, and as we shall see, I actually can do that (but only when using the Orchestration interceptor!).
I opened the .btt file manually and replaced the XPath attribute (Not the SomXPath attribute, although it would probably be good practice to change that as well) with the following:
/*[local-name()='Order' and namespace-uri()='http://xemmel.com']/*[local-name()='NAD' and namespace-uri()=''][*[local-name()='Type' and namespace-uri()='']='SE']/*[local-name()='Identifier' and namespace-uri()='']
So all I did was insert a condition “[*[local-name()='Type' and namespace-uri()='']='SE']”.
I redeploy and when using the Orchestration interceptor it works.
With the pipeline however I get the following error:
Unexpected XPath format: "/*[local-name()='Order' and namespace-uri()='http://xemmel.com']/*[local-name()='NAD' and namespace-uri()=''][*[local-name()='Type' and namespace-uri()='']='SE']/*[local-name()='Identifier' and namespace-uri()='']"
What is worse is that, in this case, BizTalk actually suspends the messages!! I thought that BAM should be an independent piece of machinery that could be placed on top of an existing BizTalk solution without impacting it (even if BAM contained errors). But that is obviously not always the case.
The conclusion
One thing I can conclude is the that the pipeline and the orchestration interceptors do not work identical. Why I don’t know yet, but it probably has to do with them using different event streams.
Is it a good idea to use custom XPath inside your .btt file then, well it depends I would say.
In my solution it was the only way to extract the information I needed, since changing the existing solution was not an option, and everything seems to work. But the fact that it only works in orchestrations is of course a heavy limitation, since many solutions are purely based on content based routing.
Hi everyone
And welcome to my small BizTalk corner of the Internet.
My name is Morten la Cour, I work as a BizTalk specialist at Logica Denmark.
In my 4 years as a BizTalk architect/developer, I have come to admire the product, its possibilities, flexibility, scalability and incredible robustness.
Through this work I have gathered several features, work-arounds, issues, faults/errors/"MS features" that I would like to share with the rest of the BizTalk community.
I will start posting articles on this blog soon.
/Morten