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…
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…
I am a late bloomer to blogging, but have realized that I do in fact have something to say on such subjects as BizTalk Server and SharePoint Technologies – and how to make these things work. So, if you share an interest – stay tuned.
However, not all blog entries need be original, right? So let’s start with someone else’s good idea.
Today, I tried to find some solutions for initializing a Multi-Part Message within an orchestration. We’ve all called a SQL Stored Procedure from within an orchestration. But why can’t you simply construct the Request/Response message with a Message Assignment Shape? It appears that this is not easy to do, because of the nature of multi-part messages. One can use a map to construct the message by simply setting default values within he map, but this seems like egregious overkill.