Custom Pipeline Components Development Best Practices

There is much to be said about pipeline component development. Online, in the helpfiles, in books there are step by step guidance on how to build pipeline components of different types (Assembers, Dissassemblers, General Purpose etc.). I’m not going to repeat any of that. Instead I’m going to list the things that I feel are paramount to think about when doing pipeline component development, regardless of type of component and its purpose.

1. 
   
   As long as it’s possible – keep it forward only streaming. Learn and know the contents and techniques of Microsoft.BizTalk.Streaming.dll.


2. 
   
   In case you can’t keep it forward only, make sure you have a seekable stream, by wrapping it in such (ReadOnlySeekableStream), which in turns creates a VirtualStream that overflows to disk instead of filling up your memory.


3. 
   
   If the above streaming classes are not enough, and you need data from the stream, try to build your own Stream implementation and perform your logic as it is being read. Be a copycat, use Reflector.


4. 
   
   Do not load the contents of streams into memory. MemoryStream, XmlDocument, string and ReadToEnd and such is therefore generally a sign of bad practice. Keep your components impact on memory as low as possible.


5. 
   
   Don’t start new threads – doing so interferes with BizTalks internal threadpool management and thus impacts performance.


6. 
   
   Try to stay away from database calls or calls to WebServices. If you must do them, be sure to cache the response if at all possible (and reasonable). Keep the pipeline lean and mean.


7. 
   
   Test. Test early, test often, test as a unit, test in conjuction with other components in a pipeline, test logic, test performance. And when testing, don’t test on your development laptop and go “that seems to work fine”, keep it real (as real as possible).

If you think of these things you’ll be better off. There are still mistakes you can make doing BizTalk custom pipeline component develpment, and of course all general .Net coding best practices apply here as well, but if you think of these things, and can clearly motivate when and why you deviate from them, you’re one step closer to a successful component implementation.