This project has moved and is read-only. For the latest updates, please go here.

Property Not promoted from destination Schema of a map.

Feb 27, 2015 at 9:13 AM
Used BRE Pipeline Framework component in the Validate Stage of Pipeline for Map transformation.

After execution of map, only the properties from the disassemble stage and BTS_MessageType property of the destination schema is promoted to next stage.

I have few properties promoted in the schema used in the destination of the map, which is not available.

I am using this properties in the filter, but i am not seeing the property value set in the context of the subscribing message.

I am not sure, whether am i doing something wrong in this case. Please advise
Feb 27, 2015 at 10:06 AM
Edited Feb 27, 2015 at 10:12 AM
Hi Dilip,

You are not doing anything wrong per se. It is not normal behavior for a map to automatically promote the context properties of the destination schema on execution. This behavior is a very specialized behavior of maps when they are executed as an inbound map on a BizTalk receive location or send port (configured via the administration console). You can test this by executing a map in an orchestration and seeing if the context properties on the output message are automatically promoted, my belief is that they will not be, and I would wager the same is true for executing maps with the ESB Toolkit.

There are two options I can think of to get around this problem.
  • Execute the BRE Pipeline Framework component which executes the map in the decode stage prior to the XML Disassembler. Doing this will ensure that the XML disassembler will promote the context properties from the destination message. If you want to be selective about which map you execute based on the message type then you can use the GetXPathResult vocabulary definition in the BREPipelineInstructions.SampleInstructions.HelperInstructions vocabulary to evaluate the root node name and namespace on the XML message (or potentially even elements within the message if you want to take it one step further), since you won't be able to access the BTS.MessageType context property seeing as the XML Disassembler hasn't yet run. I would prefer this option.
  • As a secondary option, you could leave the pipeline component exactly as it is, and then use the SetCustomContextPropertyFromXPath vocabulary definition in the BREPipelineFramework.SampleInstructions.ContextInstructions vocabulary to promote the context properties on the destination message based on XPath statements. You'll have to ensure that this vocabulary definition executes after the map. You could either do this by putting it as an action straight after the transformation action in the same rule as the transformation, or by keeping it in a separate rule with the priority set such that it will run after the transformation rule.
I hope the above makes sense to you. I have closed the issue because I don't think it is something that can/should be fixed, but will reopen if you feel very strongly about it. I'm happy to continue having the discussion in this thread.

Feb 27, 2015 at 12:17 PM
Edited Feb 27, 2015 at 12:25 PM
As you have rightly pointed out - " This is a very specialized behaviour of maps when they are executed as an inbound map on a BizTalk receive location or send port (configured via the administration console)"

Scenario being in question is messaging solution and that is how i bumped into this difference in behaviour.

As you pointed out 2 options - first option is not feasible as i am receiving a flat file which has to be dissembled before transformation can be applied.
Second option is one which we have implemented right now to overcome this issue.

My only question here now is, why to promote the same property using SetCustomContextPropertyFromXPath to make it available on filters, when we have already made it as a promoted property at the schema level (FYI - This is a common schema used across application)

Feb 27, 2015 at 7:58 PM
Hi Dilip,

The reason you had to promote the values manually is because promotion is normally carried out by disassemblers (so if you had promoted the properties on the flat file schema rather than on the XML schema then the properties would get promoted, or on inbound maps on a receive/send port. Because neither of these scenarios is being satisfied the context properties have to be promoted manually.

Can I ask why you are using the BRE pipeline framework to execute the map rather than configuring it on the port. There are many good reasons, but I'm curious to find out what yours is.

Mar 1, 2015 at 5:54 PM
I've solved this problem by calling the XML Dissembler pipeline component (Microsoft.BizTalk.Component.XmlDasmComp) within a custom pipeline component that is placed after the disassembler stage. It might be possible to write a custom instruction to do the same thing and be used within the BRE Framework.
Mar 1, 2015 at 6:17 PM
Great idea GuessMyName. Do you have code you can share? Otherwise I can figure this out myself and look at creating a new minor version of the framework.


Mar 2, 2015 at 2:02 PM
Edited Mar 2, 2015 at 2:30 PM

Purpose of using BRE pipeline framework
  1. seems to maintain "UNIFORMITY" for applying transformation across BizTalk messaging solution (not a great reason though).
  2. For deployment purpose to reduce the Biztalk application outage and to avoid inter-application references being made.
Hope you are figuring out a way to implement this missing feature in BRE Pipeline framework component. Will be waiting for one.


Very grateful for your idea on this.

Jun 3, 2015 at 11:14 AM
Hi Dilip/GuessMyName,

I am adding a new vocabulary definition in v1.6 of the BRE Pipeline Framework that will cater for this requirement. Thanks for the idea.

Jun 26, 2015 at 12:10 PM
This is now catered for in BRE Pipeline Framework v1.6, give it a whirl and see if it works for you.
Marked as answer by jcooper1982 on 6/26/2015 at 4:10 AM