9,270
edits
Join the Power Platform Masterclass #2 starting April 23
Advanced sync setup: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 1: | Line 1: | ||
{{Synchronization TOC}} | {{Synchronization TOC}} | ||
Sync Config, also called "advanced sync setup", is an XML configuration file that can be edited in Woodford. It allows you to modify the behavior of SyncDownloader, i.e., the part of synchronization responsible for the download of entity records, e.g. accounts, contacts, orders, ... Typically, this is the longest phase of synchronization. | |||
* | |||
Additionally, Sync Config can be also used to modify the upload order of entities. | |||
== Editing the sync config file == | |||
To update your sync setup file, proceed as follows: | |||
# Start [[Woodford]]. | |||
# Edit an [[App projects|app project]]. | |||
# Select '''[[Configuration]]''' from the '''Project''' menu. | |||
# Click '''Sync Config'''. | |||
# Edit the XML configuration file, then click '''Save'''. | |||
We recommend that you prepare the file in an external editor and verify that it’s a valid XML file (for example, try opening the file in a web browser); then copy the content into Woodford. | |||
[[File:Advanced sync setup.png|600px]] | |||
Alternatively, for advanced testing and troubleshooting on the Windows platform, you can directly edit the file <code>MobileCrm\Configuration\SyncSetup.xml</code> in the project directory. Once you are happy with the results, copy your setup into Woodford as described above, to make it available with all users of the project. | |||
== Why is this important? == | |||
If your organization has a lot of large entities with many records, synchronization can take a long time. By tweaking Sync Config, it may be possible to increase the performance significantly. | |||
* To learn how, we start by explaining the internals of the synchronization process. | |||
* Then we introduce main variables that control sync performance. | * Then we introduce main variables that control sync performance. | ||
* Finally, we | * Finally, we explain how to formally write the setup string. | ||
== What is the SyncDownloader? == | == What is the SyncDownloader? == | ||
| Line 36: | Line 59: | ||
Entities are somehow sorted. The exact criteria are not important. The downloader opens (usually) 3 download threads that work simultaneously - hence the term multi-downloader. Each thread takes the first entity that was not yet downloaded and executes the download of all relevant entity records. When the download is ready, the downloader takes the next free entity. If there is no such entity, the download thread quits. The downloader finishes when all its download threads terminate. | Entities are somehow sorted. The exact criteria are not important. The downloader opens (usually) 3 download threads that work simultaneously - hence the term multi-downloader. Each thread takes the first entity that was not yet downloaded and executes the download of all relevant entity records. When the download is ready, the downloader takes the next free entity. If there is no such entity, the download thread quits. The downloader finishes when all its download threads terminate. | ||
The download of entity records is done in steps, also denoted as pages. By default, one page consists of (up to) 500 records. For example, if we need to download 1253 account records, the downloader issues 3 web requests that return subsequently 500, 500 and 253 records. | The download of entity records is done in steps, also denoted as pages. By default, one page consists of (up to) 500 records. For example, if we need to download 1253 account records, the downloader issues 3 web requests that return subsequently 500, 500, and 253 records. | ||
What happens to the downloaded records? The downloader has a cache, where the downloaded records are stored. All download threads write to the cache and the upper layer (SyncEngine) takes over the cached records and stores them in the database. | What happens to the downloaded records? The downloader has a cache, where the downloaded records are stored. All download threads write to the cache and the upper layer (SyncEngine) takes over the cached records and stores them in the database. | ||
| Line 126: | Line 149: | ||
{{Note|This definition might change in the future.}} | {{Note|This definition might change in the future.}} | ||
== Sync log information == | == Sync log information == | ||