Skip to end of metadata
Go to start of metadata

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

Compare with Current View Version History

« Previous Version 5 Current »

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

 https://sequencediagram.org/
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 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.

  2. 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.

  • No labels