Mobile CRM limits: Performing an application test run
written by Jan Slodicka on April 8, 2015
In the previous post titled Mobile CRM limits. Where are they?, we talked about things that limit the application; such as RAM, storage and Internet speed. If you haven’t read that post yet, we highly advise you to do so.
What we are going to do now is to give Resco Mobile CRM application a test run and investigate the database it created.
Desktop is the best platform for such experiments – all the tools are available for free and the file system is open. (Plus, there’s a security benefit: Your business data won’t be exposed to the public network.)
We assume a good knowledge of Dynamics CRM. A working experience with Resco tools (Mobile CRM client application and Woodford) helps a lot. If needed this and this webinar provide a good explanation of the remote configuration process. (Even if they use an outdated Woodford version.)
You need to have:
- Administrator login to Dynamics CRM server (Woodford creates new entities that are used by MobileCRM client.)
- User login to Dynamics CRM server. Should represent a typical Mobile CRM user.
- Windows desktop where you have administrator privileges
- Woodford installation. If needed, you can install free Woodford trial here
- Mobile CRM desktop installation. Can be downloaded from here
Is the server data safe?
In other words: Is it safe to use the production server for testing?
The test described below will not modify existing server data in any way unless you explicitly edit downloaded data in Mobile CRM application and you send the changes back to the server.
Here are the two ways to modify server data:
- If Mobile CRM app works in online mode: Edit an item and save the changes.
- If Mobile CRM app works in offline mode: Change some data and synchronize. (However, if you delete local data (Mobile CRM>Setup>Delete Data) before synchronization, the server data remain intact.)
So if you execute proper discipline, the server data won’t be modified.
If this assurance is not sufficient, you can go another mile and prevent the app from doing any changes at all. To do so you have to make an extra step: For every entity enabled in the customization, clear the entity write/create/delete permissions. If you do this, application won’t even open any data editor. (All entity records will be grayed out.)
Finally, if you are paranoid about the safety (or because of your business rules), you have one additional option: Don’t use the production server; use your testing environment instead.
Let’s create basic customization*):
- Run Woodford, log into Dynamics CRM as admin.
- Create a new project; let’s call it ‘Test’. Select ‘Standard User’ as project type. Select the user roles that are allowed to log in into Mobile CRM. Press OK.
- Press ‘Edit Project’ button and then ‘Publish Project’ button.
Let’s test the created customization:
- Start Resco Mobile CRM desktop client
- Press the sync button in the title bar, fill in the login data (enter user login to Dynamics CRM) and press the sync button. (Say yes to the question about the old data deletion.)
- Wait until the synchronization completes. You can now open for example the Accounts – you’ll see the data imported.
That’s it. You can exit the Mobile CRM application and check the database.
- Open the file manager of your choice and go to the \Users folder on the system drive. Search for the Mobile CRM folder.**)
- You’ll see the file Database_8_0.sdf. This is the database file used by the Mobile CRM application; you can easily check its size.
- If the Woodford project included attachments, you would see also the sub-folder called ‘blob’ and could determine its size as well.
Notice that although we can “measure the data”, the data itself is encrypted (unreadable). It cannot be even copied to another device because the encryption is device-dependent. (Unless, of course, you switch off the DB encryption in Woodford.)
Let’s move further and create a more realistic data set:
- Run Woodford and open our project. Press the Edit Project button and find the entities node in the tree on the left hand side.
- Disabled (grayed out) entities are not copied to the client device. To enable an entity, select it in the tree and press the Enable button.
- If an entity is open, its fields are shown in a list. To enable a field switch on the check-box on the field left hand side.***)
(Only enabled field are downloaded to the client.)
- Another thing you can change for an open entity is its SyncFilter. Some entities have default filter such as accounts (Exclude inactive records) or emails (Exclude records older than 60 days). Take time to set up the filters that fit to your plans.
- Publish the project, synchronize Mobile CRM application and analyze the data size.
This is an iterative process, during which you enable/disable entities/fields and modify sync filters. After a few trials you should have reasonable data structure****) and an estimate of the space needed on the client device.
*) Customization is a name for Mobile CRM setup. It is stored as a special entity on the Dynamics CRM server, from where it is downloaded by mobile clients. It includes the data schema (which server entities and which fields will be used by the client), SyncFilters (which entity records will be downloaded to the client) and other aspects such as views, forms, charts etc. These items are beyond our interest right now (they do not affect the client storage) and we shall ignore them.
**) Its location is system-dependent. For example Windows7/8.1 use C:\Users\<user>\AppData\Roaming\MobileCRM\.
***) Caveat: QueueItem is a child entity. Its field QueueId points to the parent (Queue) and must be enabled manually. If you forget, MOBILE CRM synchronization fails with “No such column” Sqlite error. Woodford takes care of most parent-child relations so that there are just a few cases you have to adjust manually: ContractDetail.ContractId, ProductAssociation.ProductId, ProductSubstitute.ProductId and the already mentioned QueueItem.QueueId.
****) What does it mean “reasonable”? It is the minimalist data structure that still enables the mobile user to work efficiently. Note a similar Microsoft’s advice for Dynamics CRM for Outlook (which happens to be other CRM client): “To optimize the offline synchronization process… assign all users roles with the minimum access levels and permissions required to perform a job function to help ensure optimized data synchronization to the offline client.”
How to select the user account (security role)
If you think of using Mobile CRM for different user categories then you should read this paragraph.
- Every Dynamics CRM user has security roles assigned, which in turn define the entities and records the user is allowed to see.
- Woodford customization specifies the user role(s) that can make use of a mobile customization.
- Mobile CRM user logs as a Dynamics CRM user. During the synchronization, the Dynamics CRM selects the customization that corresponds to the MOBILE CRM user security role. (If there are multiple suitable customizations, the one with highest priority is selected.)
You see that users having different security roles may see different data sets. Hence the user selection matters a lot in our testing.
You should generally select user account that will see the largest data set. And if you don’t know that, then you should repeat our test for different user roles.
Based on many tests performed on many servers I can only say that the synchronization speed normally varies between 0.5-10 ms/record and the speed 1 ms/record can be considered as very good.
If you have reasonably large data and a good connection you may expect
- No storage space problems on the client device
- Full synchronization to take a few minutes
- Subsequent incremental synchronization to take dozens of seconds
Here are the factors that influence the download speed:
- https compression*)
- Quality of the Internet connection**)
- Data structure (The smaller the data schema, the faster the download.)
- SyncFilters (They determine the count of downloaded entity records.)
- Server responsiveness***)
If you plan to deploy a Mobile CRM solution, you should start with a thorough analysis:
- Collect the information about the client mobile devices, mainly about the free storage.
The more storage is available, the larger data can be deployed on the client device.
- Design optimal client database by using the procedure outlined in chapter 6.
- Test the application on mobile devices.
*) By default IIS will not compress Mobile CRM responses. Here is the solution for CRM 2011 Outlook client which has the same problem.
**) A simple test of the network bandwidth: Measure the download time of a large compressed document. (Network latency is not that important for synchronization.)
***) Server sends entity records in batches – max. 500 records at a time. Mobile CRM downloads 1-3 entities simultaneously, depending on what is possible. In order to get the speed 1000 records/second we need the server responses below 1 sec. I saw response times ranging 0.1 sec to 1+ min.
We provide a few examples that illustrate common Resco Mobile CRM deployments. Download the Resco Mobile CRM application test run: Case Studies to see how the app copes with large databases and slow servers.