Developer

Utilizing XML documents in BizTalk 2004 orchestrations

The uses of xPath and other XML data-handling techniques are a little different in BTS2K4 orchestrations. Here's an overview of the rules.

BizTalk Server 2004 makes its very strong bid for mid-range ERP platform legitimacy largely on the basis of ingenious leveraging of XML technology. The implementation of XML transport as the BTS2K4 workhorse is elegant and efficient; its utilization in pipelines is robust and the schema mapping software is convenient. What more could we want?

Well, for one thing, we could want XML data-handling to function the same way within a BizTalk orchestration as it does in the rest of the world. The rules are different, just enough so to be maddening! There's reason for this—it has to do with reserved words in XLANG—but you'll pull out most of your hair if you try to move data in and out of XML documents in an orchestration the same old way you always have.

You'd expect xPath to be your friend in this undertaking, and it will be. But there are some guidelines to note.

When even the canned code fizzles

My first difficulties with the XML document in a BTS2K4 orchestration took me very much by surprise. I had no reason to think xPath or anything else I might need would function differently than I might expect. I was especially caught off-guard because the expressions I was using operated on canned Microsoft components; nothing in the expressions was home-grown! I was using the HL7 Accelerator package, which includes *.xsd templates for ADT messages. Populating an instance of such a document was a breeze, and I imported the result into an orchestration message with no problem. But when I tried to pull data out of the XML-typed message with xPath, nothing worked. No syntax seemed to do the trick.

Here's where it got weird: I gave up trying my own variations on the xPath and pulled the Instance Path for the element node I was trying to access out of that node's properties. At that point I was trying to pull data (a Last Name field) from a canned schema (an ADT A08 message, part of the MS BizTalk HL7 Accelerator package), using the instance path provided via the Properties window in Visual Studio (there's a similar example below) - and it still wasn't syntactically adequate.

What xPath wants

Implementations of xPath expressions in BTS orchestrations seem to be most problematic where namespaces are concerned. The expression in Listing A is similar to the example mentioned earlier: the instance path of the element node in the XML document carrying the desired data is provided via the node's properties in VS.NET, and the expression will compile properly—but you'll get an exception when you run it. BizTalk will see the parent node but not the child node.

You'd think with that level of namespace detail, this path would work for xPath (it will work outside of a BizTalk orchestration in many cases). Here's the structure upon which the XML document is based (the document is an instance of that schema):

SampleSchema

     invoices

               invoicedetail

                         businessname

Listing B shows you a version of the expression that will work.

Digging deeper

Here's another example that goes deeper into the XML document. The schema upon which the XML document is based is more detailed:

SampleSchema

     invoices

               invoicedetail

                         businessname

                         invoicedate

                         invoiceitem

                                   prodnumber

                                   price

                                   quantityordered

Pulling data out of child element nodes in the structure above would work like the expression in Listing C.

When all else fails

Mac McGruder, a senior developer at Homecare Homebase, solved the same problem this way. In the particular case he was addressing, problems in xPath resulted from multiple instances of the child element name in the schema. This solution assumes that you have the names of the element nodes that are your data-bearing targets, and the names of their parent nodes as well:

  1. Create a method in the DLL that defines your receiving fields; this method will execute a field-specific drill-down into the XML.
  2. In the drill-down, locate the parent node.
  3. From there, grab the child node; that is, drill down in two statements, not one!

Specifically, you want to search the parent node for a node list and use that list to isolate the child node. In .NET, you can do this with an XPathDoc, or an XMLDocument (a subclass of XPathDocument). What you're shooting for is to have NodeList returned. (Thanks to Mac for this solution!)

About Scott Robinson

Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...

Editor's Picks

Free Newsletters, In your Inbox