Hi all

Today I discovered something I was not expecting while documenting something else, which I have just described here.

I had a solution that involved this input schema:

and this output schema:

Field1 from the input schema and Field3 form the output schema are promoted to the same property and Field2 form the input schema and Field4 from the output schema are also promoted to the same property. Note, that Field4 is an attribute, whereas Field1, Field2 and Field3 are elements.

I then have a map that does not map anything from the input to the output. It just creates empty elements/attributes in the output schema.

I added a receive port and receive location to read in the input and used the XMLReceive pipeline, because I needed the messagetype and I needed the property promotion. I added my map to the receive port. I then created a send port that basically just took everything that came in on the receive port and sent it out to a file. The send port uses the XMLTransmit pipeline.

The output from this was, as I expected. Given this input:

I got this output:

What happens is, that demotion is not supported for attributes, which really seems like a silly restriction, but that is just how it is.

When, however, I implemented my solution using an orchestration, it worked! The value of Field2 in the input was demoted into the value of Field4 in the output.

My orchestration is very simple:

Basically, I receive the input, transform it using the same map as was on the receive port, copy over all the properties:

   1: OutputMessage(*) = InputMessage(*);

   2: OutputMessage(DemotionTest.Property1) = InputMessage(DemotionTest.Property1);

   3: OutputMessage(DemotionTest.Property2) = InputMessage(DemotionTest.Property2);

The reason that I copy over Property1 and Property2 manually is, that they are marked as MessageDataContextProperty in the property schema, and therefore, they are not automatically copied over using the OutputMessage(*) = InputMessage(*) statement.

After doing this, I just send out the message. The result is this:

Now, this confused me… and what confused me more is, that I can actually do it with the passthrough pipeline on the send port. This means, that the demotion is happening as the orchestration publishes the message into the MessageBox for sending out the message.

So the upside to this is, that demotion for attributes DOES work – but only when the demotion occurs inside an orchestration upon sending out the message.

The downside is, that the product team have managed to do things differently depending on where in the process it happens, which really sounds like bad design. Hopefully they will fix this at some point in time.

Hope this helps someone

--
eliasen