For those of you that have been working with BizTalk for any amount of time I am sure you are well aware of the "The Bloggers Guide to BizTalk" and if so you will no doubt also be aware that there hasn't been one of since v1.8 (June 2006) ... if like me you were getting serious withdrawal symptoms fear not .... IT IS BACK!
What is this thing that has me all excited you ask ...
The aim of The Bloggers Guide to BizTalk is to provide the best of the online content produced by the BizTalk blogging community in an easily accessible format. All the content in the guide has been created by BizTalk developers who wish to share their knowledge and ideas with others in the developer community. The subjects of these contributions and the level of their complexity are varied, so there is information available for those who are new to BizTalk, as well as for advanced developers.
The posts are usually taken directly from the contributors blog, so the writing style of the contributions vary, and there is no guarantee that all the information is free of errors. Any feedback as to corrections can be made by commenting on the original article at the authors blog.
All contributions to the guide are gratefully received, and new contributors are always welcome. |
Check out the latest version (1.9) here
I must just say a BIG thanks to Microsoft for sending me to the annual BizTalk Virtual Technical Specialist Summit; held this year on a cruise liner out of Miami!
I met a bunch of new people from all over the world; including Brian Loesgen (co-author of the BizTalk ESB Guidance), John Brockmeyer (author of the incredible whitepaper on optimising your BizTalk solution), Erik Leaseburg (founder of the BizTalk Rangers team). Be warned though, some of these guys can induce instant brain haemorrhage! But it was really great to meet them and put faces to the blog poster I read all the time.
I learnt a bunch, had an incredible amount of fun, and yes ... believe it or not, worked real hard!
I look forward to VTS Summit '09!
But for now it's back to reality and life in cold SA ....
At last!
The South African BizTalk community has an online home. Head on over to www.biztalkug.co.za where you will be able to find anything and everything related to BizTalk in South Africa.
Go ahead, sign up ... you know you wanna!
PS. a big big big thanks to all that helped to get this site up & running. Nabeel, big up to you man! Thanks! To Telligent for sponsoring us a license to Community Server, thanks very much!
I am currently in Miami for the BizTalk VTS conference but as soon as I get back I will start planning for the next meeting. If anybody has any suggestions for topics you want covered please let me know by posting on the forums on the user group site.
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.