Question

I am writing a WCF client to a SOAP service that returns a mime multi-part result with binary data (actually, a PDF file). It uses a custom message encoder.

The service doesn’t seem to mind if I make the request a single-part format, so I am able to get a result back. There are two problems with the result from what I can see:

• It only seems to return the first part of the multi-part message.
• The data I get back cannot be decoded by my custom encoder.

I have tried utilizing MTOM binding, but that messes up the request. It fails to add the “boundary” parameter in the content-type, so the server cannot understand the request.

I think what I want is a basic text SOAP request, but a response decoded MTOM-style. I have no idea how to set that up, however.

The closest solution I have found is this: http://blogs.msdn.com/b/carlosfigueira/archive/2011/02/16/using-mtom-in-a-wcf-custom-encoder.aspx

But it seems like a very invasive change to my project.

Answer 1

I figured this out. First of all, I was incorrect when I said that I was only getting the first part of the multi-part message using the MTOM encoder; I was getting the whole thing. I was looking at it in the debugger and the bottom must have gotten clipped in the debug viewer. Chalk it up to my inexperience manually looking at and deciphering multi-part messages.

To the second point, all I had to do was use the MTOM encoder when the Content-Type was multipart/related and everything worked just fine. If you read the referenced article above, it’s all about dynamically detecting whether the message is multipart or regular text, and choosing the proper encoder based on that. Essentially, it’s a custom encoder that has both a text encoder and MTOM encoder built into it, and switches back and forth based on the content-type of the incoming message.

Our project requires some post processing of the response message before it’s handed off to the main program logic. So, we get the incoming SOAP content as an XML string, and do some XML manipulation on it.

This is a slight departure from the solution recommended in the article. All that’s required in the article’s solution is reading the message using the right encoder into a System.ServiceModel.Channels.Message, and returning that. In our solution, we need to interrupt this process and do the post-processing.

To do that, implement the following in your custom encoder:

public override Message ReadMessage(ArraySegment<byte> buffer, BufferManager bufferManager, string contentType)
{
    //First, get the incoming message as a byte array
    var messageData = new byte[buffer.Count];
    Array.Copy(buffer.Array, buffer.Offset, messageData, 0, messageData.Length);
    bufferManager.ReturnBuffer(buffer.Array);
    //Now convert it into a string for post-processing.  Look at the content-type to determine which encoder to use.
    string stringResult;
    if (contentType != null && contentType.Contains("multipart/related"))
    {
        Message unprocessedMessageResult = this.mtomEncoder.ReadMessage(buffer, bufferManager, contentType);
        stringResult = unprocessedMessageResult.ToString();
    }
    else {
        //If it's not a multi-part message, the byte array already has the complete content, and it simply needs to be converted to a string
        stringResult = Encoding.UTF8.GetString(messageData);
    }
    Message processedMessageResult = functionToDoPostProccessing(stringResult);
    return processedMessageResult;
}