Selecting Unknown Nodes in XPath

Originally posted by Nick Heppleston at:

My currrent project can invoke several common web-services that return roughly the same data, but with slightly different sub elements. I have just had a requirement to count the number of these slightly differing elements using a common XPath statement and I’m amazed by how simple it is, so I thought I would share my findings here.

Consider the following example web-service responses (note the common failure element, but different sub-elements):




To determine the number of possible child elements underneath the Failed element with a common XPath statement, we can use one of several wildcards:

  • * – selects any element node
  • @* – selects any attribute node
  • node() – selects any node (irrespective of type)

In our case, we always want to count element nodes, so our XPath becomes:


which returns a value of ‘3’ and ‘2’ from the examples above.

Its Cold, but not quite 1963….

This post is totally off topic, but here in the UK we’re having a bit of a cold snap and this evening my car recorded -10 degrees centigrade:


Ok, so I know that isn’t all that cold for some of you, but for the South East of England (when we barely get below -2 degrees in a good winter) thats pretty darn cold and certainly the coldest I’ve ever seen (but still not quite 1963!)

Reblog this post [with Zemanta]

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

Originally posted by Nick Heppleston at:

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


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):


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.


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]

Happy New Year BizTalk-ers!

2962774902_632da92019 Just a quick post to say Happy New Year to all of the BizTalk community. I was planning on writing about the BizTalk 2006 R2 to 2009 upgrade experience, but I managed to forget my external drive so I can’t start the VM… instead you’ll have a settle with a beautiful picture of York Minster (I’m currently back home in Yorkshire enjoying the New Year celebrations with the family).

I think that 2009 will be a fantastic year for the community with the introduction of BizTalk 2009, Dublin and the whole Oslo experience – plenty to get our teeth into.

For me, I have a few objectives and I feel that if I list them here, there is a chance of me actually acheiving some of them:

  • Get onto the Microsoft qualifications ladder, including BizTalk 2006 R2, WCF and WF.
  • Become a BizTalk MVP and attend the MVP Summit in 2009.
  • Work on an enterprise ESB and EDI project.
  • Get hands on with Dublin and Windows Azure.

and a few personal goals:

  • Travel as much as possible, including a second trip to the US.
  • Get rid of the belly fat, with a possible half-marathon if I can ever learn to run.
  • Gain my PADI Rescue Diver qualification and dive Scapa Flow in Scotland.