I have had some trouble with a custom decoder and the MLLP adapter when trying to read a larger stream (large being 10 Kb :/). It turned out to be a quite simple change, but it took me quite some hours debugging and not getting what was wrong.

When I tried to read the stream of the HL7 message in my custom decoder, I got an error. The stream length was 0 [zero] and not seekable, although it said it was seekable. This creates a problem if you are trying to read this stream of course.

One stream… another stream

There is a difference between the stream that is delivered to you through e.g. the FILE adapter and the MLLP adapter:

• FILE: Microsoft.BizTalk.Streaming.CEventingReadStream
• MLLP: Microsoft.BizTalk.Streaming.BasicStreamWrapper

Solution

I found the solution in converting the stream to a ReadOnlySeekableStream, as mentioned in this document by Microsoft (Optimizing Pipeline Performance): http://msdn.microsoft.com/en-us/library/ee377071(v=bts.10).aspx.

All I did was inset the code below and all properties (length, contenttype etc) became available and the stream could be read.

Stream seekStream = new ReadOnlySeekableStream(inmsg.BodyPart.GetOriginalDataStream());

I still don’t know what exactly was causing this behavior, but I can imagine it has something to do with how the incoming stream is handled by the adapter. Is the message being read into a big memorybuffer in a certain adapter and then handed off, or is it being streamed to the pipeline as well by another adapter?

Well, I am glad I found the solution to this problem. You will see me using this ReadOnlySeekableStream more often (if not always)  in the future when building a pipeline!