All synchronization will be initiated by the ChildreChildren, independent from the direction that data is transmitted.
|name||Sync 2.0 Network.gliffy|
The diagram above gives an overview of a typical Sync network composed of a Parent server and multiple Child nodes synchronizing with it.
|name||Sync 2.0 - Pull from Parent|
Push from Child
The push model will be used for pushing data from Children to the Parent node. Push is also done in three steps:
|name||Sync 2.0 Arch - Push from Child|
The diagram below illustrates a general overview of the Sync module architecture. Note that components might be simplified and in the real implementation split into multiple pieces. It is shown from the more interesting perspective of a Child. Note that each Child can also act as a Sync Parent.
|name||Sync 2.0 Arch - Pull Workflow|
- Architecture of push workflow
|name||Sync 2.0 Arch - Push Workflow|
Things to note:
- Each Child can also act as a Parent
- A sync module has two feed reader instances - the local feed reader and the Parent feed reader. The local feed reader is reading the local feed and triggers a push to Parent. The Parent feed reader reads the Parent feed and triggers a pull from Parent.
- SyncPushService and SyncPullService put together the business logic for pushing and pulling
- The SyncAuditLogger is responsible for maintaining an audit of Sync operations in the database
- The SyncResourceManager delegates to either the FHIR client or a REST client, based on the data type and whether a FHIR method is possible. The underlying transfer operation should be transparent to clients.
- SyncPullService uses either FHIR services from the FHIR module or database persistence to save the data locally