/
Sync Flow

Sync Flow

The synchronization flow is triggered when

  1. The user logs in for the first time

  2. The user manually initiates sync.

Synchronization needs an active internet connection to succeed.

Eligible data for sync

Uploads

  1. Entries created via dynamic forms

  2. Analytics data

Downloads

  1. Dynamic forms schema

  2. Form specific localizations

  3. Aggregated data points for dashboards

  4. Static SoS contact information

  5. Map tiles

  6. Routing information

Sequence Diagram

title Offline Sync Sequence participantspacing equal fontawesome f007 User fontawesome f10b Client fontawesome f1c0 "Local Database" as DB fontawesome f233 "Campaign Service" as Api fontawesome f233 "Storage Bucket" as Storage fontawesome f233 "Tile Server" as Tile fontawesome f233 "Routing Server" as Routing frame Offline Sync autoactivation on create User User ->> Client: Sync destroysilent User Client -> DB: GET //access_token// DB --> Client: // alt OFFLINE Client -#redx Api: Sync Request deactivate Api else ONLINE par DOWNLOAD Client -> Api: Sync Request Api --> Client: <align:center>//Form Config, Static SOS data, Form specific Localization,Aggregated\ndata for dashboards, Map boundaries, routing information//</align> Client -> DB: Persist data, form config, \nand locaization strings DB --> Client: // par Map caching Client ->> DB: Clear local map cache deactivateafter DB Client ->Tile: GET tiles for boundary Tile -->(2)Client: // Client ->> DB: Persist tile data deactivateafter DB thread Routing Information Client ->Routing: GET routing information for points Routing --> Client: // Client ->> DB: Persist route data deactivateafter DB end thread UPLOAD Client -> DB: <align:center>GET all entries where \n**isSynced=false**</align> DB --> Client: // Client -> Client: Compile entries into a file deactivateafter Client Client -> Client: Generate file checksum deactivateafter Client Client -> Storage: File Storage --> Client: //File URL// Client -> Api: FileURL + checksum Api -> Api: Verify checksum deactivateafter Api Api --> Client: // Client -> DB: UPDATE entries as synced DB -->Client: // end end autoactivation off

 

Downloads

Dynamic Forms Schema

  1. The schema will be queried based on last updated timestamp.

  2. If a new schema is returned it will overwrite the previous schema.

Form Specific Localization

  1. Localization data will be saved as a dictionary.

  2. The content of the dictionary will depend on the localizations of the form and the field keys.

Uploads

Entries created via dynamic forms

  1. The created data will use client-side generated UUIDs to ensure uniqueness in the system.

  2. The proposed solution is to consolidate all entries into a file (or batched files) and uploaded. Downside is that registration IDs, won’t be synced back to local cache.
    A checksum can be used to verify integrity of the upload.

  3. The sync status will be captured via separate APIs.

  4. A solution was proposed to assign users a batch of system generated IDs while syncing. During registration, these IDs will be assigned to the individuals who are not able to provide a document ID. This solution might render a user unable to register new individuals if they run out of system generated IDs.

Related content

Health Campaigns Flutter Architecture
Health Campaigns Flutter Architecture
Read with this
Login Flow
Login Flow
More like this
HCM-MOZ-IMPL SERVICE API Documentation
HCM-MOZ-IMPL SERVICE API Documentation
More like this
Collections Dashboard
Collections Dashboard
More like this
National Dashboard- National Urban Realtime Dashboard Technical Documentation
National Dashboard- National Urban Realtime Dashboard Technical Documentation
More like this
Home
More like this