Alise.
I am happy to talk and I am (I think) 14 hours ahead.
Obviously, we proved that the translations were fine and tested the maintenance and housekeeping scripts (we use a menu for Ops rather than the GUI).
Our setup is to have one Cloverleaf site for each hospital site/application and we have one PAS application and three LAB applications sending information to Cloverleaf.
In essence, the business wanted the ability to backout if required and we did not want to be changing NetConfigs ‘on-the-fly’. The business wanted to leave the applications communication until we had been on-line on the new server for one week and then perform migration. This would avoid the migration relying on other support groups/vendors.
The solution was to create Cloverleaf ‘pipe’ and ‘crossover’ sites…
Pipe
A pipe site sits on the ‘old’ server and connects to the new servers ‘real’ Cloverleaf site. The pipe site performed NO processing and just communicated messages to the real site and ACKs back from the real site to the application (we logged message control IDs through which is our ‘standard’).
We used pipe sites for all applications that connected (TCP) with the application as the client.
When one of these applications migrated to the new server, the pipe site was turned off (obviously making sure all messages flowed through)
Crossover
The crossover sites connected to a Cloverleaf ‘data receiving’ site (PAS and LABS) and communicated messages to the other server.
When an an application was migrated, the cross over threads were turned off.
I created scripts to automatically create the cross over sites and, as we had control of the PAS communications, we only needed a few pipe sites which we manually created.
I also created the scripts, called from a web page, to perform the migrations etc.
If you would like to discuss this, we can organise a time to suit – richard.hart@health.wa.gov.au
.
