Rationalizing Multipart Message, Port and Correlation Types

In many orchestrations, I find myself creating the same port, multipart message or correlation types over and over again. For example, we have a scenario where a certain number of different orchestrations receive the same type of message, with a common envelope and a context-specific payload.

For some reason, it never occurred to me that I could rationalize those types in a single common orchestration.

In order to do that in the Orchestration Designer when declaring such types, it is obviously necessary to modify the "Type Modifier" property for the appropriate object from its default "Internal" to "Public" instead. This will ensure that the given object is available in other orchestrations that need them.

Apart from this simple change however, there are certain subtleties to take into account.

Empty Orchestration

The first problem is that BizTalk does not allow empty orchestrations. To be valid, an orchestration needs a input stimulus. This can be an activated receive shape or a input orchestration parameter. In this case, I like to declare a single untyped message parameter.

Processing Untyped Messages

Receiving untyped messages pose a certain challenge.

Normally, untyped messages are represented in BizTalk as parts typed System.Xml.XmlDocument. This allows arbitrary payload messages, including non-XML messages, to flow through BizTalk without any further processing.

However, when other orchestrations reference a common orchestration that declares a public multipart message or port type whose part or operation respectively uses System.Xml.XmlDocument to denote untypedness, it sees this as Microsoft.XLANGs.BaseTypes.Any instead !

Untyped Messages HowTo

In fact, there are two ways to represent untyped messages in BizTalk orchestrations.

The first way consists in using the BizTalk-specific Microsoft.XLANGs.BaseTypes.Any type for a message part or a port operation. This special type has been designed to represent arbitrary XML documents. It is particularly suited when transferring potentially different XML documents whose contents is not of interest in BizTalk.

The second way consists in using the Microsoft .Net Framework System.Xml.XmlDocument type for a message part or a port operation. This datatype has been chosen by BizTalk designers to represent the "base class" from which any and all messages flowing through BizTalk inherit. In the particular context of BizTalk however, this datatype name is misleading for it does not necessarily designate XML contents. Instead, it is ususally and most certainly used to represent arbitrary flat file or binary contents.

Extracting Message Parts

The solution is to include a little helper that extracts the part with the appropriate type:

public static class Message
{
    public static void AddPart(XLANGMessage 

message, string name, object part)
    {
        message.AddPart(part, name);
    }

    public static object GetPart(XLANGMessage 

message, string name, Type 

type)
    {
        XLANGPart part = message[name];
        return part.RetrieveAs(type);
    }

    public static Stream GetRawStream(XLANGMessage message, string name)
    {
        return (Stream) 

GetPart(message, name, typeof(Stream));
    }

    public static Stream GetRawStream(XLANGMessage message)
    {
        XLANGPart part = message[0];
        return (Stream)

part.RetrieveAs(typeof(Stream));
    }
}

Extracting the appropriate part is a simple matter of calling this function in an Expression shape, like so:

This entry was posted in BizTalk. Bookmark the permalink.