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