A Quick Walkthrough of the BizTalk 2006 R2 Upgrade to BizTalk 2009 RTM

Originally posted by Nick Heppleston at: http://www.modhul.com/2009/04/11/a-quick-walkthrough-of-the-biztalk-2006-r2-upgrade-to-biztalk-2009-rtm/

This post is an update to my original documenting the BizTalk 2006 R2 installation to the latest BizTalk 2009 Beta release. This post looks at the RTM’d version, rather than the beta release, of BizTalk Server 2009.

Installing Splash Screen

We start with the now usual Microsoft installation splash-screen, providing options to install BizTalk, UDDI and RFID on this computer. For this walk-though, I’m doing a default install (upgrade) of the existing BizTalk 2006 R2 installation that is present on my VM:

installation-splash-screen

The Upgrade Process

When the installer runs you need to provide the usual licence key and accept the licence agreement itself. Prior to performing the actual upgrade, you will be prompted to confirm the upgrade details, which are shown in the screenshot below.

A few points of interest are at this stage are:

  • All BizTalk Host Instances, the Business Rules Engine Service and the World-Wide-Web Publishing service must be stopped; BizTalk databases must also be backed-up.
  • Several features are not available in BizTalk Server 2009, including: Human Workflow, The BizTalk Deployment Command Line Tool (btsdeploy.exe) and MSMQT – I’m pleased to see that the MSMQT implementation has been dropped and that Microsoft have finally removed BtsDeploy.exe after it was superseeded¬† by BtsTask.exe in BizTalk 2006.
  • A Developer Edition of BizTalk Server 2006 R2 will be upgraded to BizTalk Sever 2009 Enterprise Edition – I don’t know if this is a beta feature or not (i.e. will the same happen with BizTalk Server 2006 R2 Branch Edition?) We are no longer prompted for this in the RTM version.
  • All BizTalk, Rule Engine and BAM databases are upgraded.

upgrade-screen

Prerequisites

Next comes the usual prerequisites screen, with options to automagically or manually install the prerequisites, or install from a previously downloaded CAB file. Interestingly, the beta release only prompted me to download and install the .Net 3.5 Framework – with this already installed on this test VM, I’m now prompted for two further prerequisites: MS SQL XML 4.0 with SP1 and MS ADO MD.Net 10.0.

If you want to download the CAB files before the install, Thiago Almeida has links to the latest versions on his Connected Thoughts blog.

The Upgrade

Before proceeding with the upgrade, you will be presented with an upgrade summary screen as shown below. If you’re happy with everything, click Upgrade.

upgrade-summary

Once you are happy with the upgrade details, the installer will proceed as shown in the screenshot below (I’ve enhanced the screenshot here to show the full upgrade process, so please excuse my Paint abilities):

installation-progress

With the upgrade complete, we now have a BizTalk 2009 Start Menu entry, containing the usual BizTalk Admin Console, BizTalk Server Configuration, Business Rules Composer etc. We also retain a BizTalk Server 2006 Start Menu entry containing a link to the BAM Portal website. We don’t however have a new directory in Program Files, although the contents of this directory have been updated to the BizTalk Server 2009 binaries. I was hoping that this would be resolved in the RTM version, but this doesn’t appear to be the case – possibly a bug?

Comparing an upgrade with a previous BizTalk 2006 R2 installation

Its interesting to compare an upgrade with an old installation: looking through the resources deployed in the BizTalk.System and BizTalk.EDI applications – even though one or two have been removed – of those that remain the assembly versions have not changed. Furthermore, existing custom Applications, Send Ports and assemblies are preserved.

Running existing BizTalk 2006 R2 Applications following an upgrade

Prior to the upgrade I deployed a very simple orchestration-based project and I’m very pleased to see that following the upgrade, this project works exactly the same in 2009 as it did in 2006 R2 – without modification. This is excellent news and means that there is little – if any – work that needs to be done to a 2006 R2 project before migrating to BizTalk 2009.

Conclusion

In conclusion, the upgrade process is very straightforward for anyone experienced with the BizTalk installer – there is no need for re-configuration, however only the BizTalk 2006 R2 elements of functionality that are installed will be upgraded.

Reblog this post [with Zemanta]

XmlAssembler TargetCharset Property Error in BizTalk 2006 & 2006 R2

Update: Tomas Restrepo added a comment to this post in which he explains why this particular ‘feature’ is present – I think its worth repeating here:

…the problem was that the Target Charset property of the assembler actually gets written as two separate elements when serialized to the pipeline XML file, and both must be present for the assembler to actually figure out the encoding to use… So what happens is that the metadata in the actual design time properties for the assembler component only actually represents one of those elements in the serialized format, and this is what the per-instance pipeline configuration dialog uses to ask the user to enter the values. So in essence, the dialog only allows you to edit one of the values and not the other, so you always end up with the component incorrectly configured.

Thanks Tomas!

While researching a post about message encoding in BizTalk, I can across this Microsoft Knowledge Base article regarding the TargetCharset property on the XmlAssembler component – it would appear that if the property is set through the Admin Console, it won’t take effect. This is strange, because this bug appears to have been fixed in BizTalk 2004 SP1, but somehow made it back into all versions of BizTalk 2006 & 2006 R2. Furthermore for BizTalk 2006, Microsoft only offer a work-around rather than a Hotfix which is frustrating.

So, what happens when you attempt to set the TargetCharset property? The default encoding when using the XmlTransmit pipeline – without the TargetEncoding property set – is a UTF-8 encoded Xml message (click on the image for a full-size version):

UTF-8 Encoded Message

If you change the TargetCharset property on the XmlAssembler component of the default XmlTransmit pipeline in the BizTalk Admin console (as shown below), the change is not picked-up and the same UTF-8 encoded message (as above) is returned; in this case, we’re trying to change it to UTF-16:

XmlAssembler-AdminConsole-TargetCharsetProperty

To change the encoding, you must create a custom pipeline and use the XmlAssembler with the TargetCharset property set appropriately, as follows:

XmlAssembler Custom Pipline Component TargetCharset Property

Using this new custom pipeline with the TargetCharset property correctly configured to output UTF-16 encoded messages, we acheive our desired encoding, as follows (click on the image for a full-size version):

UTF-16 Encoded Message

Encoding can also be acheived by setting the XMLNORM.TargetCharset property of the message to be output in an Orchestration Message Assignment shape as follows:

<MessageName>(XMLNORM.TargetCharset) = "UTF-16";

Note, this testing was performed on BizTalk 2006 R2.