This week I met with a healthcare customer who is using BizTalk to build a robust publish-subscribe architecture. One component
of this involves making last second decisions to either send or “eat” messages going out to a send adapter. I put together
a quick sample to demonstrate how you can selectively eat messages on the way out of BizTalk.

The core logic for this naturally resides in a custom pipeline component. Mine, called “EatMessage”, is a (any) send pipeline.
I have some custom properties that enable this component to be reused in multiple scenarios. The code looks like this:


public IBaseMessage Execute(IPipelineContext pc, IBaseMessage inmsg)
{
//grab value out of context using property fields
object eatField = inmsg.Context.Read(_FieldName, _FieldNS);

//if that value exists
if (eatField != null)
{
//compare the context value to the property condition
if (eatField.ToString() == _EatCondition)
{
System.Diagnostics.EventLog.WriteEntry(“Custom Pipeline”, “Message Eaten”);

//eat the message
return null;
}
else
{
return inmsg;
}
}
else
{
return inmsg;
}

}


So as you can see, I’ve got some design time properties that store the context property value and namespace, and a field
that is used to determine whether to eat the message or not. For instance, the _EatCondition might be equal to “true”, which
means if the context value equals “true” then eat the message. Or, it could be a date, or number, or whatever.

Next I build my schema. Basic stuff, contains a node called DoNotSend which I’ll set via a map, prior to sending the message
through the pipeline.

I then created a property schema with the one promoted EatValue node. I could reuse this with multiple different schemas.

Now the fun part. I created a new Send pipeline in my BizTalk project. I first drop the XML Assembler component, then plop
down the MessageEater component. As you can see here, there are the three properties I use later in the code.

Finally, I create a map. This map uses functoids to see if the Patient ID is a certain value, and if so, sets the DoNotSend
node to true. Otherwise, sets it to false.

After deploying the project, I created a send port to the FILE system. In it, I selected my new Send pipeline, and, the map. Since
the order of processing in a send port goes “Map –> Pipeline” I can be sure that the map outcome will feed the latest data to my pipeline component. After
building and testing, indeed, when I send a file through BizTalk with one particular Patient ID the message never comes back out, and
DOES get dropped if the Patient ID equals something else. Nice.

Technorati Tags: BizTalk