Connectathon Day 1 (and Day 0)

Today (actually yesterday if you want to get technical) was the first day of the IHE North American 2010 Connectathon.  And the day before that was load in.  This is the first year I was here Sunday morning for Connectathon, and I'll tell you that it makes a big difference.

1. You have plenty of time to get your equipment connected to the network, verify connectivity with others and get ready for Monday when the real work happens.
2. You can review your connectathon tests and make a plan to complete them.
3. You can write code uninterupted to fill in any gaps that you may have discovered.

Now for observations on Day 1:
The morning is usually spent dealing with basic connectivity, kudu review, preparing and uploading a bunch of data.  Most of this can be done back in the office or on Sunday.

The first thing most people do on Day 1 is install a hosts file on their machine and configure it to connect to the IHE Connectathon network. This is basic networking. You'd be surprised at the number of people though that don't bother with this step until they show up.  I have a key fob that I circulated with the hosts file, and I gave my teams the spiel on how to succeed (or fail).  I was already set up having been here Sunday.  I must admit though, that more people were ready to go at the start than last year.

There are a couple of things that catch people off guard during this time.  One of them is the proliferation of virtual machines.  If you have a VM, you either need 2 IP Addresses (and most people only ask for one), or you need to know how to configure your VM host.  Most VM hosts provide a way to route network trafic into the VM through Network Address Translation.  This allows the VM to have a completely separate network address from the host, and yet allow the host to act as a network connection to that VM for the outside world to see.  If you don't know how to configure your VM to support that (or if you've never done it before), the best way to deal with it is to count up the VMs, and add 1 to determine the number of IP addresses that you need to request.

The other issue is that many of these systems use multiple machines to complete their work (e.g., a server and an interface engine).  Some folks have assumed that they only need an IP address for the machine that people will be connecting to them with, and that they don't need one for the other servers because they can just send traffic to the separate system.  But, if you are given a DHCP address, guess what?  Systems on the "DHCP network" cannot communicate into the Connectathon network, and visa versa.  So, make sure you ask for an IP address for every machine that's doing real work.

Another thing people spend time on in the morning is installing and testing certificates.  That should already be done during MESA (pre-connectathon) testing, however, there are some good and bad reasons why people are still dealing with that.  The better reasons have to do with configuring new hardware for connectathon after MESA testing, and the worse ones have to do with not completing that testing before you show up.

One of the first interoperability tests performed is time synchronization.  There are two rules here:

1. Set your clock to Central time.  That's where we are after all.
2. Sync up with your time server using SNTP or NTP.

There's a FAQ on how to set up common operating systems for the CT profile on the IHE Wiki.  There are a couple of issues on time syncronization that you need to be aware of.  If you are having problems getting your server to syncronize, this document describes some of the reasons why your clock doesn't sync up right away on Windows.  I suspect you can also use this information to address similar issues on Unix systems.  Basically, systems using NTP slew the clock to get it correct, and it takes a while for things to sync up, but eventually it gets there.  The only way to force them to jump the clock is to stop all syncronization activities, update clocks and start them up again.

 For XDS edge systems, the next set of steps is usually to perform the CONTENT_CREATOR and CONTENT_CONSUMER tests.  Some folks want to get going right away sending documents using XDS, but that is not the best strategy. 

1. Many people are still getting set up and working the bugs out with TLS and ATNA, and starting right off with a Provide and Register transaction will take a good deal of time.  Let others work out their issues first and then work on those tests.
2. Similarly, Registry Stored Query or Retrieve Docuement transactions require that there be some documents to work with, and their just aren't that many to test with initially.

If you are a content consumer, design your application so that there is a debug mode in which you can download documents from KUDU, and process them from local file system.  That's a quick way to knock out a dozen or more tests quickly on day 1.  If you are a content creator, make sure you have a way to write files out to your local file system so that again, you can knock out a half dozen tests quickly.

Of course, if everyone follows these strategies, there will still be no documents to process later in the day.  That's why it's important to have two people assigned to your system.  While one of you is knocking down a double dozen of tests, the other should be working on getting the peer to peer testing working.

BTW:  If you've figured out a way to quickly run several tests, run more than the necessary three.  Why?  Because some of your tests may fail (never of course your own fault).  Running more than the necessary three will ensure you get at least what you need, and will also help others pass their own tests.

One of my favorite things about connectathon is that it's all about getting everything to work.  There's no benefit to you if your competitors fail, because this week, they are your partners.  This week you can solve problems together in a day that would have taken you a month in the field.  Go forth and make it work, your customers and mine will be much happier!