BizTalk Server is a persistent system. Meaning that messages, while residing in BizTalk, are never lost, especially if they fail. Whether it is a failure related to the transaction itself (transformation, parsing, etc.) or a failure within BizTalk itself (server downtime, reboot, etc.), however, this doesn’t mean that BizTalk will guess what needs to be done to the transaction during this period. All BizTalk can do is queue it somewhere and wait for a BizTalk Administrator to manually flush it out or reprocess it. This should be the last resort, because we never want transactions queuing up in some location where only an Administrator has access, and has no plan for it. Instead (depending the scenario) a proper plan has to be placed around handling and moving the transaction forward.
Where to start? – The Queue
This scenario of having BizTalk inherent functionality just Queue failed messages in the suspend queue is a very common one for beginning BizTalk installations, and one that can survive for a period of time, if there are a very small number of integration transactions running. In enterprise-class installations, the sheer quantity of messages make it incredibly inefficient, time consuming, and unstable to take that approach.
What is the best practice, per Microsoft?
If we are trying to make a call to a Database or a Web Service to deliver some transaction and it is not available at a particular time, our “Exception handling” solution could be to wait 5 minutes and try again, until the server is up. Alternatively, we could choose to send a notification via email, or even a text message, to tell the appropriate party to look into the issue. If the error is related to “bad data”, we could provide a user interface to allow a non-IT associate to edit the transaction, and resubmit it for reprocessing. For every situation there is a different scenario and solution. . . but the Best Practice is to never let a transaction to go to the default BizTalk “Suspended” queue. Instead, as each new error type occurs, they should be learned and handled until no messages are ever suspended. The Suspended queue is meant for a fall safe, and as a temporary repository for errors while proper error handling routines are implemented to prevent them from arriving in the Suspended Queue again.