.debug

One of the really cool features about BizTalk 2002 was the way “filters” were implemented; BT2002 uses the good ol’ XPaths to implement filters, i.e.–if you want a certain “channel” (BT2002 speak for ”ports”) to filter out messages, the message should “match” the XPath.  For example, if you want the channel to only accept messages whose 3rd ‘node1′ child’s ‘attr1′ attribute equals ‘FTW’, you will define the filter as:

//node1[3]/@attr1=’FTW’

Cool, isn’t it?  Well, it’s not all bed of roses here…thing is, since the filter is implemented this way, you can only filter via the XML nodes of the message. 

With BT2004/BT2006 that changed, of course.  You filter through what we call as “promoted properties” which doesn’t have to represent an XML node of the message.  However, the dumbass who designed BizTalk filters also took away the neat-o BT2002 feature to be able to filter via XPaths!  DAMN.  Now if you want to filter out messages using the notation shown previously, the Schema should have that particular node defined as a “promoted property” which has a number of limitations in its own…like, um, you know, that NODE has to be non-repeating/unique. 

Holy crap, we’ve came across a number of situations where we WISHED we still have the BT2002′s means of filtering, because you have no idea how frustrating it is to define filters without XPaths.

You’re probably thinking “What’s the point of this post?”  Well, I’ve been toying around an idea to be able to filter via XPaths…and I think it would work.  I will update this blog within the next few days if it pans out or not.