Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Projects

Page tree
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 19 Next »

Sync 2.0 is an OpenMRS module accessible at the Home Page


When clicking Sync 2 you are provided with access to Sync2 functionalities

The "Load Configuration" functionality is where you store the configuration for the Sync Module

It can be loaded from a file or edited directly in the application



More detailed info on how the configuration works can be found in Sync 2.0 configuration variables page.

Before running Sync module, it is important to configure as well the AtomFeed module:


Details about the Atomfeed module can be found here: Atomfeed for Sync 2.0

What is important is to make sure all the entities you wish to synchronize are configured in the AtomFeed confguration so:

Only the entities that have property "enabled" set to true will be published as Atomfeed feeds.
In Atomfeed you can also configure Catchment Strategies which enable synchronizing objects with specified geographical data.
It is also needed to configure some global properties:

"sync2.event.handler" needs to be set to "atomfeed", "sync2.local.user.login" and "sync2.local.user.password" are used to set login and password to local Sync OpenMRS instance,

while "sync2.parent.user.login" and "sync2.parent.user.password" are used to set login and password to Parent instance. "sync2.mergeBehaviour" is used to determine the way of solving conflicts

and in "sync2.resource.preferred.client" a default client can be set, "rest" or "fhir"

The main functionalities of Sync Module are "Manual Pull from the Parent" and "Manual Push to the Parent"


When performing "Manual Push to the Parent" on a Child server, all the changes done on the server are being "pushed" to Parent Server.
If the push is successful, you should see


This means that all the changes applied on the Child server should be now on the Parent server as well
Analogically when performing "Manual Pull from Parent" on a Child Server, all the changes done on the Parent Server are being "pulled" to the Child Server


When the pull is successful, all the changes applied on the Parent should be present also on the Child Server
Pulling and pushing can be configured to be performed automatically by setting "enabled" property to true in "push" or "pull" json entities.
The synchronization interval (in seconds) can be set in "schedule" property

The synchronization can be performed automatically when setting sync.push.enabled/ sync.pull.enabled properties in Load Configuration to true and in .schedule set the synchronization interval accordingly


The parent server also has possibility to decide, which children are allowed to push data to it/pull data from it. This is done using the sync.whitelist property

The "instanceIds" parameter contains all the ids of instances that are allowed to perform synchronizing operations
with the current parent server. Empty value means that all children are allowed to synchronize

OpenMRS Sync 2.0 synchronization also allows to solve conflicts that may occur during multiple changes on many instances.
Depending on the setting of "sync2.mergeBehaviour" global property, conflicts can be solved in two ways:

  1. When set to: "sync2.newIsTheBestMergeBehaviour", newer changes are automatically integrated
  2. When set to: ""sync2.restrictConflictMergeBehaviour"


  • No labels