Sync guide (draft)

Definitions:

• Master: server that is the source of information to be synced with a remote server.
• Source: same as master.
• Remote: server that will received resources from a Master, it holds copies of the resources at the source.
• Slave: for now, a remote can be considered slave of the master. This could change in the future since we might have master-master sync or even slave-slave sync.

1. All servers in a cluster require a default admin/org to be able to login and generate sync tokens or cluster configs.

2. Admin users and default org should not by synced.

3. Because of 2. queries that have author=admin can't be synced, since the admin in remote with the same UID as the local admin won't exists.

• if the query is created by and admin we can consider the admin to be the same on all the cluster and assign the remote admin as author even if it has a different UID as the local admin.
• we can prevent admins from creating queries, since those should be created by accmans or orgmans in an account or organization, but for practical purposes we need admins to be able to create queries for any org.

4. EHRs for the default org should be synced even if the default org is not synced, this is for testing purposes.

• Bootstrap should avoid to generate default EHRs, so the sync do not create EHRs with the same UIDs (111..., 222..., etc.) on the remote.

5. The default accman for the default org should also be unique in the cluster, since we need the accman to create the org.

• We can set the admin user to be the accman/contact user for the default org.
• The issue is if the accman is synced, the remote will receive a duplicated email and won't create the synced accman from the local.

6. TODO: test who OPT sync is woring

• We need to avoid creating duplicated OPTs, since bootstrap loads base OPTs, that works for initial run , but also to reload when a prod server is rebooted.
• Bootstrap should not load default OPTs, since those will be synced with the remote, but this can affect how prod reboot works since we need those OPTs automatically loaded in memory (will exist on the DB but cached to memory)

7. Sync Account

• Will sync an account, it's organizations, user roles, users.
• Will exclude the default admin user and the default organization. Those are the same for all the instances of the EHRServer and are needed to bootstrap the server, not for real usage.
• Roles are not synced since those are static and the same for all the EHRServer instances, so UserRole.role will reference at the local Role instance in the remote, not at the synced Role from source (master).

8. Sync EHR

• Will sync just the EHR
• Needs the Account/Organization to be synced first, since EHR belongs to Organization

9. Sync OPT

• Will sync just the OPT (data + source XML)
• Needs the organization to be synced first since each OPT is associated with an org

10. Sync Contribution

• Will sync Contribution, AuditDetails, and the Versions in the original format in which was committed to the master server.
• Needs EHR to be synced first, since the Contribution is for an EHR.
• Needs OPTs to be synced, since the Compositions reference OPTs that are used to index the compos.

11. Sync Query

• Will sync Query, DataCriteriaExpression, DataCriteriaX, DataGet, QueryGroup
• Needs the organization to be synced first since each Query is associated with an org
• If the QueryGroup with the same UID exists, it associateds the Query with the existing group, if it doesn't exists, the sync creates the QueryGroup in the remote.
• Needs users to be synced first since the Query.author should be an existing user.

12. Sync EhrQuery

• Will sync just the EhrQuery
• Needs Queries to be synced first since EhrQuery references a set of existing queries.

13. Sync Folder

• TBD: we need to add some features to manage folders before finalizing a set of rules for syncing folders.