BizTalk: How To: FlatFile Batching and Promoted Properties

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 Schema 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 toMessageContextPropertyBase 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 toMessageContextPropertyBase 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.

post by Richard Seroter