Documents in Resco Mobile CRM (SharePoint, DropBox, Google Drive, OneDrive) – a technical deep dive – Part 2

In Part 1 we’ve established the basic terminology when discussing the use of documents in Resco Mobile CRM and described how they’re presented in the apps user interface. In this post we’ll take a closer look at document filtering, viewing, editing, storage and safety.

3. Document filtering

The documents are primarily downloaded during the synchronization. Because the external storage (e.g. the SharePoint server) may contain Terabytes of data, Woodford admin has the possibility to define document filters.

<?xml version="1.0" encoding="utf-8"?>
<BlobStoreFilter>
<FilesFilter>
             <Quota>1000000000</Quota>
             <MaxFileSize>100000</MaxFileSize>
</FilesFilter>
</BlobStoreFilter>

Above is an example of a trivial cloud document filter that says:
a) MaxFileSize: Do not download cloud documents larger than 100K.
b) Quota: Stop downloading when the total size of all cloud documents exceeds 1GB.
Here is a more complex example:

<?xml version="1.0" encoding="utf-8"?>
<BlobStoreFilter>
 <FilesFilter>
             <Quota>1000000000</Quota>
             <Filters>
              <BlobStoreFileTypeFilter>
                          <FileSuffix>jpg</FileSuffix>
                          <MaxFileSize>1000000</MaxFileSize>
              </BlobStoreFileTypeFilter>
              <BlobStoreFileTypeFilter>
                          <FileSuffix>*</FileSuffix>
                          <MaxFileSize>100000</MaxFileSize>
              </BlobStoreFileTypeFilter>
              </Filters>
 </FilesFilter>
</BlobStoreFilter>

The filter above specifies the quota and additional conditions:
a) Download jpeg images up to the 1MB size
b) Any other file type is limited to 100K size
It applies to cloud documents, however, you can filter CRM attachments (notes) as well. Here is an example:

<?xml version="1.0" encoding="utf-8"?>
<BlobStoreFilter xmlns:xsd="https://www.w3.org/2001/XMLSchema"
 xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
 <FilesFilter/>
 <AttachmentsFilter>
              <MaxAttachmentSize>300000</MaxAttachmentSize>
              <NotSyncingAttachmentsFor>
                <string>contact</string>
                <string>campaign</string>
              </NotSyncingAttachmentsFor>
              <EntityFilters>
                <EntityAttachmentsFilter Entity="annotation" AttachedTo="account">
                            <MaxFileSize>150000</MaxFileSize>
                            <Filters>
                              <BlobStoreFileTypeFilter>
                                           <FileSuffix>jpg</FileSuffix>
                                           <MaxFileSize>50000</MaxFileSize>
                              </BlobStoreFileTypeFilter>
                              <BlobStoreFileTypeFilter>
                                           <FileSuffix>doc</FileSuffix>
                                           <MaxFileSize>100000</MaxFileSize>
                              </BlobStoreFileTypeFilter>
                            </Filters>
                </EntityAttachmentsFilter>
                <EntityAttachmentsFilter Entity="annotation">
                            <Quota>-1</Quota>
                            <MaxFileSize>300000</MaxFileSize>
                            <Filters />
                </EntityAttachmentsFilter>
                <EntityAttachmentsFilter Entity="activitymimeattachment">
                            <Quota>-1</Quota>
                            <MaxFileSize>123456</MaxFileSize>
                            <Filters />
                 </EntityAttachmentsFilter>
               </EntityFilters>
  </AttachmentsFilter>
</BlobStoreFilter>

Explanation:

• If there are multiple EntityAttachmentsFilter nodes that apply to given attachment, then all of them must be fulfilled.
• MaxAttachmentSize defines the size limit applicable to all attachments. (Same effect as MaxFileSize in the Setup form.)
• NotSyncingAttachmentsFor is used to specify entity types for which no attachments are downloaded.
• Account annotations are limited to 150K, however there is a stricter limit for *.jpg files (50K) and *.doc files (100K).
• All annotations (except account annotations) are limited to 300K.
• ActivityMimeAttachment’s use custom size limit.

Example 2: Starting with Resco Mobile CRM version 11.1 (Summer Update 2018), you can also utilize a positive condition to filter selected attachments, e.g.:

<AttachmentsFilter>
    <MaxAttachmentSize>100000</MaxAttachmentSize>
    <OnlySyncingAttachmentsFor>
      <string>contact</string>
      <string>account</string>
    </OnlySyncingAttachmentsFor>
</AttachmentsFilter>

Notes:

• Files that do not pass filter conditions are not downloaded. However, these files are listed on the screen and can be downloaded on demand.
• Size “-1” means unlimited. Size “0” means nothing allowed.
• AttachmentsFilter Quota values are ignored at the time of writing. (MCRM 10.1.0.2)
• If you do not have any explicit BlobStoreFilter, MCRM will use an implicit filter that specifies a quota of 4GB and MaxFileSize as defined in the Setup form
• Pay attention that you use one of the forms of the conditions (positive and negative; NotSyncingAttachmentsForm & OnlySyncingAttachmentsForm), but not both. (Formally allowed, but does not make sense

The document filter is the most frequent reason that causes not-downloaded documents. Other common errors are various download failures, such as web communication errors.

Creating the document filter in Woodford

At present Woodford does not offer a dedicated UI for adding a blob store filter. Hence, the system admin has to do it manually:

1. Create BlobStoreFilter.xml file. Double check that it is a well formed xml file (open it in the web browser, for example)
2. Use Woodford to export the project
3. Rename the exported *.Woodford file to a *.zip. (i.e. change its file suffix)
4. Open the zip file
5. Add BlobStoreFilter.xml to root folder of the opened zip file
6. Save the zip file, rename it back to *.Woodford
7. Import the project back into Woodford
8. Publish the updated project so that the changes can be distributed to all mobile users

4. Document viewing/editing details

There are numerous document types: images, Office documents, plain text files, PDF files… or even proprietary formats. However, the question is: Which of these file types can be viewed by MCRM?
The general answer is – it depends on your device: Some file types can be opened directly in MCRM. For the remaining documents, MCRM asks the OS to open the file. The result depends on whether the device has a suitable viewer/editor installed. Hence the general rule is – if you are able to open certain file type on your device, you will be able to do so also from MCRM.
File types that can be viewed directly in MCRM*:

• All platforms: PDF, SVG, HTML, text files, basic image files (jpg/jpeg/jpe/jfif/png/bmp)
• Windows Store: common media formats (mp4/mp3/m4a/wma/wmv/waw), additional image formats (gif/tiff/tif)
• Windows Desktop: gif files
• Android: gif files, media files (mp3/m4a/amr/aac/mid/xmf/mxmf/rtttl/rtx/ota/imy/ogg/wav/mp4/3gp/webm)
• iOS: documents (doc/docx/rtf/ppt/pptx/xls/xlsx/htm/html/xhtml), audio (aac/m4a/mp3), video (mp4/mov/mpv/3gp)

File types not listed above require an external viewer.
Document editing is supported partially – on Android and Windows Desktop platforms. iOS and Windows Store versions do not support document editing.
*) In-app preview is usually realized in web control.

5. Document storage and Safety

Documents are usually stored in the blob storage.*
Documents at rest are as safe as any other MCRM data – entity records, attachments etc. More precisely, they are stored encrypted and can only be opened by MCRM. The Woodford admin has enough tools to warrant MCRM data safety and this warranty extends also to document files downloaded to your mobile device.
Documents at transit refers to the document download/upload. Document safety in this case depends on the communication protocols offered by the server. All file hosting services use https protocol and SharePoint is normally configured this way too. It means documents at transit are safe.
Finally, the data in use. This refers to the question of how safe is the data when being previewed/edited. This is a grey area because a situation that an unencrypted document is used beyond MCRM control may occur. Plus, we also have to differentiate between platforms…
General schema looks like this:

1. A document is decrypted to a temp file.
2. The temp file is passed to the viewer/editor.
3. If the edit action has finished and the file was modified, it is encrypted and saved back into the original store.
4. Sometimes later the temp file is cleaned. (At the time of writing the temp files are latest cleaned at next MCRM startup.)

Platform differences:
iOS: MCRM runs in a sandbox, hence all its data (incl. temp files) are inaccessible to the outside world. Document passed to external viewer lives in the sandbox of that viewer. Hence data in use is considered as safe as is the iOS sandbox itself and the external viewers you use. Note that data at rest is more secure as it benefits both from sandbox security and added MCRM security (encryption, remote device control etc.).
Android: MCRM also runs in a sandbox and similar security conclusions as for iOS apply – with one exception, however: Documents passed to external viewer live as temporary unencrypted files. Hence using external viewers can be considered a security risk.
Windows desktop: No sandbox is used by the platform, hence only MCRM security features apply. Temp files containing unencrypted source documents (even those passed to the in-app viewer) are not secured in any way.
*) Notes can be optionally stored in the main application database, if the Woodford admin decides so. However, this is rarely a good idea – mainly because of decreased database performance.
Coming up next week, we will examine the details of how Resco Mobile CRM works with file hosting services, especially SharePoint which is commonly integrated with Dynamics 365/CRM.