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]
Advertisements

Handling a Web-Service Null Response: The ‘CreateBodyPart’ Pipeline Component

Originally posted by Nick Heppleston at: http://www.modhul.com/2009/03/11/handling-a-web-service-null-response-the-createbodypart-pipeline-component/

Today I’m releasing a small component that addresses an interesting problem I’ve never come across before – a null response from a web-service.

The web-service in question is provided by a third-party and unfortunately cannot be changed. Their WSDL defines the root response element with a maxOccurs=1 and a minOccurs=0, which allows for a null response to be returned. So instead of a result element with no child nodes as I would expect (below in green):

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="..." xmlns:xsd="..." xmlns:xsi="...">
 <soapenv:Body>
  <GetPendingSalesOrdersResponse>
    <PendingSalesOrdersResult xmlns="..." />
  </GetPendingSalesOrdersResponse>
 </soapenv:Body>
</soapenv:Envelope>

we’re receiving an empty response (note the lack of an element between the <GetPendingSalesOrdersResponse> element):

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="..." xmlns:xsd="..." xmlns:xsi="...">
 <soapenv:Body>
  <GetPendingSalesOrdersResponse>
  </GetPendingSalesOrdersResponse>
 </soapenv:Body>
</soapenv:Envelope>

When the SOAP adapter receives this null response, it creates a message but neglects to create a body part – I presume this is because there is nothing to create it from. As a result, the message fails in both an XmlReceive and PassThruReceive pipeline; when using the PassThruReceive pipeline, the XLANG/s engine throws the following error when it tries to read the body part:

The XLANG/s message has no part at index ‘0’.  The total number of parts found in the message is ‘0’. If you expect a multipart message, check that the pipeline supports multipart messages such as MIME.

To address this problem, I’ve created a very simple receive pipeline component which lives on the receive side of the web-service solicit-response port and interrogates a message to determine whether it has a message body. If a message body is not present, it creates one based on the component properties (which mimic the expected – valid – response from the web-service) allowing the response message to be passed into the Message Box without issue. It a message body is present, it passes the message through unchanged.

The CreateBodyPart Pipeline Component

The component lives in the Decode stage of the receive pipeline and simply detects for the presence of a message body. If the body part is null, a new message part is created using the component properties BodyPartName and BodyPartContent and assigned as the body part of the message, before being passed onto the next stage of the pipeline. The BodyPartName and BodyPartContent properties specify the name of the body part and the Xml you want the part to contain – given that the content of the message is likely to be small-ish (i.e. <PendingSalesOrdersResult xmlns=”…” /> in the example above).

There are a few enhancements that I can envisage for this component already, including the ability to specify whether the part should be a body part – you might just want to create extra parts on the fly, not just a body part; and also the ability to specify the encoding and character set being used with your part content. However, I’ll leave these enhancements for a later day.

You can find binaries and source for the component at Codeplex: http://btscreatebdyprtcomp.codeplex.com/

As a final note, my client is currently running BizTalk 2006 (not R2) and we are running on the out-of-box SOAP adapter. Does anyone know whether this issue is a problem in the WCF-SOAP adapter or the WSE adapter?

Reblog this post [with Zemanta]

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

Originally posted by Nick Heppleston at: http://www.modhul.com/2009/01/04/upgrading-biztalk-server-2006-r2-to-biztalk-server-2009/

In this post, I’ll quickly walk through upgrading a production BizTalk 2006 R2 installation to the latest BizTalk 2009 Beta release.

Prerequisites

The only prerequsite for an upgrade is the .Net 3.5 Framework (link) and the framework must be manually installed before starting the upgrade process. Although the provision for an automagic installation appears to be available, it is not enabled in this beta release.

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. A few points of interest are at this stage are:

  • All BizTalk Host Instances must be stopped and the BizTalk databases 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?)
  • All BizTalk and BAM databases are upgraded.

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. Interestingly, we retain a BizTalk Server 2006 Start Menu entry containing a link to the BAM Portal website. We don’thowever have a new directory in Program Files, although the contents of this directory have been updated to the BizTalk Server 2009 binaries. I’m presuming that both of these are beta issues that will be resolved in the RTM version.

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. There are still a few rough edges that need to be worked on, but this is expected from a beta product.

Reblog this post [with Zemanta]

The BizTalk Ops Team – Maintaining a Healthy, Responsive and Available BizTalk Environment

Originally posted by Nick Heppleston at: http://www.modhul.com/2008/12/22/the-biztalk-ops-team-maintaining-a-healthy-responsive-and-available-biztalk-environment/

One of the things that surprises me about BizTalk installations is, in my experience, the limited support they receive once a project has gone live. BizTalk is a large enterprise product and a dedicated team of BizTalk operational specialists and SQL Server DBA’s should be created for the task of maintaining operational and test environments.

In this blog-post, I’ll run over some of the responsibilities that I believe a BizTalk operational support team need to focus on to maintain a healthy, responsive and available BizTalk environment.

BizTalk Application Maintenance

BizTalk application maintenance relates to all aspects of the environment above SQL Server. Areas of focus for the Operations Team include:

  • Responding to and actioning monitoring software (e.g. MOM/SCOM) alerts, including errors, warnings and performance issues, in a timely manner.
  • Managing suspended instances to ensure that these do not grow out of hand and cause performance problems. Where suspended instances are caused by development bugs, triage and liaise with development to roll-out patches as necessary; where they are the result of misconfiguration, address any problems.
  • Identifying and apply BizTalk Hotfixes to all environments as necessary. A good place to start is the Microsoft RSS feed for BizTalk 2006 KB articles. Note: this RSS feed appears to be time-based and may not always have entries (thanks to Nikolai for pointing this out).
  • Understanding BizTalk throttling and tweaking parameters as necessary based on historical performance statistics and knowledge of the product domain (e.g. does the application need to handle larger volumes during certain times of the year).
  • Ensuring that the TDDS Tracking Service is running and that tracked messages are being moved to the Tracking Database.
  • Maintaining BizTalk Hosts and Host Instances, provisioning and decommissioning as necessary.
  • Maintaining Adapters, installing and installing as necessary.
  • Understanding options for scaling-up and scaling-out of the application tier; perform scaling as required, before performance becomes an issue.
  • Understanding some of the underlying developer-orientated concepts, including subscriptions, pipelines, maps etc.; a good understanding of the Orchestration debugger is also crucial.
  • Becoming one with the MsgBoxViewer tool to identify potential performance issues before they happen.
  • Running the BizTalk 2006 Best Practices Analyser at regular intervals to identify any non ‘best-practice’ issues.
  • Managing third-party adapter tools that interface directly to BizTalk, such as the Covast EDI Accelerator.
  • Maintaining operational documentation, including known issues, fixes and resolutions – a Wiki is an excellent resource to manage this knowledge.
  • Scripting as much as possible, particularly known, reoccurring situations. E.g. WMI scripts to clear-down any ‘harmless’ known suspended instances, such as zombies. The more that is scripted, the less chance of manual error. Scripting can either be performed in PowerShell, VBScript or C#.
  • Maintaining all scripts, bindings and configuration settings in source control to ensure proper versioning. Ensure all environments are updated with the same version of the tools.
  • Performing deployments (and have sufficient knowledge of BizTalk, SQL Server and the product domain to make decisions on deployment issues without having to go back to the development team).

Database Maintenance

This goes without saying, but unless you team maintains the health of the underlying SQL Server database the BizTalk environment will not perform as expected. To maintain optimum health, the team needs to:

  • Ensure that the BizTalk SQL Agent jobs are running successfully and are not running for an excessive length of time.
  • Ensure that tracking data is cleared down using the Purge and Archive jobs and that historical archive data is made available in an offline mode (i.e. on a different SQL Server) for analysis and reporting.
  • Ensure that backups are taken, using the BizTalk Backup job, and that the resulting backup data and log files are verified.
  • Monitor performance of SQL Server environment through a monitoring tool to ensure that the server/s are not exceeding CPU, memory or IO load; scale-up or -out as necessary.
  • Monitor replication performance and/or automagically restore backups to a DR environment, to ensure continuity of service in the event of downtime; respond to any incidents that arise in the restore.
  • Understand what can and more importantly what can’t be done on a SQL Server that is hosting BizTalk.
  • Understand options for scaling out the database tier and in particular, the Message Box; perform scaling as required, before performance becomes an issue.
  • Identify and apply SQL Server Hotfixes to all environments as necessary.

I would recommend that DBA’s also read the excellent Microsoft KB Article How to maintain and troubleshoot BizTalk Server databases.

Disaster Recovery

Disaster recovery is unfortunately often overlooked until it is too late. The Operations team should perform regular reviews and tests of their DR plan to ensure it is upto date and effective. Areas of focus for the team include:

  • Switching the live environment over to disaster recovery at regular intervals (every quarter / every six months) to prove the disaster recovery plan and to give confidence to the business. The switch to DR should be for a short period – 1 to 2 days – during a period of known ‘slack’. Switching to DR should be straightforward and (almost) entirely automated to ensure manual error is minimised.
  • Where there are problems with the plan, refine as necessary. Keep the master recovery document on a Wiki for example, but ensure an up-to-date hardcopy is kept off-site.
  • Ensuring that all members of the team have confidence in the plan and are prepared to invoke it as necessary.

Infrastructure and General Maintenance

There are a number of day-to-day infrastructure and general maintenance tasks that the team will need to complete during the lifetime of an environment, including:

  • Application of Windows Updates as necessary during scheduled down-time.
  • After creating new environments, run the BizTalk 2006 Best Practices Analyser to check for any non ‘best-practice’ issues.
  • Liaising with infrastructure team to ensure environments are correctly built before operation commences, including correct SAN RAID configuration, clustering etc. Work with DBA’s to ensure that the layout of data and log files is correct based on the role of the databases (BizTalkMsgBoxDb vs. BizTalkMgmtDb for example). Ensure elements of the environment (e.g a BizTalk Server / A SQL Server node etc.) are cleanly removed before downtime commences to actioned failed hardware.
  • Liaising with networking team to ensure necessary ports are open on firewalls etc. for traversal of traffic for both the underlying SQL Server Infrastructure and external access.
  • Liaising with security team to ensure correct Active Directory Domain users and groups are created and maintained to ensure a well running system.

For those of you who are a member of a BizTalk operational support team (or as a consultant), are there other recommendations you’d like to share?

Reblog this post [with Zemanta]

A Helpful SQL Server DBA Checklist

Update: As Omer points out in the comments to this entry, the recommendations made in the DBA Checklist mentioned below are in places at odds with the official BizTalk/SQL Server best practices. When reviewing the checklist, please refer to the Microsoft BizTalk SQL Server Best Practices KB article.

SimpleTalk has a helpful DBA checklist for all those BizTalkers who double-hat and manage a SQL Server as-well-as a BizTalk environment. It covers a number of useful topics, including:

  • General best practices
  • High-availability
  • Performance tuning
  • Application coding and design
  • SSIS, Analysis Services, Reporting Services & Service Broker

Plenty of content for both new and experienced DBA’s – well worth a look.

Enhanced by Zemanta