Lost Boys Thinking

Several blogs on BizTalk that I have read recently state that the BizTalk mapper is a top-down mapper. A top-down mapper starts processing at the first node and progresses downward, node-by-node, through the output schema. Stating that the BizTalk mapper is a top-down mapper is misleading because that is not technically accurate. Lets look at some examples.

 

 

First we build a simple schema that we will use in the map. As you can see in the picture the schema consists of a root node,one record node, and two child elements in the record. We then attach an Uppercase functoid to the record and both elements. The first Uppercase functoid contains the value "1", the second the value "2", and the third the value "3". We turn off output validation for the map so that we can output text in the record node Parent.

When we run the map the output appears as seen here:

 

 

Notice that the value "1" appears after the values "2" and "3" in the output. This is the method of outputting values in a record, so the fact that the "1" appears in the output after the "2" and "3" values doesn't indicate that the execution order was anything other than "Parent", "ChildOne", "ChildTwo".

 

 

We add one node to the schema (Globals) to get us a place to attach a script that defines a global integer and sets the value to zero. Here is the code in that scriptoid.

 

int counter = 0;
public void Globals ()

{}

We use an Equals functoid with the second value set to "false" to block the output of the Globals node. Since the scriptoid attached to the Equals functoid outputs no value, the Globals node will not be output.

The scriptoid attached to the node Parent contains this script:

public int incCounter ()
{
return ++counter;
}

The script increments the counter and outputs the new value to the node Parent. Since the counter was initialized to zero, we expect the value to be output here to be "1".

Two more scriptoids are attached to the nodes ChildOne and ChildTwo. Both contain the code:

public int retCounter ()
{
return counter;
}

Since the counter was incremented in the scriptoid attached to the node Parent, we expect the value output in both these nodes to be "1" as well. Here is the output of the map:

 

 

Oops. This is not what we expected. Both child nodes contain the value "0", which is the initialized value of the variable. The record node outputs the value "1" indicating that the scriptoid attached to the node Parent did work. This is a clear indication that the code attached to the record node did not execute until after the code in the child nodes.

But.... Not all aspects of the record are executed after the children. Here is another map, identical to the last one except that we've added an Equals functoid (values "1" and "2") that will always return "false", thus blocking the output of the record Parent.

 

 

 

The output of this map is:

 

 

Now the record Parent and all of the children of Parent have been blocked. In this map the Equals functoid must have been executed before the Parent node or the child nodes.

Bottom Line:

As a rule, links to child nodes are executed before connections to their parent nodes. An exception to that rule is that connections which control the output of a parent node are executed before connections to the child nodes.