A long while ago, while BizTalk 2006 was in beta, I mentioned a
couple of things about the Failed Message Routing feature and how it related to adapters.
Turns out I was a bit off the mark, and wanted to leave this here in case I ever need
this information again .
A couple of weeks ago I spent some good time troubleshooting an adapter, and was able
to understand a bit better the relationship between this feature and an adapter’s
behavior. Indeed, as I initially stated, failed message routing depends
on the ability to suspend messages that fail the submission process.
What can make this a bit confusing is that the BizTalk Messaging Engine can decide
to suspend messages on its own without adapter intervention. In cases where this happens,
failed message routing will still work, even if the receiving adapter doesn’t actually
support suspending messages in an explicit way.
For example, under some configurations, when an XML message fails processing
in the pipeline because the XML Disassembler component rejects it, the Messaging Engine
will suspend the incoming message on its own [1]. When this happen, the adapter will
receive an status code in the batch results with the value BTS_S_EPM_MESSAGE_SUSPENDED
(0xc00001).
What’s interesting about this value is that it is a success status code;
so, from the adapter perspective, it looks as if the message submit operation completed
without errors. It can, however, be a little confusing if you’re not aware of this
behavior.
Other than this scenarios, if you want to fully support failed message routing with
your adapters, you still need to fully implement suspending messages (through IBTTransportBatch.MoveToSuspendQ()).
[1] Unexpectedly enough, I haven’t seen this behavior with the Flat
File disassembler.