Resco Mobile CRM: How Resco implements the offline mode (a technical deep dive) – Part 2/3
I have described the difference between online and offline mode in Resco Mobile CRM client for Microsoft Dynamics CRM in my previous blog post.
As written in there, online mode resembles the work of a web browser, it’s getting data directly from server. Which makes data operations slow, costly and potentially risky.
Offline mode, on the other side, works with data stored in the local database. Hence the data loading/storing is fast and presents no problem at all.
So far, so good.
Online mode looks like a looser.
So why then do you find primarily online clients in the Dynamics CRM world?
BECAUSE WRITING A GOOD OFFLINE CLIENT IS A VERY CHALLENGING PROGRAMMING TASK.
Did you expect this sort of answer? Maybe yes, maybe not. In any case, I’ll try to sketch how Resco MobileCRM implements the offline mode.
Here is a brief summary of the problems involved:
- Data size: SQL server database used by CRM dynamics is often too big (multi GB as a rule) to even think of its replication to a mobile device.
- Security: Transport security is solved by the same means as in the online mode. (https, VPN…)
However, the offline mode must additionally secure the local database. Hence, it is important to understand the security risks involved.
Client data structure consists of entities (database tables) and entity attributes (table columns).
Both online and offline mode use identical data structure, that is a subset of full CRM Dynamics server data structure.
This structure is defined by MCRM remote configurator (a.k.a. Woodford). Woodford is also used to limit the number of records downloaded to the mobile client. Admin achieves this goal by specifying so-called entity Sync Filter that lists additional criteria for entity records to be downloaded to the device.
By applying suitable Sync Filter you can for example:
- Exclude inactive accounts. (SyncFilter for accounts specifies status=0.)
- Exclude appointments older than 30 days. (SyncFilter uses last-x-days operator.)
Final effect of the data design described above is that the size of the downloaded data drops to a reasonable number.*)
Let us mention here the concept called **customization**. It is the setup file created by Woodford that describes MCRM aspects such as:
- Client data structure and SyncFilters
- UI forms and business logic – tabs, controls, workflows…
When MCRM connects (synchronizes) to a particular organization for the first time, it actually downloads and interprets specific customization.
*) It is difficult to specify what is “reasonable” as it depends on the mobile device used, connection speed etc. I’ve seen a customer happily using 500+ MB database storing over 700,000 records.Initial full synchronization took over 10 min, but apart from that the work was fluent and the incremental synchronization was relatively fast.
There are several risks involved, but most of them are common to both offline and online modes, hence we don’t need to discuss them. Full details can be found here.
What we need to talk about is the security of the data stored locally on the device.
(Applies to the offline mode, but may apply to the online mode too – depending on the SyncFilter setup.)
The local database uses strong encryption and a custom database key derivation process.
This means that even if the attacker got the database file and knew the password, he would not be able to read the data. (The database itself is “safe”.)
As in all password-based systems, the main risk presents the password management.*) This risk is even more dangerous, when the data is stored locally.
If the attacker has**) the password, he might be able to start MCRM application***) and read some data from the screen, for example. The only safe option to avoid this risk completely is that the system admin does not allow the mobile users to set up MCRM to remember the password.
If you are paranoid about the security and still would like to use the offline mode, you have an additional option: Configure selected entities (those containing sensitive information) to be “online only”. In this case respective data is not stored on the client device at all, but will be downloaded from the server whenever needed.
*) The password is used to authenticate with the CRM server and plays a role in the database encryption, too.
**) “Has” does not mean “know”. MCRM can be configured to remember the password.
***) The system admin can use a number of tools to make MCRM launching as difficult as possible (wipe, lock, force login… see Security manual)
However, these actions do not provide equal level of security as, for example, the database encryption used.
Click here to continue to Part 3 on synchronization.