Blog

BizTalk, Pipeline Components

Consuming Pipeline Component issue fixed in R2

I previously experienced an issue with a general purpose (not an assembler/disassembler) consuming pipeline component in BizTalk Server 2006. For those of you unfamilliar with the term a consuming pipeline component is just that, a component that consumes the messages and returns null to stop pipline and message processing. Having tested this on R2 I’m happy to report that this issue doesn’t exist any more.


In short, my previous issue was that in some situations a consuming pipeline component might cause an endless loop to occur within BizTalk, which in any scenario is undesirerable. The cause of this was if the pipeline threw an exception making the message become suspended on the first time around, and then returned null the second time around. Granted, not a very common scenario, so chances are good that it might not have happened to you.


This code in the execute method of the pipeline component would allow you to reproduce the error:

public IBaseMessage Execute(IPipelineContext pContext, IBaseMessage pInMsg)
{
if (pInMsg.MessageID != new Guid((string)pInMsg.Context.Read(
“InterchangeID”, “http://schemas.microsoft.com/BizTalk/2003/system-properties”)))
{
System.Diagnostics.Trace.WriteLine(“EndLess: Return null”);
return null; // resume, return null
}
else
{
System.Diagnostics.Trace.WriteLine(“Ex”);
throw new Exception(“First time in pipeline, throwing exception”);
}
return pInMsg;
}

Just stick this code in the appropriate place in the custom pipeline component, create a receive pipeline, and run a message though. First time around it will get suspended. Now go ahead and resume it. Wham! There you go – endless loop in 2006. However like I said, R2 does not display this behavior, and with any luck some hotfix or update for 2006 might contain the fix as well.


The code above also shows another small trick: How to know if a message is a resume in a receive pipeline. When a message is first received the MessageID and InterchangeID are the same, however on a receive the MessageID will be a new one, but the InterchangeID will remain the same as it was the first time.

BizTalk, WMI

Programming WMI – The Visual Studio Server Explorer Way

Recently Niklas posted about a tool called WMI explorer. It’s a nice and easy tool to use if you want to explore the WMI interfaces and their values on any computer, especially any non-development computer. However as far as development, debugging and using WMI goes, I’ve come to be more in favour of another way of doing WMI programming. Namely by using the Visual Studio .NET Server Explorer. There is a great article/blogpost at El Grego’s BizTalk Blog highlighting the procedure. Granted, the post isn’t recent, but the approach is still valid. The only update for the 2005 version of Visual Studio .NET is that the Management extensions isn’t needed. The less custom code the better.

BizTalk, Performance, Pipeline Components

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.

Blogging, CommunityServer

Getting ClustrMaps into CommunityServer

I know, when you’re just starting out a blog, you don’t have that many readers, if any – so having an empty ClustrMap isn’t all that cool. But we all started somewhere. Getting ClustrMap for your blog is as simple as it gets. Just go to http://clustrmaps.com/ and sign up for a free account, wait for a mail and sign in using the password it will contain, then paste some html. Follow the same procedure as my previous post.

Blogging, CommunityServer, Messenger

Getting Messenger into Community Server 2007.1

See the little Messenger status icon under the News section in the sidebar? You can use that to contact me. If you click it it will open up a web messenger style dialog in a new browser window allowing you to either sign in with your Live Id or post a message anonymously (I’m allowing that for now).


If you want this on your site you can find out how at the Messenger blog. Basically you go to your online Messenger Settings and choose one of three styles, the little messenger window where you can chat directly in the same window as the blog, the staus icon look and the button look, which is a status icon and your display name inside a button. You then get html code to paste to whereever you want it.


I wanted the later, which of course was the one I couldn’t get working. The first obstacle, being new to CommunityServer, was finding out what to do to get something in the sidebar. I found this blog post, saying that you could basically put anything in the News section. Sounded easy enough. The example is from an older version of CommunityServer, things look a little different in the version I’m using, but the idea still works. When I pasted the html and clicked save though, it got formatted into html special characters text making the actual code appear on my blog instead of the meaning it represented. Finding out why that happens was a matter of another search, locating this forum post, explaining how to alter the configuration to allow for the script tags to pass unchanged. I did that. I also added in the attributes of msgr:width etc to the div tag. Since the configuration file is xml I also added a namespace declaration for the msgr namespace. I finally got the code as it should be, but the button still won’t show up. I suspect it has something to do with the class of the div that contains it, or perhaps it being inside a ul tag. Not sure. For now I settled on the status icon instead. If anyone has insight into how to get this to work, feel free to share.