Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

session description

  • session was lead by Dave Thomas (dthomas@pih.org)
  • the sync module is in use by PIH Rwanda
  • more documentation can be found here: Sync Module

setup / overview

  • sync operates on a spoke and hub model (parent server with children)
    • each child needs to initiated with a copy of the parent server's DB
      • this was done through database dumping
      • an alternate option to consider is to copy the mysql files instead of importing/exporting the DB, in order to save import/export time
    • any way to not start out with clones and have some kind of merge done?
      • short answer is no since the records would need to be reconciled
      • the key to doing that successfully is to be able to match up UUIDs, which is a non-trivial task
    • registration is done between the child to parent and parent to children
      • parent server and child servers have a static IP
        • it may be possible to use a dynamic DNS (DDNS) service (e.g. no-ip.org, dyndns.com) to get around this
    • sync process always runs on the child; configured to contact the parent server on a regular basis
      • can we use the parent server as the operational server?
        • yes, this is how it is currently used in PIH Rwanda
        • is there a performance impact?
          • none observed so far
  • configurable settings
    • the amount of time when the child contacts the parent
    • timeout for when the child should stop contacting the parent
    • maximum number of tries for the child to reach the parent
    • whether sync'ed data is compressed or not (which is run through the openmrs configuration which can optionally be gzip)
    • the class of data to be sync'ed
    • at the technical level, it is sync'ing at the level of db tables
      • not able to sync subsets of patients, but this is a feature we'd like to implement in the future
  • prerequisites
    • did we need to beef up our servers for the sync?
      • no, we have our servers running on off the shelf laptops with 3GB of RAM
    • had issues with the servers not being on proper UPS (we used laptops)
      • mysql databases can get corrupted if power is lost in the middle of a transaction
    • what about network firewall considerations?
      • this is done via HTTP post, so either port 80 (HTTP) or 443 (HTTPS)
    • bandwidth
      • our sites are on VSAT and performance has been fine even with all of the outages that we have. sometimes the bandwidth is 1kbps or less.
        • how long do we need to have something up and running in order for the sync'ing to work?
          • dependent on bandwidth, but from our experience, sending 200 records at a time, it takes about 5 minutes to sync
        • this can even be sync'ed via USB key
          • and there won't be duplicates even if it is manually sync'ed by USB and afterwards, the network is restored
        • we will be piloting this on GPRS modems; the issue is not bandwidth, but rather having fixed IP addresses on the children (that are using the modem)
          • however, this may be overcome by using a DDNS service (see above)

functional questions

  • still able to do updates on both the parent and the child?_
    • yes
  • what is the format of what is being sent?
    • xml (serialized java objects)
      • can the XML be consumed by other services?
        • probably possible
  • is it possible to have grandparents? i.e. multiple layers of syncing between children and the parent?
    • theoretically it could be possible
    • sync was built to be a child to parent relationship, where each node will communicate to a parent (if it exists) and its children (if they exist); children don't know about each other.
    • is there any thought about doing a peer-to-peer relationship rather than a hierarchical relationship?
      • this might be something to consider in the future
      • (a concern was raised by an audience member): not sure if this should be perceived as a solution for a national reporting system built off of (child) districts and (grandchild) clinics because of data access/privacy concerns; DIHS should be used instead
      • filtering might help to alleviate this challenge
  • complex obs files able to be sync'ed?
    • may not be possible to do at the current time since it would require so much bandwidth to do
  • 2 vs. 1 way sync
    • it is possible to use the sync module as an info path alternative (in a one directional way)

similar/related efforts

  • run a sync on an android device
    • the android device has a full DB copy
    • it is not made to handle conflicts
    • questions to think about:
      • is there any opportunity to combine the efforts through refactoring?
      • because there has been trouble to get hibernate to run on android, is there any way to remove that dependency from the existing sync module?
  • No labels