Promoting reoccurring elements – Part II

by | Apr 13, 2009 | BizTalk Community Blogs via Syndication

Hi all

I had a post about promoting
reoccurring elements in BizTalk. As we all know, this isn’t possible. BUT actually
well 🙂

Basically, you promote properties for three reasons:

  1. You need it to route based on the value
  2. You need it for correlation (which is basically just a specialization of routing)
  3. You need to either read or set the value inside an orchestration (Don’t do that! Use
    distinguished fields instead)

So, dealing with number 1, routing, I started thinking back at BizTalk 2002, which
was my first BizTalk experience (I’l bet ALL BizTalk developers/architects think of
BizTalk 2000/2002 every now and then no? 🙂 ). I seemed to recall that you could
do something fancy with routing back then, so I fired up an old BizTalk 2002 on windows
2000 Professional to test it. It turns out, that on a channel you can enter a filter
which is an XPath expression. The text field is editable, so you can change the XPath
expression all you want – it will complain if you try to leave it with an invalid
XPath expression (syntactically – not semantically).

Given this XML:

<MyRoot>

  <myReoccuringRecord Myfield="42" /> 

  <myReoccuringRecord Myfield="2" />

  <MySecondRecord MySecondField="jan" /> 

  <MyThirdRecord>

    <MyThirdField>1</MyThirdField> 

  </MyThirdRecord>

</MyRoot>

I can have a channel with this filter:

  • /*[local-name()=’MyRoot’ and namespace-uri()=”]/*[local-name()=’myReoccuringRecord’
    and namespace-uri()=”][position()=1 and @Myfield = 42]

Basically, documents will only go through this channel, if the value of the “Myfield”
attribute of the first “myReoccuringRecord” element has the value 42.

So, it isn’t promoting as such – BizTalk 2002 doesn’t have this concept, but it
allows us to route based on the value of a specific occurrence  of a reoccurring
element.

On a side note; If you leave the filter like this:

  • /*[local-name()=’MyRoot’ and namespace-uri()=”]/*[local-name()=’myReoccuringRecord’
    and namespace-uri()=”][@Myfield = 42]

it will accept the incoming document no matter what the position of the “myReoccuringReord”
is. Can’t make up my mind if this is a good thing or not 🙂

Now, as we all know (?), manually editing the XSD in BizTalk 2006 solution to make
sure the XPath evaluation will only return a single XmlNode doesn’t work. You either
get a compile time error:

  • The promoted property field or one of its parents has Max Occurs greater than 1. Only
    nodes that are guaranteed to be unique can be promoted as property fields.

or you get a runtime error:

  • There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive,
    Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
    Source: "XML disassembler" Receive Port: "ReceivePort3" URI: "C:\Projects\Blog
    Entries\PrommotingReoccurringElementsEditXSD\Instances\In\*.xml" Reason: Unexpected
    XPath format:

Anyway not that many BizTalk 2000/2002 installations till in production, I assume,
so this post is merely for informational purposes. It’s just funny discovering functionality
that is doable in earlier versions of BizTalk and not in the latest versions.

—

eliasen