Message assignments that have inconsistent values in BizTalk Server 2004 (908169)

INTRODUCTION

You may notice message assignments that have inconsistent values in Microsoft BizTalk Server 2004. This issue may occur when you make the message assignment by passing a message reference to a Microsoft .NET object or to an external assembly.

When a message is constructed, a representation is in the MessageBox database and another representation is in memory on the computer. If an external assembly modifies the representation in memory on the computer, the BizTalk Server 2004 XLANG engine is not aware of the modification. Additionally, the XLANG engine does not invalidate the message part data that is in the representation in the MessageBox database.

For example, the following code sends the UnderlyingPart data from the representation in the MessageBox database.

// In this example, assume m1 is committed to the MessageBox
Construct m2 
{
m2 = m1; // m2's part data representation is the UnderlyingPart data of m1
m2(myContextProperty) = "123"; // m2's part data representation is still the UnderlyingPart data of m1
A.test(m2.part); // XLANG does not invalidate the UnderlyingPart MessageBox representation
}
Send(p.o, m2);

MORE INFORMATION

Message part data has the following modes of representation:

The XmlDocument representation
The Object representation
The Stream representation
The UnderlyingPart representation

How the message part data is represented in memory depends on the message construction and whether the type is a .NET class or an XML Schema definition language (XSD) schema. However, the UnderlyingPart representation is always a stream pointing into the MessageBox database. Because messages in BizTalk Server 2004 are immutable after the message is committed to the MessageBox database, the XLANG engine uses the representation in the MessageBox database when the XLANG engine references message part data.

Note A constructed message may already have a representation in the MessageBox database if you assign parts from a message that is already committed.

To work around this issue, you can use code that is similar to the following to return an XmlDocument document to a Message XLANG variable.

Void A.test(ref XmlDocument xd) {.}
XmlDocument A.bar(XmlDocument xd) {.}

construct m2 
{
m2 = m1;
m2(myContextProperty) = "123"; // m2's part data representation is the UnderlyingPart data of m1
A.test( ref m2.part); // XLANG has enough information to know it has to invalidate the UnderlyingPart MessageBox representation
// or
m2.part = A.bar( m2.part); // XLANG has enough information to know it has to invalidate the UnderlyingPart MessageBox representation
}