I have had the "pleasure" of working with BizTalk on a few projects now.
I will save my general impression of Biztalk for another post. This is just to mention a undocumented side effect in BizTalk.
One of the key things in BizTalk is that all messages are immutable. I have found this to be mostly true.
In the following Message_1 and Message_2 are messages and should be immutable (except for in the block that constructs them)
Variable_1 = Message_1;
XmlSplitter.GetSFPage(Variable_1,0,2);
Message_2 = new System.Xml.XmlDocument();
Message_2.LoadXml(Message_1.OuterXml);
Message_1 is constructed elsewhere and yet we are able to change it by loading it into an XmlDocument. the above code is XLANG and I think it's a bug that the first line of code does not clone the message.
Maybe I read the code wrong, but it doesn't seem you've shown that BizTalk's immutability is broken. You've shown that you can construct one message from another, not that you can modify an existing message.
ReplyDeleteHi Ronnie.
ReplyDeleteBizTalk's orchestrations consists of blocks. The code above is part of a construction block that constructs Message_2. Message_1 is constructed in another block. The above code should result in Message_2 being the same as Message_1 was to begin with as you per definition can't change a message outside it's construction block. This is however not the case. It acts as I would expect C# code to act. A lot of the compile time check in Biztalk is based on the fact that you cannot alter a message once it has been constructed and this breaks that illusion.