Ok, everybody understands the concept of synchronization – server changes are applied to the client database and vice-versa the client changes are sent to the server. That’s the basic idea and even if I didn’t write it, you would certainly formulate it in a similar way.
I may similarly explain other related concepts; such as the connection, the conflict resolution etc. – you have an a priori idea of these things and that idea is usually correct.
However, the concept “synchronization of server deletes” is rather counter-intuitive. You simply need to have some technical insight to understand what’s going on.
Here is the basic idea:
When the Mobile CRM app is about to download server records it formulates a fetch request such as:
“My name is John Smith. Give me all accounts that were changed within last 60 days.”
The server will reply with a list of accounts that
were created or modified within given period, and
the user John Smith is entitled to read.
Notice that although this protocol (so-called FetchXml protocol) excels in getting records satisfying all thinkable criteria, it is not able to deliver information about the deletes that happened at the server.
To overcome this problem Resco Woodford tool installs special plugin on the CRM Dynamics server that collects the information about specific server actions; such as the deletes.
This information is downloaded and processed during the initial synchronization phase. (I.e. when the progress dialog says “Sync: ServerDeletes”.)
The role of Woodford
As nearly every aspect of the Mobile CRM application, the plugin has to be set up in the Woodford configuration tool, where you have to activate the plugin by selecting entities and actions that will be tracked.
Although we spoke about the deletes so far, there are altogether 3 tracked actions – you will see them in a moment.
No entity is tracked by default. You have to say “I want to track accounts, contacts etc.”
If you don’t do this, the delete information won’t be collected and the mobile client database will possibly contain records that were meanwhile deleted from the server.
However, you should select tracked entities wisely as each tracked action costs time and space. It makes no sense to track entities that are not used on the mobile devices; this will just degrade the server performance.
Whenever CRM Dynamics server executes a tracked action, the plugin adds a new record to the custom entity resco_mobiletracking.
During the synchronization Mobile CRM downloads those resco_mobiletracking records that were added since the last synchronization and interprets them as explained below.
Here is the list of the tracked actions (plugins):
The Delete Plugin collects ID’s of the deleted records. App reacts by deleting listed records from the local database.
The plugin tracking N:N relationship disassociation. App reacts by deleting corresponding records in intersect tables.*)
The plugin monitoring ownership changes. These changes may be interpreted by the application as deletes.**)
*) Here is an example that is often used to explain many-to-many relationships: Authors and Books.
An Author can write multiple books, and a Book can be written by more Authors. Standard reference Book.AuthorId cannot describe this relation, you need a new table AuthorBook with columns AuthorId and BookId. For a book with 2 authors you will find 2 records (associations) etc.
Using CRM terminology, AuthorBook is called intersect table; corresponding CRM entity is called an intersect entity.
CRM Dynamics uses a number of intersect entities: accountleads, competitorproduct, contactorders…
**) If, for example, an email was assigned to a different user, that email might become inaccessible to the mobile user (due to insufficient permissions). In such a case the email has to be deleted from the mobile device.
How long does the synchronization of deletes take?
First of all, it may be an instant action.
This happens when the server delete plugin is not activated or if the deletes at the server happen seldom.
In both of these cases, the Mobile CRM user hardly notices “Sync: ServerDeletes” progress message. (Unless the Internet communication is slow, of course.)
The opposite extreme is obvious. If the server performs bulk actions that involve the deletes, disassociations or owner changes, the server resco_mobiletracking table will blow up and Mobile CRM will process this information for a long time.***)
***) Our latest releases detect this situation and perform full synchronization of impacted tables. This isn’t an instant operation either, but is certainly several times faster than the delete processing.
What to do in case any problems appear?
Make sure you use the latest version of Resco Mobile CRM.
Look for the possible reason in the synchronization log.
Sync log is to be found in the app’s About dialog. Advanced Android/desktop users may look for the file SyncLog.txt in the Mobile CRM data folder.
If you have the log text, look for the string “SyncDeletes”, decode the the text that follows and try to draw some conclusions. For example the log discussed in the next paragraph indicates that the server executes too many deletes (or owner changes, or disassociations).
This fact might be worth of reporting to CRM Dynamics administrator who might be able to take respective measures.
Sample sync log analysis
Here is an excerpt from a real-world log, that was just a little bit shortened:
<Analyze Tim=484 TblsWithManyDeletes: account=3124 annotation=10160 salesorder=10078 UnchangedTbls=28/>
<TblCleared account annotation salesorder/>
Items=10655 Fetches=10 Deletes=8401 Tim=41430/>
This concrete text can be interpreted as follows:
The analysis phase:
Table account has 3124 server deletes, which is considered as ‘too many’. ****) There are other 2 tables with ‘too many’ deletes: annotation and salesorder.
28 tables do not have any server deletes.
The remaining tables (we do not know how many) have relatively small amount of server deletes.
Cleaning of tables that contain too many deletes.*****)
All 3 above mentioned tables were cleared. These tables will be re-downloaded from the server in the later synchronization phase.
Actions done on the local database:
// This many resco_mobiletracking records were downloaded from the server.
// This many server requests were sent to verify whether the owner change should be considered as a delete.
// This many local records were deleted. (Cleaned tables are not counted, of course.)
// The whole ServerDeletes synchronization took 41 seconds.
Examples of other actions that might be reported at an other occasion:
// Server deleted 2 records that were edited on the mobile device since the last synchronization.
// Deletes executed on intersect entities.
Some server tables (account, annotation, salesorder) seem to suffer from bulk delete operations. These tables contain ~23000 deletes and will have to be re-downloaded from scratch. (We could estimate the time lost in re-downloading these tables, but this is beyond the current topic.)
There are other 8400 server deletes that take up 40 seconds to process.
****) Current Resco Mobile CRM version denotes this way the tables with at least 20% of deletes.
*****) In case these table contained changed records, these changes were uploaded to the server by the time the delete synchronization started.