I recently had a bit of time to figure out answers to some questions about how BizTalk handles promoted values in
batches. Specifically, do promoted values from the “envelope” transfer to the “body”, and what if you want to interact with those
values from an orchestration? I’ll also show how to add the flat file header content to each debatched outbound message.

First step was to build working samples of both XML and flat-file debatching. Setting up an XML debatching scenario is fairly simple.
First you build the “body” schema. Then you construct an Envelope schema. This is done by (a) marking the schema-level property called
Envelope to true and (b) setting the Body XPath property of the root node to the XML element you wish to rip apart.

Now, I’ve demonstrated before that if you map fields in the header and body to the same Property Schema field, then the value in the header
gets demoted down to each debatched message. However, what if you don’t want to have a field set aside in the message body to hold
header content values? So, I created a property schema and promoted two of the nodes from the header portion of the XML document. After
deploying the solution, and feeding a batched up message into BizTalk, each message got debatched, AND, the promoted fields got copied
down to each message. The documentation states this, but I had to see it.

Next, I wanted to see how it behaved with flat files. Given that we handle flat file debatching differently, I wanted to see if the
promoted property behavior was the same. So, I used the Flat File Wizard to generate both a header and body schema. The debatching key
in the body schema is to flip the repeating batch field element to Max Occurs equals 1.

Finally, I created the necessary receive pipeline to disassemble the flat file input. I pointed the Document Schema and Header
to the previously created flat file schemas. Also, I flipped the Preserve Header flag to true. This crams the
header message into the context of each debatched message.

When I redeploy the solution (now with flat file schemas) and add new receive/send ports, drop the flat file in, I can see the header
message sitting in the FlatFileHeader context value. You could use this data however you want. But, what if we want behavior
just like the XML debatching example above? Specifically, distinct promoted values from the header? So, I went back and promoted the
values in the flat file header schema. After redeployment, I can go back and see that indeed, I have not only the whole header in a single
context field, BUT each promoted value is isolated as well.

Now that I’ve gotten this far, I can demonstrate adding the flat file header BACK to each outbound message. It’s easy. Simply create
a send pipeline with a flat file assembler component, and again choose the Document Schema AND add the Header Schema. What
this does is take that header blob out of context and reapplies it to the outbound message automagically.

My last question was how do interject an orchestration into the mix. Clearly we are working with promoted fields that don’t exist
in the individual message. They’ve been snagged from the parent. So by default, you can’t access these promoted values from within
an orchestration. However, if you go to your property schema, and click on a given element, you’ll see a field called Property
Schema Base
. This setting determines where BizTalk looks for the data in a promoted property. I flipped my value to
MessageContextPropertyBase which means that the value will be looked for in context, not the message itself. After I change
this flag, I can now see the property field in my orchestration.

What I wasn’t sure of was how this solution would behave now. By flipping the value to MessageContextPropertyBase would I screw
up the pipeline when it writes to context? I didn’t think so, but wasn’t 100% sure of what this would do. So, after dropping my XML
batch message in, I checked the context of the message after it has passed through the orchestration (which changed the promoted property
value to something else). Sure enough, the value in the outbound message was changed successfully.

Cool stuff. It would be easy then to change the promoted values inherited from the parent, and then send the message directly back
to the MessageBox for additional content-based processing. So there you go, all sorts of fun with BizTalk batches.

Technorati Tags: BizTalk