I had a tremendously frustrating experience recently configuring BizTalk Server 2006, but I walked away from the situation a little wiser. We wanted BizTalk Server on an Application Server communicating with a seperate Database Server running SQL Server 2005. I have performed multi-server environments before, but the vast majority had been installation and configuration on a single server (BizTalk and SQL Server on the same machine).
Having created the Domain Groups and Domain Accounts which were required, we set about to perform the Custom Configuration. The BizTalk Server 2006 Configuration Helper is a huge improvement when it comes to configuring BizTalk: a much cleaner interface and the ability to configure each service seperately. However, when we attempted to configure the BizTalk Group or Run Time configuration, we consistently saw the Red Warning Icon when we entered our Domain Group Names.
Initially, we were convinced…
Even with all the time I have spent with BizTalk 2004 and 2006, there is one thing that I will occasionally get tripped on – the fact that exported Bindings and Configuration files do not contain passwords.
For security purposes, BizTalk never shows the existing values of any passwords – whether those passwords are entered during configuration, setting up SQL or FTP adapters, etc. Instead all the user will see is ************* (the # of asterisks does not correspond to the length of the password).
So if you export bindings to “save a copy” of the current configuration, don’t forget to track the passwords somewhere. One approach is to edit the exported files and fill in the empty password fields, but this should only be done if you can ensure the xml binding files will be tightly secured.
Here is an example of the password output for a…
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…