„Unwanted“ feature - When a feature becomes a bug

#001 Unexpected property demotion in BizTalk Server

A feature should be a category which should not bring ambiguity in our solutions. Also, we should be empowered to willfully turn it on or off.
Property promotion and demotion is - documented feature in BizTalk Server - widely blogged and discussed on news groups when it does not work as expected.
In the following sample Property Demotion works but it's not really what we expected to happen!

Here is my sample schema... (Schema.xml)

The only thing we should notice is that the PP element is promoted using Quick Promotion in the Visual Studio Schema Editor and it is a Distinguished Field.

Our sample orchestration receives a sample message (MsgIn). In the Message Assignment Shape MsgIn is assigned to MsgOut and the "NP" string constant is assigned to the MsgOut.PP distinguished field. At the end, the orchestration sends out the MsgOut message.

I created a FILE Receive Port/Location pair with the XMLReceive Pipeline and a FILE Send Port with the XMLTransmit Send Pipeline and bounded the sample orchestration to those endpoints.

If the MsgIn message is: (MsgIn.xml)

the MsgOut message arrived at the receive location is: (MsgOut.xml)

Just as expected.

But, if for any reason we change the promoted property's (PP's) Property Schema Base in the property schema to MessageContextPropertyBase the resulted message will be equal to the original message. The PP element value stays "PP" and not "NP". That's not what we expect to happen.

So, what happened? Property demotion.

If we debug the orchestration everything seems fine. The PP value changes to "NP" and the orchestration sends out the MsgOut message with the "NP" value in it. Still the message on the file system shows "PP" for the PP element. The PP value is changed in the pipeline. As we assigned MsgIn to MsgOut with the MsgOut = MsgIn; expression the Message Context is also assigned. With MsgOut.PP = "NP"; we only changed the body data not the context property and the XMLTransmit pipeline is demoted the old value into the message body.

If we change the content of the Message Assignment shape to:

MsgOut = MsgIn;
MsgOut(UnwantedPD.PropertySchema.PP) = "NP";

the resulted message body's PP element value will become "NP" immediately during the execution of the shape. With execution of the second line both the message context property and the body element value are changed in the same time. Later on, if property demotion happens, nothing changes.

So, be careful using distinguished fields when they are also promoted properties.

It would be even better if we could turn on or off property promotion/demotion in our pipelines.

Few days ago, this behavior cost me several hours of debugging. The receive location was a SharePoint view and the send location was the same SharePoint InfoPath form library where the view was also defined. I debugged my orchestration and saw that the SharePoint view filter value in my message was changed but there were no forms in my library and every second a new orchestration started up, endlessly.