Professional BizTalk® Server 2006

13.4. Subscribing to Failure Messages

As discussed later in this chapter, suspended messages can cause administrative problems. BizTalk suspends messages following an error condition. Error conditions vary from simple message-integrity problems (not adhering to the schema, for example) to more serious orchestration failures (such as an uncaught exception thrown by the BizTalk engine or a custom component).

Some error conditions can be caught and handled by the developer (for example, the use of a Scope shape within an orchestration with an exception handler configured or the use of a try/catch block within a pipeline component). Other error conditions cannot, by default, be caught by a developer (for example, a malformed message received by the XmlReceive pipeline). In these cases, the exception is propagated to the BizTalk runtime, which either returns an error to the client (in the case of a Receive pipeline connected to a request/response adapter) or (as in all other cases) places the message in the MessageBox but marks it as suspended.

You can view suspended messages through the BizTalk administration tool. In some cases, a suspended message may be resumed. Resumption causes BizTalk to reattempt processing. Such resumption is common when an orchestration was not enlisted when the message arrived, for instance. The orchestration not being enlisted means no subscription for the message would have been present (and therefore the message was then suspended).

In other more serious ...