9,313
edits
Synchronization steps: Difference between revisions
Jump to navigation
Jump to search
→Attachments: Download multiple attachments in one batch
(→Attachments: Download multiple attachments in one batch) |
|||
| Line 417: | Line 417: | ||
=== Attachments === | === Attachments === | ||
==== What are attachments? ==== | |||
In case of Dynamics CRM: | In case of Dynamics CRM: | ||
* activitymimeattachment.body | * activitymimeattachment.body | ||
| Line 454: | Line 454: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
==== How are attachments downloaded during sync? ==== | |||
# Collection: Download of annotation (activitymimeattachment, salesliteratureitem) records. Attribute documentbody is excluded from the download. | # Collection: Download of annotation (activitymimeattachment, salesliteratureitem) records. Attribute documentbody is excluded from the download. | ||
| Line 474: | Line 474: | ||
#: (*) This is actually a fetch of annotation record with given ID, but this time only 1 column is requested - document body. | #: (*) This is actually a fetch of annotation record with given ID, but this time only 1 column is requested - document body. | ||
==== Azure attachments ==== | |||
Dynamics 365 users may store note and email attachments using Azure Blob storage. This storage is much cheaper than storing large files directly in Dynamics. | Dynamics 365 users may store note and email attachments using Azure Blob storage. This storage is much cheaper than storing large files directly in Dynamics. | ||
Using this external storage requires adjustment of the fetches that MCRM normally uses. To support Azure blob storage, set <code>AppSettings.SyncAzureAttachments=true</code>. | Using this external storage requires adjustment of the fetches that MCRM normally uses. To support Azure blob storage, set <code>AppSettings.SyncAzureAttachments=true</code>. | ||
{{Note|This is rather undocumented area. MCRM so far supports annotation attachments. Possibly activitymimeattachment attachments should be included, too.}} | {{Note|This is a rather undocumented area. MCRM so far supports annotation attachments. Possibly activitymimeattachment attachments should be included, too.}} | ||
; How are the attachments stored? | ; How are the attachments stored? | ||
| Line 486: | Line 486: | ||
* ... | * ... | ||
==== Attachments FAQ ==== | |||
What happens to non-downloaded (refused) attachments? | |||
* (For example, those exceeding MaxAttachmentSize) | |||
* These attachments are downloaded on-demand, when the respective form is opened. The app knows that the attachments exist and it displays a download button. | |||
What happens when the sync is aborted during the attachment download? | |||
* Downloaded attachments were periodically (~once per second) removed from AttachmentQueue. | * Downloaded attachments were periodically (~once per second) removed from AttachmentQueue. | ||
* Non-downloaded attachments remain in the queue and will be downloaded during the next sync. | * Non-downloaded attachments remain in the queue and will be downloaded during the next sync. | ||
Asynchronous attachment download | |||
* (If <code>AppSettings.AsyncAttachmentsDownload==true</code>; only applies to foreground synchronization) | |||
* The synchronization engine initiates the attachment download, but does not wait until it completes. Synchronization is gracefully terminated (attachment download is usually the last major step), progress switches to background and users can continue working with MCRM. | |||
==== Download multiple attachments in one batch ==== | |||
Since release 14.2, you can modify the behavior of the sync downloader to combine the download of several attachments into one batch request. (By default attachments are downloaded one by one.) | |||
Limitations: | |||
* Done for Dynamics or Resco Cloud servers and (so far) annotations only. | |||
* Max attachment size to be eligible for batch download is 100K. | |||
* One batch combines attachments with a total combined size of up to 10 MB. | |||
Effect on [[API calls]] (examples): | |||
* If your attachments are predominantly images with an average size of 50K, you may decrease API calls used in attachments download even more than 100x. | |||
* If you typically use PDF attachments with an average size >1 MB, there will be no savings on API calls. | |||
Effect on performance: | |||
* Attachments are binary files downloaded using BASE64 encoding. This makes them weakly compressible. Hence the batch downloader typically won't change the amount of data transferred. | |||
* The second important fact is that the default downloader already employs parallel attachment download and often uses the maximum available throughput capacity. | |||
* Hence, apart from savings in web latency, we cannot expect a noticeable performance increase in general. The exception is the situation when the client data contains a lot of duplicated annotations (can be considered as a design bug, nevertheless it happens). This allows for higher compression of the transferred data and a noticeable performance increase. | |||
How to analyze attachments download: | |||
In the sync log look for these items: | |||
<syntaxhighlight lang="xml> | |||
<Attachments Recv='211' Skipped='1' TotalTim='10563ms' /> | |||
... | |||
<ApiCalls DelPlugin='2' SyncAnalyzer='31' Downloader='30' NNDownloader='3' Images='2' Attachments='54' Total='182' /> | |||
</syntaxhighlight> | |||
In this case, 211 attachments were downloaded in 10.5 seconds using 54 web requests (API calls). | |||
=== BlobStoreFilter === | === BlobStoreFilter === | ||