BizTalk Orchestration Designer is the core tool for laying out components representing business processes, and connecting them with logic operations when designing BizTalk applications in Visual Studio. Behind the scene, the XLANG compiler actually generates C# source code before compiling it into .NET assemblies. If you ever want to look under the hood and view the C# source, here is a little trick.
Use your favoriate registry editor (I simply use RegEdit.exe), go to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0. This is where some key properties of Visual Studio 2005 IDE are stored. Add a DWORD value named “GenerateCSFiles”, and set the value to 1.
Next time you launch Visual Studio to open a BizTalk project with orchestration files (.odx file) in it, click on the “Show All Files” icon in the Solution Explorer after the project is built. You will see along side with your abc.odx…
We always enjoy giving presentations and seminars on BizTalk 2006 and show IT and business stakeholders what BizTalk can do for their business. Last week was no exception with our Tallan Fall Seminars series.
In both events we had a focused group of companies/individuals who were mostly looking into adopting better ways to manage their integration processes. The goal of the seminars was to introduce BizTalk and give simple demos on how to perform message integration as well as business process modeling using orchestrations in BizTalk. If you were one of the attendees and want to learn more on how we can help you, contact us for more information.
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 : )
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.
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…