Daily Archives: March 4, 2006

Canberra Skyfire 18

I decided to jump on a bus to go into the city this afternoon to sit at a cafe and do some blogging and reading. The last time I did this the Civic area was almost completely dead but for some reason the whole place was alive.

Of course, as the title of this post indicates the reason was the Canberra Skyfire event which is basically a big fireworks display that they hold over Lake Burley Griffin. So rather than heading directly home I decided to swing past the lake to see the display.

The place was completely packed but people were being well behaved for the most part. The queues for the port-a-loo’s were something to behold, only to be out done by the queues to the food stalls – I wonder whether there was some kind of correlation here.

I managed to find a spot about two metres from the waters edge by the time the fireworks started. The fireworks themselves were fantastic but the real entertainment was the things I overheard during the course of the event.

  • “Dude, I am so glad I had a joint before I watched this!”
  • “Oh my god, that one made me crap my pants!”
  • “Do you think the fireworks would be hot to touch?”
  • “Look at that geek typing on his laptop!”

In my defence, the person was the same one that admitted to crapping his pants so he shouldn’t be quite so smug.


BizTalk and the HL7 Acelerator

Recently I have been working with the BETA version of the HL7 accelerator for BizTalk Server 2006 (due out real soon now). For those of you know don’t know, HL7 is the horrible specification for the exchange of information between systems that service the medical industry. Just to show you how horrible it is, I thought I would share a sample message:


It should be plainly obvious from this (WTF!!!) that this is a message which notifies us that the patient is being discharged from the medical facility (ADT message group, message ID A03).

The documentation that comes with the accellerator is pretty good but it assumes that you know a lot about HL7 which may or may not be true. In my particular case I am just a .NET developer with BizTalk skills who was asked to map from one HL7 message format version to another.

If you are in the same situation then I share the following high-level steps to you as a way to get this up and running:

  1. Create a solution; there are going to be lots of sub-projects.
  2. Create a common project; which common project you use will depend on the version of HL7 that you are dealing with. If you are dealing with v2.3.1 then you are going to need to use the BTAHL7V231Common Project. Once the project is created you will need to sign it with a strong name key (duh – its a BizTalk project). This project contains the underlying schema types required by the particular version of HL7 that you are using.
  3. Create an empty project; in this project you will add the specific message schemas that you want to work with (for example ADT AD03). When you go to add a BTAHL7 schema a dialog will come up. Select your schema and click finish (twice). Once this is done add a reference to the BTAHL7V231Common project that you created earlier. Once again, remember to sign the assembly with a strong name key.
  4. Repeat steps two and three; for each different version of HL7 that you want to work with and message that you want to map between.
  5. Create an empty project for mapping; while you could put a map inside one of the assemblies that you have created I recommend that you put the maps inside a seperate assembly in this case. Create an empty BTAHL7 project and at a BizTalk map file too it. Add a reference to the two BTAHL7 projects that contain the message schemas AND the common projects that they reference. Go ahead and map the two schemas (this is the fun bit because some schemas are VERY large, and the names differ just slightly. Once again – sign the assembly with a strong name key.
  6. Deploy the assemblies; you should be able to do this without any problems from Visual Studio. If you are using a virtual machine go and have cup of coffee.
  7. Create send and receive ports; using the snazzy new administration tools in BizTalk Server 2006 quickly knock up a send and receive port, I recommend using the file adapter for testing purposes. There isn’t anythinig special about these ports other than they use BTAHL72X[Send/Receive]Pipeline.
  8. Apply your map; apply your message map to the send port and set a BTS.MessageType filter to equal “http://microsoft.com/HealthCare/HL7/2X#ADT_A03_231_GLO_DEF”.
  9. Press the big red button; restart the host instance just for good measure and drop your sample message into the location that the receive port is looking. If you don’t have a sample message grab one from the following location: “C:\Program Files\Microsoft BizTalk Accelerator for HL7 1.3\Samples”.

Its easy when you know how, but unfortunately if its the first time that you are doing it you see quite a few error messages before you see any success.

What about HL7 v3?

Good question. Getting good information on HL7 v3 is pretty hard, the specification really isn’t baked yet and what I have seen scares the crap out of me (possibly more than the sample message above). What they seem to be doing is building a type system on top of XML and then layering the various messaging requirements they have on top of that. To me, this seems like an abuse of XML and is perhaps one of the reasons the spec hasn’t made it out the door.

Personally, I think that the medical industry needs to hand the design of messaging formats over to a number of commercial software vendors (say IBM and Microsoft), in my experience this kind of arrangement ends up with much better results (I cite the pace of development around SOAP vs. XForms as an example).

Selling stuff on your blog.

I was reading the kottke blog and I had also independently come across the “Getting Real” book that the 37signals guys are hawking over on their site. I combined that with the stuff that the guys over at edgeio are trying to get up and realised that we are starting to see a subtle change in the way that technology savvy people are conducting commerce.

During the dot-boom a lot of smart people came out with great ideas that no one really wanted to pay for. They started companies, things got over hyped and eventually the bubble burst.

Today, smart people are coming up with great ideas which people want to pay for, but in order to limit costs they are looking for payment processors which allow them to hawk their goods without going through a whole heap of paper work.

Principles of Team Foundation Server Administration

You are a configuration manager. You have been charged with the responsibility of deploying Team Foundation Server into your enterprise so that project teams comprising of project managers, business analysts, developers, testers and even end users can use it to deliver high quality line of business applications. Are you prepared?

Obviously you have carefully studied the TFS installation guide and read widely about the installation experiences of other configuration managers in your same position and you think you are ready to perform the installation.

Is wish you luck! But have you considered the principles of Team Foundation Server administration?

Principles of Team Foundation Server Administration

In the coming months there are going to be a lot of configuration managers and build masters moving ahead with the deployment of Team Foundation Server into their enterprise. This is a good thing – when deployed and used correctly TFS can significantly enhance the analysis, scheduling, development, testing and feedback processes of development teams, however, if used incorrectly it can be quite frustraiting experience for everyone involved.

With that in mind I offer up these principles of TFS administration which should help guide your adoption and long term satisfaction with the product:

  1. Team Foundation Server is development infrastructure
  2. Beware the build server
  3. Administer the server, not the process
  4. Version control process templates

I firmly believe that the infrastructure requirements of developers in terms of standard desktop images vary greatly from that of a standard user. Typically a developer will need to have administrative rights to their local machine, and sometimes even need to run a server operating system.

With power comes responsibility and one of the important things that development teams need to realise is that Team Foundation Server is development infrastructure, as such it should be carefully managed and not put on a box which is the dumping ground for miscellaneous pieces of software.

When provisioning you should avoid co-locating TFS with any other parts of your computing infrastructure. This makes sense for a couple of reasons – for one you may not be able to install it in the first place, but secondly it creates an unnatural dependency with another system which could limit future options.

Another sugguestion that I like to make to people is giving each team their own build server. While the build server can and likely will (initially) be co-located on the TFS application tier, at some point in a projects lifecycle it is going to want to put something into the build that is going to require a special piece of software or configuration to be installed on the TFS box.

Don’t do it! Remember, Team Foundation Server is development infrastructure and you shouldn’t install miscellaneous pieces of software on it.

Of course, letting development teams run their own build server shouldn’t be a problem in most cases but some configuration managers feel that they need absolute control, which brings me onto my next point – administer the server, not the process.

Team Foundation Server allows teams to choose which process they use – in fact, they allow teams to customise that process to meet their requirements. As a configuration manager don’t get too precious about how people are using version control – provided they aren’t impacting other teams you can let most things slide and be responsive to requests to load new process templates (after testing them in a virtualised environment).

Finally – if you are going to do process template customisation I would strongly recommend that you keep them locked up safely in version control. This has the side benefit of being able to easily evolve your internal processes over time so each team isn’t starting from a (potentially) distant baseline.