Tips & Tricks: synchronizing external changes

by Giuseppe Lanzi on 09/05/2014

By way of greeting you all as we return from our summer break, I’d like to start up the blog again by discussing the Tips & Tricks subject you’ve been the most interested in: synchronizing changes to the database made by external software.

As you know, the Document Orientation sync service uses two different methods depending on the conditions: full or partial. When the user syncs for the first time (or if they haven’t done so in a long time), a full sync is run, in which all documents are read from the corresponding database tables and sent to the device. When the user only needs to receive the most recent changes, a partial sync is used, and in this case the data is read from the ZZ_Sync table. The framework writes the changes to ZZ_Sync every time changes are made to a document with the Synchronization flag enabled.

The problem arises when other software is making changes to the same database, because in this case no one is in charge of writing the changes, and therefore they won’t be sent to the device during the next partial sync. To get around this, we must figure out how to update ZZ_Sync correctly.

To do so, it’s not a good idea to update the database directly, because it’s complicated and we’d have to know the right syntax. A better approach is to use the same framework, simulating a save. In this example project, we achieve the desired result for the Product class by using:

  1. The Product.LastExternalChange class property.
  2. The HandleExternalChanges procedure.
  3. The Product.BeforeSave event.

The LastExternalChange property contains the answer to the question “when did the external application change the product in the database?”. This is the only real requirement that must be met. Unless you answer this question, it’s impossible to know which products must be handled. In our case, the value is set by the SimulateExternalChange procedure with an update to the table. You can test this immediately: launch the project applications and synchronize the mobile app. Then use the SimulateExternalChange button in the web application and sync again; you’ll see that this second change is ignored.

In the HandleExternalChanges procedure, we take all the products changed by the external applications, set the inserted property to true, and set a skipupdating tag with a value of -1. Then we save the product.

In the Product.BeforeSave event, if the skipupdating tag is set to -1, we simulate the save by setting the skip parameter to true.

Thanks to inserted = true, the product is viewed as requiring insertion into the database, and thanks to skip = true, the save is not actually performed. In this particular case, the framework will still write a new change in ZZ_Sync containing all the document properties, including those changed by the external application. Use the web application’s HandleExternalChanges command, and then sync the mobile app again to see the result.

Happy syncing everyone! 🙂

What would you like to see addressed in the next edition of Tips & Tricks?

  •    Optimizing synchronization of documents with BLOB properties.
  •    Document locks, a practical example.
  •    How to have users with multiple domains in the sync.
Loading ... Loading ...

Leave a Comment

Previous post:

Next post: