As some people have mentioned recently, one of the new features in BizTalk Server 2006 (aka PathFinder) is routing of failed messages. This is a very cool new feature because it gives you the possibility of using the standard Pub/Sub mechanism exposed by BizTalk to handle failed messages (either because they failed during a receive or a send operation). The trick to enable this is the "Generate error report for failed message" checkbox in the port configuration.
One really nice thing about how this feature is implemented is that it should be adapter-agnostic, meaning it should work with any adapter that uses the standard adapter framework (except, I believe, MSMQT which it seems won't support it). Now, here's the tricky point: As I understood the feature, it would work with any adapter that supported suspending failed messages.
However, imagine my surprised when I noticed the feature working with a custom transactional receive adapter I had built for one of our customers, given that the adapter explicitly does not support message suspension (if the submit operation generates an error, the adapter just aborts the transaction and forgets about it).
In the case I was testing, I tried having the adapter submit a document with invalid XML to the XMLReceive pipeline (which would fail). Normally, I would've expected the adapter to trap the error and abort the transaction, but instead it went ahead and commited it! Apparently, when the "Generate error report for failed message" is enabled, the BizTalk messaging engine will trap the error condition when the message is submitted and, instead of reporting the error back to the adapter, it will tell it that everything went OK.
I do not know if this is intentional, or if it is a bug, but it certainly seems like an interesting behavior to be aware of. It would be interesting to know if this is not done for adapters that support in order processing... This was, btw, tested on the CTP of BizTalk 2006 given out at TechEd this year.
