I've been writing some Pipeline Components for BizTalk 2006, and I ran into a bit of a problem while testing one of them. The problem is a fairly common, but obscure issue that appears with most non-trivial pipeline components: Stream Handling.
Charles Young has a pretty good article here about the problems that appear when pipeline components don't handle message stream correctly. In particular, Charles talks about a bug in BizTalk 2004 which caused inbound maps to fail when a pipeline component returned a seekable stream, and thus recommends pipeline component developers always make sure they return a non-seekable stream to avoid the issue.
My case, however, was a little bit different. It seems that Charles recommendation only holds true for pipeline components that run in or after the disassemble stage in a receive pipeline. I was, instead, writing a decoding component, and, in my test, the receive interchange kept failing with the following message in the machine's Application Event Log: "Stream does not support seeking". Indeed I was returning a non-seekable stream from my pipeline component, but I haven't figure out exactly why this is an issue.
As far as I can see, this is related to the presence of the Xml Disassembler component in the disassemble stage of the receive pipeline I was using to test my component. Though BizTalk unfortunately doesn't give you any details about the error (not even a stack trace), it's pretty hard to diagnose exactly what the problem is with non-seekable streams here, but I think it has something to use with the use of the MarkableForwardOnlyEventingReadStream used by the Xml Disassembler, which is constructed during message probing (IProbeMessage.Probe()). I did some spelunking around doing some tracing and using Reflector, and it does indeed seem that this special stream class that the disassembler creates called my Stream's CanSeek method (which properly returned false), but I could not see code where explicitly an error message was returned or processing was halted based on this value, and instead some alternative work was done, which I found rather confusing.
These kind of issues can be quite a bit of stressful because the semantics expected by BizTalk (or rather, but the standard components included in BizTalk) are not documented anywhere, making the process of writing a good and efficient pipeline component a trial-and-error process, which is wildly frustrating and a very innefficient process itself.
I think this is pretty nasty requirements for decoding component writers, as, in general, they are usually built to decode a stream start to finish without moving around the stream (most encryption/decryption components are easy, natural and efficient to write this way). Additionally, it makes it imposible to simply have a decoding component that returns a System.Security.Cryptography.CryptoStream stream to BizTalk, because it is always non-seekable.
Solving the Issue
The easiest way to work around this problem would be to have the decoding component decode the entire message into a seekable in-memory stream, but this is highly inneficient, and it is sure to cause performance and scalability problems with either large interchanges or a lot of concurrent messages flowing through the system.
What's more frustraring about this is that it seems that the BizTalk Developers were aware of this problem and solved it. After quite a bit of looking around, I discovered that the MIME/SMIME component included in BizTalk is apparently aware of the problem with non-seekable streams! It verifies if the data stream coming off the adapter is seekable, and, if not, wraps it around a custom stream that allows read-only, seekable access to it in what looks like a more efficient way than just loading it entirely into memory. It basically does something like this:
if ( !stream.CanSeek )
{
part.Data = stream = new ReadOnlySeekableStream(stream);
}
The ReadOnlySeekableStream class is implemented in Microsoft.BizTalk.Streaming.dll, and is a public class. Unfortunately, it is undocumented, and the assembly is only installed to the GAC, making it, at the very least, cumbersome and risky to reuse on your own.
If anyone has any explanations of why seekable streams appear to be required on this case, I'd sure would like to hear about it!
