Way back in 2005 Stephen W. Thomas wrote the #1 Google hit for “recoverable interchange processing”. This was added as a very welcome feature to the 2006 edition. As such I knew about it when designing the following information flow.
- Data is polled from a database (about 500 parent rows at a time). SQL server then adds the child data for each parent and returns it as XML.
- The receive pipeline is set to XMLReceive and the message is debatched when received by BizTalk. This is because the data is wrapped in an envelope by the adapter.
- Each individual message can then be mapped to an internal format.
- Each message is the mapped again and sent to the receiving party.
Now what happens if row 486 contains some kind of error and cannot be mapped on the receive port? The answer: The default behavior of BizTalk is that it will suspend the whole batch. Enter recoverable interchange processing (or RIP for short).
So I simply turned on RIP on the receive pipeline in step 2, but to no avail. That did not work. Turns out that you need to add a bit of code in a custom pipeline component for this to work.
to a pipeline component and add it to a pipeline in the validate stage. Don’t forget to add an XmlDisassembler to the disassemble stage, since you want to keep the debatching behavior.
The result will look like this:
If you create the component, make sure to have it be configurable from Visual Studio as well as BizTalk Management Console.
The end result might look like this:
You can see that there is a property called SuspendBatchOnFail. If this is set to false, BizTalk will process the next message in the batch even if mapping fails.
BizTalk also marks the message with a sequence number. This number that is displayed in the eventlog if it is suspended. The error will read: “The Messaging Engine failed while executing the inbound map for a recoverable interchange message on Receive Port [—] The input message to the map is being suspended. The sequence number of the suspended message is 8.”