We are preparing a new source of documentation for you. Work in progress!
Data synchronization is the process of establishing consistency among data from a source to a target data storage and vice versa and the continuous harmonization of the data over time.
When you synchronize your app for the first time, you basically download to the device a subset of the server database. This subset refers to the time instant when it was downloaded. (Or synced last time – hence the name LastSync time. Strictly speaking there is no LastSync time for the database as a whole. Instead, each table has its own LastSync time.)
Once you have the data on the mobile device, you can start using it – view, search, but also create, edit or delete. Of course, the same data items may be changed on the server, too.
The purpose of the synchronization is to
- Download server changes to the client
- Upload client changes to the server
- Resolve eventual conflicts
CRM servers have large databases with a lot of data. Users of the mobile app usually need only a small subset of entities, and they don't need the full set of fields for each record.
Types of synchronization
When talking about data synchronization, we sometimes need to differentiate between its various types.
Full vs incremental
- Full synchronization - Creating a copy of all server records on the client. This is used when you launch the mobile app for the first time.
- Incremental synchronization - Server sends its changes to the client; client sends its changes to the server.
Full synchronization can be forced
- for a new customization (using Woodford)
- for selected entities (using Woodford: edit an app project, select an entity from the Project menu, set Synchronization to Always Full Sync)
- by the client (Setup form > Delete Data)
Full synchronization of an entity is needed when you enable an entity in Woodford, or enable a field in an already enabled entity. In these cases, full sync is performed automatically, with no additional user or admin action needed.
Full synchronization is also necessary when the security model is changed, for example when you switch the security role of a user, or modify permissions in a security role, or create a new business unit. Such changes require that the full synchronization is triggered manually by user or forced by admin.
Foreground vs background
- In foreground mode, the app displays progress dialog; users must wait until the synchronization finishes
- In background mode, users can use the application freely during synchronization. When both the user and the synchronization process attempt to write to the database at the same time, users will be notified and they have to wait.
When a new customization is available (new app project published from Woodford), the synchronization must run in foreground.
(Settings > Sync Login on/off)
Manual vs automatic
- Automatic synchronization can be periodic or triggered by app start or data change.
The very first synchronization is a full synchronization with some additional steps. Client downloads the following:
- Entity records as specified by the customization (they are saved to the database)
The result is a kind of equilibrium:
- Client has customization that was valid at the time of the last sync.
- Client has a projection of server data (as defined by the customization) that was valid at the time of the last sync.
This equilibrium changes after some time:
- Client changes: User created or edited some data records; some new records were created automatically (for example audit)
- Server changes: Someone modified records on the server.
- Some records might have been changed by both client & server (= conflicts)
- Woodford might have changed the customization.
The next synchronization (incremental) has the task of restoring the equilibrium:
- Upload client changes
- Identify conflicts (based on record modifiedon attribute)
- Resolve conflicts if possible. See Conflict resolution for details.
- Unresolved conflicts are shown in SyncErrors form; respective records are excluded from upload.
- Client changes (except unresolved conflicts) are uploaded to the Server. Records that fail to upload are also shown in SyncErrors form. (Together with the error message.)
- Check for the new customization and try to apply it.
- New customization may change the data model. This is a non-trivial operation and it cannot be performed during a background synchronization (dangerous for user interface), or if there are not-uploaded changes - conflicts or errors (new customization could delete the changed columns).
- In these cases the new customization is ignored and the user will be notified about that. (Next time foreground sync will be forced.)
- If a new customization is available and can be applied => It will be applied.
- Finally, download server changes
Result: A new equilibrium between the client and the server with these exceptions:
- Sync Errors (conflicts, upload failures)
- Possibly waiting customization that could not be applied. (background sync or unuploaded changes)
See Synchronization steps for a detailed technical description of the synchronization process.
Servers involved in synchronization
Resco license server: iservices.resco.net
- external users resolution
- ApplicationVersionCheckService (responsible for update available notifications)
- Dynamics CRM
- CRM4 (deprecated)
- CRM5: Dynamics 2011/2015/365; Online / On premise
- Resco CRM server
- DropBox, Box, GoogleDrive, OneDrive
- Azure cloud storage for attachments