In my last post I blogged about the improvements to recoverable interchange processing (RIP) in the upcoming 2009 release of BizTalk Server. One question that pop up while writing that post was whether it would be possible to write a custom pipeline component that supports RIP.
After doing some research on the Internet I found out that it is possible and fairly simple to do. Actually it was already possible in BizTalk 2006. It was just something that I (and the co-workers that I asked) didn’t know. So please stop reading if you are already familiar with this Image may be NSFW.
Clik here to view.
A typical scenario is a pipeline that consists of a XmlDisassembler and this custom RIP pipeline component. The interchange is received in the pipeline and disassembled into separate body messages by the XmlDisassembler. After that, for each body stream some processing is performed by the custom pipeline component. If this processing fails the single body instance needs to be suspended instead of the whole interchange.
There are basically three things you must do in your pipeline component to enable this:
Write property “SuspendMessageOnRoutingFailure”
The property “SuspendMessageOnRoutingFailure” needs to be written to the context of the message in case the processing of the message in the pipeline components succeeds. The value of the property needs to be set to true.
This property tells the messaging engine that each body message needs to be suspended in case of a routing failure. If you don’t write this to the context you’ll get a routing failure report for each body message while there will only be one suspended message (the whole interchange).
Write property “MessageDestination”
This property needs to be written to the context of the message when the custom pipeline components has decided that the processing on this specific body message has failed.
The value needs to be ‘SuspendQueue’ so that the messaging engine knows this particular body message needs to be suspended.
Return a searchable stream
The messaging engine needs a searchable stream to be able to put the body message in the ‘SuspendQueue’. I don’t know the exact reason behind this but the engine probable needs to rewind the stream for proper error handling. Anyway we just have to make sure we return a searchable stream when the body instance needs to be suspended.
I wrote a simple test application to test this. The first I did was adding a property to enable or disable the RIP feature of my component. Much like the setting for the XmlDisassembler (and XmlValidator in BizTalk 2009)
Image may be NSFW.
Clik here to view.
The execute method of the pipeline looks like this:
Image may be NSFW.
Clik here to view.
First the incoming stream is wrapped a XpathMutatorStream object to be able to receive an event when a certain xpath is matched. I use this to check whether or not the message is wrong (and should be suspended). In this sample the body messages each contain an attribute to indicate whether they are ‘good’ or ‘wrong’.
Image may be NSFW.
Clik here to view.
Next I create a virtual stream (which is searchable) to meet the requirement of returning a searchable stream.
In the third step I create a new output message containing the searchable stream.
If the message is ‘good’ I don’t care about RIP being enabled or disabled and just return the message (using the method ‘HandleHappFlow’). The only thing I need to do is write the ‘SuspendMessageOnRoutingFailure’ context property to the message as mentioned above.
If the message is ‘wrong’ and RIP is enabled I call the method ‘HandleRecoverableError’. The code of this method:
Image may be NSFW.
Clik here to view.
It just returns the message with the searchable stream, set some error information and writes the property ‘MessageDestination’ to the context.
Finally if the message is ‘wrong’ and RIP is disabled I throw an error so that the whole interchange will be suspended by the messaging engine.
Image may be NSFW.
Clik here to view.
The sample source can be downloaded from here. It was developed using the beta release of BizTalk Server 2009. As said before the sample should also work for BizTalk 2006. The solution needs to be manually converted back to a Visual Studio 2005 solution however.
Tagged: BizTalk, BizTalk 2009, Pipelines Image may be NSFW.
Clik here to view.
