Last week was really busy forme, I was packaging everything for traveling back to Kigali . At least now, I get time to write a couple of blog posts . I am seating in WA Dulles airport, waiting for the plane that take me to Brussels; I am waiting almost for the whole day and I can now summarize what I’ve done on OpenMRS during last week .
My GSoC project is again about Sync: “Data synchronization is a new OpenMRS feature allowing synchronization of data amongst a set of loosely networked servers. Such ability to exchange data is essential for operation of EMR system in rural areas where connectivity amongst sites maybe unreliable yet the need for timely centralized collection and analysis of data from remote sites exists.”
The synchronization feature was designed in a parent-child hierarchical model, to allow data to flow from from remote sites to more central parent and vice versa . A parent OpenMRS server can have many child servers and child can have only one parent . At synchronization, a child server send new change-sets to its model (SYNC REQUEST) and receives all new change-sets from the server (SYNC RESPONSE) . This can be done either via the web or with a disk drive (file) that can be carried over the parent while the child is off-line and the parent will also issue an off-line sync response to carry back to the child . The sync via file doesn’t mean that you have to move physically to the place where the the parent server is installed ; OpenMRS is a web app and any where you can access the parent app you can sync your off-line child !
There are two additional changes on the OpenMRS data model that synchronization does :
1) synchronization_* tables are added to the data model for storing sync settings & configuration and they also store the temporary sync import/export records .
2) GUID indexes : to ensure data exchange between different OpenMRS systems, the ID fields are not enough to identify a record because there are from different MySql installations, so the GUID index columns are added to all data that can be sync-ed .
My actual project’s main aim is to provide an automated way of creating a new sync node(i.e.child) and provide the appropriate user interface . This was done in manual process and required much administrative knowledge. When creating a new sync node(i.e.child) you had to:
- register newly created child with parent
- back up parent server DB and move the backup to the new child server
- restore parent’s DB
- assign new server sync ID
- change any server identifying information from parent to child (i.e. form entry server URL)
- test sync connection between parent and child and finally establish periodic sync schedule
In order to achieve these project I have to start from the actual sync code . As last year I was commiting to the synchronization-admin-ui branch, I think I am going to commit to it even for this project . So I started by resolving few issues in the actual code and I merged the synchronization_bidirectional branch to the sync-admin-ui branch so that all sync changes after last GSoC be available to the sync-admin-ui . This was not a simple task because the sync_bidirectional branch also merges from trunk .
I just used Subclipse merge feature and I let both the old and new versions of code be there then I removed the old revisions where it was necessary and, sometimes I had to use a piece of regex in order to be fast .
For example, Subclipse should form somewhere two blocks of code with different versions and limit them with
<<<<<<< .working
//Code
=======
// Code
>>>>>>> .merge-right.r7385
Then in that case I used the following regex and replaced it with an empty space in order to keep the merger-right version of the code
(<<<<<<< \.working([\x00-\xFE]*?)=======)|(>>>>>>> \.merge-right\.r7385)
This is how I merged and it’s working perfectly .
My next step now is to find out a way of cloning the MySql database from the parent DB and apply it to the new child instllation automatically . If you have more ideas about how to achieve this, please leave your comments .
