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.