Those long xpaths…

Tired of havng incredibly long xpath statements when using the “xpath” keyword in
your orchestration expression shapes?  (They are generally long because of the
xml namespace issues, unless your documents do not use namespaces.  When namespaces
are in play, “local-name()” tends to overwhelm your actual path content.)

For BizTalk 2006, we can take advantage of the fact that System.Xml 2.0 added the
ability for documents to supply namespace mappings themselves when doing xpath work
– without the need for manually populating and using a XmlNamespaceManager instance,
as was the case for .Net 1.x.  Note that XPathNavigator now (as of .net 2.0)
has a SelectSingleNode method which can accept an implementation of the new IXmlNamespaceManager
interface (which XPathNavigator itself implements.) This means that the ‘xmlns:someprefix=someuri’
declarations in your instance document can actually be used automatically, such that
your xpaths can use the same prefixes when issuing a select. .Net 1.x had no such
mechanism.

So, in whatever “utility” class you have sitting around to help you out when doing
orchestration work, add the following static method.  (I generally put such things
outside of a namespace – that way they are a bit more concise inside the orchestration
expression editor.) In high-performance scenarios, may want to measure the performance
of this approach vs. the built-in xpath keyword.  Recall that messages can be
passed as XmlDocument instances, so your expression window might have: myString =
XmlUtility.GetXPathStringResult(myMessage,”/spf:someparent/spf:somechild”);

public static string GetXPathStringResult(
    XmlDocument document,
    string xpath)
{
    XPathNavigator nav = document.CreateNavigator();

    // (so namespace mappings are in scope when we select)
    nav.MoveToChild(XPathNodeType.Element); 

    XPathNavigator node = nav.SelectSingleNode(xpath, nav);

    return node.Value;
}