Earlier this week I downloaded a CTP of BizTalk 2006, the first public build to be stabilised against the RTM version of the .NET 2.0 runtime. I’m doing a fair bit of work with BizTalk 2004 at the moment so I was interested to see what improvements they had made in the product.

This wasn’t my first attemped install of BizTalk, I had tried to do it three months ago when I got my hands on some very early bits – the installation hung on my machine, so hopefully this time around I would get further.

Installation

The real test for an installation of BizTalk is whether or not you can go through an installation and get it right without reading the absolute latest version of the deployment guide. I actually did quickly skim it just to see if anything jumped out at me – nothing did so I kicked off the installation.

The installation process has been revised a little bit and I liked the way that it went and downloaded the pre-requisites from Microsoft directly. That was always a pain previously – having said that, if you are installing BizTalk 2006 into a secure environment you are probably going to need to get the pre-reqs manually anyway since you will probably not be able to connect out to the Internet.

There were no complaints during the installation process but after it was all up and running I noticed that a number of SQL jobs were failing. The reason was that I installed using my domain user account onto my laptop which usually doesn’t have a connection to the domain controller – so SQL was essentially saying it couldn’t run the job because it couldn’t verify who I was.

It may be been in the deployment guide but I think next time I install I will use a local account to avoid that particular issue.

Administration Tools

One of the first things that I noticed was that the contents of the program menu for BizTalk had changed. Most notably, the Deployment Wizard wasn’t there.

The configuration wizard had run automatically after the installation so all the databases were set-up, and it is worth noting that it has been given a bit of a face lift, unfortunately I think they took the bandages off too early and it has caused some scaring.

The tool itself is functional and gives you a lot of feedback about the health of the configuration and I am looking forward to having my first serious configuration issue and seeing how this tool helps me out. For now, I just want to point out a few UI-related things to the developers or PM behind this tool.

• Don’t use a tree view as the navigation tool, it is so last century, do something like they do in the Windows XP Control Panel with the collapsable regions and hyper-linked navigation style. If you did that you could probably get rid of the menu strip and tool strip.
• Don’t give the form a sunken edge.
• Make the form resizable.

Before I move onto the new administration tool I need to point out that the Health and Activity Tracking tool hasn’t been given a face lift, although that didn’t worry me too much because all the functionality that I wanted from it has been moved into the administration tool – thats right the Administration Tool is now a read/write view over your BizTalk deployment! Lets have a look at the UI for the new administration tool.

Man – thats slick! Lets have another look just for good measure!

Ooooh! Gives me goosebumps! The tool is looking remarkably similar to the Enterprise Manager from SQL Server 2000. Under the covers it is actually using the new Microsoft Management Console 3.0 technology which introduces explicit support for managed code developers.

A few years ago I was asked to produce an MMC snap-in for the older MMC 2.0 technology and after about a week of trying to do everything that I wanted I decided to knaw off my arm and get out from underneath the mountain of COM interop code.

Hopefully developers who are producing server applications will use MMC 3.0 to provide administrative interfaces to their software – even for line of business applications. Having said that – the SQL 2005 team didn’t, but it probably wasn’t ready in time (they had already taken too many dependencies).

Anyway – back to BizTalk 2006! The first thing I noticed about the tool was that everything was much more configurable from the administrationt tool, pretty much everything you could do via the Visual Studio 2005 BizTalk Tool Window you could do here.

One thing I liked as the logical grouping of configuration settings into applications. You can create them directly in the console then load in your assemblies (under the resources section).

Once you load in your assemblies (it gives you the option to load them into the GAC) the Pipelines, Maps, Schemas and Orchestrations sections get filled out. You can then go in and configure the send and receive ports in the tool. I managed to deploy an orchestration via the administration tool in a few minutes without any trouble.

As you can probably surmise from the picture above I moved on to creating an “Enterprise Service Bus” application. I’ve since been advised that ESB is a Gartnerism, and as such I should refrain from using it – especially on this blog (given the name).

Development

So far the in Visual Studio 2005 experience is pretty similar to BizTalk 2004, but I really have tried doing anything fancy yet. Basically I built a quick pub/sub application which does translations to and from a canonical schema. The development phase went fine although there a few issues in deployment, one of them was a layer 8 problem (as Rocky would put it) which Bill was able to help me out with.

One thing that caused me some frustraition was that I was starting and stopping the logical application so it could start processing new messages/schemas that I had defined but it wouldn’t pick up the message type. Initially Bill thought it might be because the BizTalk deployment from Visual Studio did something extra to make BizTalk pick it up - but I have since discovered that I had to restart the host instance for it to be able to pick up the message type.

Once that was sorted it was smooth sailing – I kicked a few tires around inbound and outbound maps including flat file schemas and it all seems to be working OK.

There were a few things that I was disappointed about. One of my other passions at the moment is Team Foundation Server and I’ve been informed that the BizTalk project type won’t be supported by MSBuild natively which means we have to do some MSBuild hacks to get it to execute devenv.com. I hope they reconsider that feature exclusion because BizTalk definately plays in the enterprise space and I would expect it to work with Microsoft’s premier team development tools.

Summary

I think this version of BizTalk is going to be the first one to really get me excited. I always felt that BizTalk needed better administration tools and I think we get it in this version. The streamlined deployment and configuration process will make it appeal more to developers who are used to have good tools for other application infrastructure components like SQL Server.