9,400
edits
Documents: Difference between revisions
Jump to navigation
Jump to search
→Technical information
No edit summary |
|||
| Line 92: | Line 92: | ||
* Document headers are stored in the database entity resco_sharepointdoc. Each record describes one document - its file name, path, size... but mainly the lookup to the owning CRM record (resco_regardingid). | * Document headers are stored in the database entity resco_sharepointdoc. Each record describes one document - its file name, path, size... but mainly the lookup to the owning CRM record (resco_regardingid). | ||
* Document bodies are stored separately in the blob storage. | * Document bodies are stored separately in the blob storage. | ||
=== Document synchronization === | |||
Documents are synchronized in a separate step after the sync of CRM records is completed. | |||
The download is organized similarly to attachments: | |||
* Download of document headers from external document server. If you have multiple servers, they are queried one by one. The result of this step is an updated resco_sharepointdoc table containing headers of (non-downloaded) documents. | |||
* Not all known documents need to be downloaded. Woodford admin may use either the [[Configuration#Max_Attachment_Size|Max Attachment Size]] setting or the [[Document filters|BlobStoreFilter]] to determine which documents are downloaded. Non-downloaded documents can be downloaded on demand from UI. Documents that should be downloaded are enqueued in a so-called FileDownloadQueue. | |||
* The download queue works in parallel to the above step. Its task is to download the document bodies (files). If the download is interrupted, the queue resumes its work at the next sync. Unlike attachments, asynchronous document download is unsupported. | |||
The upload phase is conceptually simpler: Document changes (creations/deletions) are uploaded one by one. | |||
=== Caveats === | |||
Documents may consume large portion of device memory. Tips: | |||
* Use MaxAttachmentSize setting or BlobStoreFilter to limit needed storage. | |||
* To measure the used document storage (need to be done on Windows) go to the [[Log_files#Finding_physical_files_in_Windows_versions_of_mobile_apps|%APP_DATA% folder]], then subfolder blob, then subfolder resco_sharepointdoc. | |||
[[API call]] consumption | |||
* Some calls are needed for document headers. (Exact specification is server-dependent.) | |||
* Each downloaded document requires 1 call. | |||
Dynamics SharePoint integration | |||
* Dynamics lately added another SP-related entity: sharepointdocument - used internally by Dynamics for presentation purposes. | |||
Woodford admins might be tempted to enable this entity, but this would be pure overhead - Resco apps do not use it. | |||
(Moreover, for MCRM versions prior to v12.2 this entity causes sync failure. (Because it does not have the rowversion field.)) | |||
Too many GetList calls | |||
* Applies to SharePoint with old ListService API. If you use SharePoint for many purposes, you might end up with 10K+ lists and the sync might get penalized by long delays (up to several hours per sync!). While Resco apps offer some tricks for this problem, the simplest and best solution is to start using the REST API. This eliminates GetList calls altogether. | |||
Root document locations | |||
* Document locations are hierarchical. Resco apps require that you have a root location for each entity type which allows SharePoint attachments. For example, you need to have a location for "accounts". If there's such a location, MCRM can create location for any particular account record. It does so by creating a subfolder with the name <record_name>_<record_id>. | |||
In the opposite case, Resco Mobile CRM refuses to create SharePoint attachments for the account entity. | |||
== Additional resources == | == Additional resources == | ||