I wrote this “How To” article for my company back in the spring, but thought it might be helpful to developers new to BizTalk. For me, troubleshooting schemas is always a pain point; this mostly due to all of the whacky file formats that are out there.
HOW-TO: Troubleshooting Schemas
One of the biggest frustrations about working with BizTalk can be the fact that schemas cannot really be “debugged” in the traditional sense. In the .NET world, we can attach a debugger to a process and break into our source code. While schemas are compiled into CLR classes, the source code is not a VB.NET or C# class: they are XSD files. You can’t put a break point into these files.
What you can do is use the developer tools in Visual Studio.NET to test your schemas, provided that you have a sample…
If you are pulling your hair out wondering why you followed the tutorial to the letter and yet things aren’t working as it should be, here is Lisa’s Blog site [dead link] that provides the latest updates to the tutorial. Please make sure you download the latest tutorial from MSDN site instead of using the out-of-dated one comes with BizTalk installation. Trust me this will save you a lot of sleepless nights.
Download [Dead Link]
This tool examines a BizTalk Server 2006 deployment and generates a list of best practices issues it discovers. I haven’t tried, but it should be very useful if it works as advertised.
Microsoft just released a new document to help developers with programming issues within a BizTalk application.
It contains 120 (!) pages of useful info about every aspect of BizTalk – including best practices. Additional info about the document is available here [Dead Link] and here [Dead Link].
After scanning it over, I found several topics that are still missing. I guess that’s OK as it leaves me with material I can add to this blog : )
Recently, a client of ours was running into a problem with our SQL Receive Locations being automatically disabled by BizTalk 2006. This happened whenever the IT admins took down the SQL 2000 servers and/or the network for maintenance.
Some background: BizTalk 2K6 is used in an integration solution that requires querying a SQL 2K database for new records. Due to requirements of the system, the data needs to be pulled every 15 seconds.
The problem is when BizTalk receives 5 errors in a row trying to retrieve data from the SQL data source – when this happens, BizTalk will disable the receive location and generate an error in the event log.
Since we poll the SQL server every 15 seconds, this results in the receive location being disabled anytime the server or network is down for over a minute. And since the client hasn’t implemented event log monitoring, an entire weekend would go by before anyone would notice that…