Logical (Existence) functoid in BizTalk 2013

To explain the problem I will first show the (simplified) map used:

The logic is quite simple: if the node ‘Optional1’ equals ‘first’ the value mapper will map the node (after a logical existence) to the output document. Below is a sample of the input file used.

I know this is a strange place to use the ‘Logical Existence’ functoid and it would be better to have the result of the ‘Equals’ functoid as direct input for the ‘Value Mapper’-input. But this was the situation as I encountered it. And I only noticed it because one of the unit tests failed. Otherwise I would not have spotted this.

BizTalk 2010 behavior

In BizTalk 2010 the input file and map will give the following result:

So it seems like the logic for the second repeating node in the map is something like:

• ‘second’ is not equal to ‘first’ result of functoid = false
• Input to logical existence = false result of functoid is false
• Input to value mapper is ‘false’ so no output is produced.

The above logic results in the absence of the second ‘Optional1Direct’ node.

BizTalk 2013 behavior

In BizTalk 2013 the given input file and map will give the following result:

The logic for the second repeating node in the map is something like:

• ‘second’ is not equal to ‘first’ result of functoid = false
• Input to logical existence = false result of functoid is true
• Input to value mapper is ‘true’ so output is produced.

The logical existence functoid results in the following script (run validate map):

And it seems that this little function is affected by the different Boolean behavior as described here.

It doesn’t seem logical to attach a ‘Logical Existence’ to the output of another functoid (this would certainly be a remark during a review and really smells like bad practice). However in BizTalk2010 this would still produce expected results. In BizTalk 2013, because of the compiled transform, the result of maps can be different.

Takeaway 1, Use as intended!

If a ‘Logical Existence’ functoid is used as it is intended (and as stated by the help).

Use the Logical Existence functoid to return the value “true” if the input record or field exists in the source message. This functoid requires one input parameter only.

and the functoid is only linked to records or fields of the input document, the behavior is as expected. If linked to anything else, the results will be different. So when migrating a solution check your maps if the logical existence is used as it was intended in the first place.

Takeaway 2, Use Unit tests!

The difference was found because one of the unit tests included in the 2010 solution failed. This is not the first time we found a difference (or even issues) in BizTalk 2013 thanks to the unit tests of BizTalk 2010. Make sure you have several unit tests in your solution before you start a migration!

Takeaway 3, Inspect your scripting functoids on Booleans!

Any output from one of the logical functoids used as input in a scripting functoid will always give a true if it is passed in as a Boolean!. So make sure you check your maps for Boolean parameters in scripting functoids.