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.
