Other ways to deal with suspended messages...
Rudolf Henning recently wrote an interesting post in his blog entitled "Listing BizTalk suspended filenames";
Typically I don't respond directly to people's posts, but heck that's what blogging is supposed to be for - to express my opinions and insights on particular subjects; and this seemed like a good candidate for a response ...
So here we goes my best attempt....
Rudolf opens his post with the following:
"One of the real limitations of BizTalk server (design issue) is the lack of details for when things go wrong"
Now I am not sure what he means by this but I disagree with this statement.
BizTalk provides EXCELLENT support for when things go wrong. The tools are all there you just need to go looking in the right places.
New to BizTalk Server 2006 is the excellent BizTalk Administrator Console. This is really your one stop shop for your BizTalk environment. In previous versions of the product this functionality was seriously lacking and we needed to rely heavily on HAT and on the brilliant tools provided by the community; such as the "BizTalk 2004 Administration Management Tool" written by our very own local boy, Paul Somers. But thankfully this is now a thing of the past, I have not yet come across and administrative type requirement that I could not do with the Administration Console. The Admin Console is the cockpit or flight deck of your BizTalk environment providing you with detailed insights into all your applications, active messages, suspended messages, etc. It allows you to access the body of all messages and view the promoted properties etc.
That's all fair and well if you're sitting watching the Admin Console all the time; but what if you're not that masochistic and you prefer to be doing other things with your spare time than hitting F5. Well, fear not ! BizTalk has great support for a number of operational management applications, including SCOM. With the BizTalk pack loaded you have access to all sorts of metrics and events that you can build actions on. You want to know when a message is suspended, no problem. You want to know when a send port could not deliver a message, no problem. Whatever you want it's there for you, and if by some miracle it isn't you can always write your own stuff for SCOM.
Rudolf mentions that he'd like the original filename of a file message that was suspended and shows how to retrieve this info from the message box; nice idea but I have a few issues with this. Firstly, i try NEVER to dig around in the MessageBox. This things is central to the entire way BizTalk works and any work inside this is more than likely not supported by Microsoft and is not guaranteed to work the same way in future versions. It's like popping the bonnet of your Ferrari and fiddling around with the complicated wiring and plumbing of the engine ... um, no thanks!
What if you have a BizTalk deployment that has multiple messageboxes? Do you need to know where to go look for your messages?
What is the sole purpose of the messagebox? It's a central temporary store where messages are published for subscribers to consume.
So how long does a message stay in the messagebox? Depending on your exact setup, only very briefly. Messages are delivered, consumed and they're gone. Well ok, not exactly true ... The body of the message is discarded and the context is moved off to the tracking database. Even the tracking db is not a permanent store for messages, because it is best practice to prune this thing else it can grow really really big quickly. So assuming your messages don't get suspended they don't stay in the messagebox very long.
Ok, Rudolf is talking purely about suspended messages, so what happens to these? Well if they're Suspended (Resumable) then the body of the message is held in the messagebox and his solution works quite nicely. But surely there is a better way of doing this instead of digging around in the BizTalk internal organs. Well, I believe there is ...
What about enabling failed routing and creating an orchestration that subscribes to failed messages. This orchestration can then access the original filename from the context, has access to the body of the message and can something with it; Like returning it to sender for correction, or emailing an information worker, or dropping it into a Sharepoint list ready for human intervention? The possibilities are endless and the nice thing about this solution is that you will not clutter up the Administration Console with all these suspended messages lying about ....
Without knowing the complete problem being faced by Rudolf I cannot say whether my solution would suffice or not, but the point that I am trying to make is that BizTalk, like anything, is merely a tool and it is up to you to decide how best to use it's (extensive) set of features in your specific scenario.
It is great to see local guys blogging on BizTalk topics ... it means the product is finally starting to find purchase in the local marketplace and is starting to rise up to where it is destined to be .... </salespitch> 
I'd love to hear your thoughts / comments / flames / other suggestions on how to accomplish the same thing.
Disclaimer: Please note; this is in NO WAY an attack on Rudolf (I don't even know the guy) or the way he is doing things, just merely my insights into what he wrote, the problem he faced and an attempt to come up with a potential alternative.