Recently, a company in the process of implementing BT 2006 within their enterprise asked me for a recommendation regarding best practices for a pre-existing usage scenario they were seeking to accommodate using BizTalk. This company receives, on a reoccurring basis, a variety of disparate inbound flat file business documents which, at present, are processed into their suite of business applications using SQL Server DTS. While the interchange with this company in question has CERTAINLY inspired folks at BlogBizTalk and Tallan to start developing a whitepaper comparing and defining best-practice usage and design considerations for implementing SSIS (or equivalent ETL tool) and BizTalk both in scenarios of consonance or autonomy, a few much more immediate considerations arose for my address.
One such very much more low level consideration was that for the handling of the disparity of received file formats. My understanding…
In the previous post we started creating the c# class that implements the interfaces needed to develop a custom BizTalk pipeline component. In this post, we continue with this sample…
The next interface we will implement is the IPersistPropertyBag interface. Before we do that, we need to add two generic utility methods to read to & write from property bags. A property bag is an object which can persistently save its properties. MSDN provides more info on the Microsoft.BizTalk.Adapter.Framework.PropertyBag class.
#region utility functions
/// Reads property value from property bag
/// <param name=”pb”>Property bag</param>
/// <param name=”propName”>Name of property</param>
/// <returns>Value of the property</returns>
private object ReadPropertyBag(
Microsoft.BizTalk.Component.Interop.IPropertyBag pb, string propName)
object val = null;
pb.Read(propName, out val, 0);
Recently, I had the opportunity to help one of our company’s developers through some training exercises for BizTalk 2006 development. In that process I encountered what I considered to be a fantastic solution sample that I wanted to share with the BizTalk community should anyone be in a similar Trainer / Trainee situation or simply looking for a good example to demo to a technical audience regarding the power of BizTalk messaging and orchestrations. However, should the case be the former, you would be hard pressed to find a solution example that better illustrates to a developer who has a good handle on messaging but needs to be introduced to some of the more complex, advanced topics in Orchestration development.
In the circumstance I encountered, the developer was reviewing the use of envelope schemas for the purpose of dissecting composite messages…
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…