by eliasen
15. december 2009 20:50
Hi all
I had a discussion with Randal van Splunteren (http://biztalkmessages.vansplunteren.net/) today about demotion. Randal has been so kind as to review the first chapter I am writing for the book (http://blog.eliasen.dk/2009/09/18/BizTalkServer2009Unleashed.aspx) and we started chatting about demotion. Specifically we discussed whether existing values in XML would be overwritten when demotion occurs.
As it turns out, it depends.
I did a small sample with two schemas and a map. I used a receive port to receive a message, mapped it to the second schema (which just created empty nodes in the destination schema) and output the result through a send port. The receive location used XMLReceive and the send port used the XMLTransmit pipeline. What happened was, that the output had the correct demoted values in them, since the XML assembler had empty elements to map into. Now, if I changed the map to put a value into the fields, then the mapped values were also output and not the demoted values. This means, that demotion does NOT overwrite existing values.
Randal, however, had a sample, where the existing values WERE overwritten. His solution was leveraging an orchestration, however, which seems to be the big difference. As I have blogged about here: http://blog.eliasen.dk/2009/10/16/DemotionDoesNotWorkForAttributesOrDoesIt.aspx orchestrations can demote into attributes, which normal demotion cannot. So apparently there is another difference, which is, that demotion in an orchestration, actually overwrites existing values.
But now for the funny (weird?) part. I setup a solution where I had an XML instance as input and used the passthrough receive pipeline. So no message type was promoted. Even without an orchestration, the XML assembler actually does demotion, which is cool. BUT, it overwrites existing values… Go figure. If the message type is present, existing values are not overwritten, but if it is not present, existing values are overwritten.
Weird!
--
Eliasen
efefd844-42d2-4965-b34d-018d3f5c9cf7|0|.0
Tags: