Yossi Dahan [BizTalk]


Sunday, March 19, 2006

Failed Message Routing

I really like those tick boxes on the receive and send ports that allow generation of error reports on failures.

There are quite a few posts about this feature, so I won't go into details, but generally it allows messages that failed in the receive (or send ports) to be published to the message box with additional context properties to indicate the error (while not fulfilling any of the "good" subscriptions)

This allows the system to automatically handle error scenarios and basically extends the option we had in BizTalk 2004 to subscribe to NACK's.

I believe the most common use for this is to handle messages with routing failure.
These can generally happen when there was a problem in the receive pipeline (or indeed the received message) or when a service is not enlisted.

The problem with this is that although it allows you to "take ownership" of the problem in a sense and handle it as needed, it still logs an error into the event log, which, at least in large organizations with well implemented monitoring solutions will trigger a whole mechanism of alerting and handling the error scenario.

This led a lot of implementation to create a sort of dead-end subscriber in the form of an orchestration, a pipeline with a consuming pipeline component (which will require configuring transport settings to the adapter which will never be used) or even a custom "consuming" adapter, in order to ensure the message has at least one valid subscriber and avoid errors from being logged. In any case this is an additional, largely pointless object which requires development (and maintenance) and makes a much less clean architecture.

I wish MS had a settings that’s allows us to decide if an error should be logged, ideally allowing us to set it at runtime through our error handling routines, maybe, in the case of routing logging an error only if there were no subscribers to published error message.


Post a Comment

<< Home