Putting together BizTalk integration solutions can be complex and tricky at times. Debugging them is an art in itself. While onsite recently, I found myself (on more than one occasion) having *words* with BizTalk.

One example that tested our relationship (BizTalk and I) was an orchestration decision shape that appeared to be misbehaving. I had three branches in the decision shape, each branch testing the existence of a node in the message being processed using the xpath() function. For Example:

xpath(msgRequest, "string(count(/*[local-name()='root']/*[local-name()='parent']/*[local-name()='child' and code='some value']))") == "0"

Tip: use Dan Sharp's Xml Viewer to retrieve the correct xpath to use in these statements. BizTalk schemas will give you them to, but Dan's tool has some nice features thrown into the bargain

One branch rule tested for a zero node count, another for exactly one, and the Else rule branch to handle multiple occurrences of the node. During testing and debugging we found the else branch was always being used despite the messages satisfying one of the other rule conditions (over different tests). Repeated checks, breakpoints, and logging soaked up 20 minutes or more and had me demanding satisfaction by challenging BizTalk to a duel with pistols at dawn.

It was then, a bright beam of light breached the false ceiling above me and shone down in all is splendour. No, this was not a helping hand from god, but rather from a colleague working with me. Picking up on my frustrations, he calmly stood, moved over to me, and placing a soothing hand on my shoulder, utters two words that have changed my life...Kane Theory. I eagerly implemented a quick change (as guided by Kane Theory teachings) and my problem was solved! More cases arose during the project and each of them resolved with ease using this mystic and elegant theory.

Ok. That's a bit dramatic, but I am considering a professional self-help book exploring the practical uses of Kane Theory and wanted to get some practice in.

So what is Kane Theory?

Although only a novice in its teachings, I am fortunate to receive guidance from the enlighten one himself. Kane Adams (his real name used here to protect reveal his identity)  explains it in terms of Yin & Yang, Karma, and the Force. Reflecting on this I can best describe it as a derivative of keep it simple stupid (KISS).

In the example above, we declared an orchestration variable (System.String) to store the result of the xpath function in an Expression shape before entering the Decision shape. We then used the variable in the rule expression for the comparison. Eg:

strNodeCount == "0"

By powers understood only to the enlighten one, this worked a treat and we could all break for a quick cup of the worst coffee ever brewed. (Sceptics might argue that it has to do with the way the XLANG engine performs explicit type conversions during the comparison operation...but they would say that wouldn't they!)

As for the enlighten one himself:

Some say he is a direct descent of John Adams, author of the mystical theory of political architecture and founding father of the new Empire (there's the link to the Force we needed).
Some say, he meditates to the haunting chants of mid-level public servants.
We know him as The Stig!