how Destination Schema properties will get promoted after Receive pipeline processing if we use Map??

Question

Hi Guys,

how Destination Schema properties will get promoted after Receive pipeline processing if we use Map??

Thanks in advance,

---

Chittidi

Answer 1

Since the mapping happens after the pipeline processing, all your properties will have been promoted by the time the XSLT map is executed.  If you need to promote after pipeline execution, you can do this in an orchestration.

---

David Downing... If this answers your question, please Mark as the Answer. If this post is helpful, please vote as helpful.

Answer 2

The mapper will only produce the destination structure with values and cannot promote them to the context. But if you have some fields in destination schema that are marked for property promotion, you have to do it in some other means.

Few options are:

• Pass the output through a pipeline that is capable of promoting it
• Invoke a custom .Net to promote the property
• Inside the orchestration like YourMessage(YourPropertySchema.YourProperty) = <The value>, if you are performing the transformation inside an orchestration.

---

Thanks, Murugesan M - Please Mark as the Answer, if this answers your question. Please vote as helpful, if this post is helpful.

Answer 3

This is not correct.

After a Map has been executed on a Receive Port BizTalk will run the destination XML though an XMLDisassembler Pipeline Component, so that any Promoted fields on the destination Schema will be promoted before the message enters the MessageBox.

Here is a Blog-post about some of the issues concerning this mechanism:

http://blog.eliasen.dk/2009/06/10/PromotingValuesFromDestinationSchemaOfMapOnReceivePort.aspx

Morten la Cour

Answer 4

To summarize laCour's point above; in this scenario, message properties may be promoted twice, once in the disasembler component (Flat file, XML, ...) and then again to promote destination schema properties after the mapping has happened. If destination properties overlap with the source properties the destination properties will persist in the message context, if they do not both sets of properties will flow in the message context.

---

David Downing... If this answers your question, please Mark as the Answer. If this post is helpful, please vote as helpful.

Answer 5

To summarize laCour's point above; in this scenario, message properties may be promoted twice, (...).

---

David Downing... If this answers your question, please Mark as the Answer. If this post is helpful, please vote as helpful.

 This interpretation is not entirely correct. Property promotion happens only once. But the properties associated with the destination schema are indeed promoted after the map has executed. This, although seemingly counter intuitive, makes sense when you understand how pipeline components are designed to work, in a streaming fashion.

I stumbled by chance on this fact and blogged also about this here.

Answer 6

As the message is being streamed, the disassembler is responsible for the property promotion (the flat file disassembler passes it's output XML stream to an internal XML disassembler to do the property promotions), each subsequent downstream component passes it's output stream downstream to the next component and so on.  Before all chained streams are processed (Read(...)), the output stream from the map is presented to another XML Disassembler which will perform property promotion for the destination schemas' stream.  When the pipeline and map are finally executed and the chained streams are pulled, the property promotion occurs during processing.  The XML disassembler will first do property promotion in the disassemble stage as it's stream is being pulled... finally the XML disassembler being used after the map will do it's propery promotion as it's stream is being pulled.  If the source schema and the destination schema both promote to the same property schema field, the property will have been promoted twice.  In other words; property promotion that happens after the mapping will always overwrite the property promoted by the pipeline's disassembler.

One way to look at pipeline execution is to imagine it as chained streams, when the most downstream component stream is being read, it's upstream component stream is read so the component can process it's read, this upstream component in turn read it's upstream component to get it's data to process, ... and so on.

Assuming the after map processing uses the XML Disassembler to do it's property promotion, during the GetNext() method call, the source message context is cloned into the output message context.

After a bit more thought, I remembered that the BizTalk mapper was modified to allow streaming whenever possible in BizTalk 2006 R2 (if memory serves me correctly).  Assuming the upstream pipeline stream(s) were not completely read prior to the post-map XML disassembler being created and the GetNext() method executed, the output message context would have been cloned prior to the pipeline disassembler's property promotion, which means the properties will not be over written because they are separate message contexts.

---

David Downing... If this answers your question, please Mark as the Answer. If this post is helpful, please vote as helpful.