Synchronization Conflicts

Users can work offline when no server connection is available.

The request is then stored on the device as an uncommitted request and the changes are applied in the local database. When a server connection is re-established, CRM.pad automatically sends the uncommitted requests to the server and updates the data in the Aurea CRM database.

However, when a request cannot be committed the server returns an error. In this case:

  1. The error is stored locally and the request is marked as blocked.
  2. This request's changes are reset locally (i. e. changed data is not available for the user anymore when searching or viewing data – both offline and online).
  3. All dependent uncommitted requests (i. e. changes to the same record and new child records) are also blocked and are not available for the user anymore.
  4. The user is informed about the synchronization conflict and can try to fix the problem.

Conflict Handling - Example

In the following example, creating a record results in a conflict and the error messages are displayed in CRM.pad:

  1. A new order for a company is added containing two delivery dates on the same day.


  2. If a server connection exists, an error occurs:


    The application's server log file shows a Duplicate-Key-Error thrown by Aurea CRM's business logic.

  3. If no server connection exists, this error message is not displayed as CRM.pad does not check this occurrence. CRM.pad accepts this record in offline mode and the user can even add further order items. After entering the data, the record is probably displayed.


  4. When CRM.pad is online again, the Sync conflict(s) are shown in the application menu.


    The record created previously is not included in the order list anymore.

  5. If the user taps on the Sync conflict(s), the conflict's error message is displayed:


    In addition to the error message, also the info area, the action (e. g. new) and whether a dependent process (e. g. quick add for offer items) exists are displayed.

  6. The user can either click on Discard changes (the data is removed) or click on the conflict to fix it (in the example by changing the second date and saving the record again). Child processes are also automatically executed (and hopefully do not return another conflict).

Conflict Handling for Complex Server Requests

If your server requests are large and combined with complex business logic, they may take a long time until the server returns the commitment to the client. If the client does not receive or cannot process the commitment from the server (e.g. due to of the network connection loss), data inconsistencies can occur as the client tries to resend the request.

The following logic was implemented to solve this problem:

  1. The client numbers each request and sends the numbers to the server.
  2. The server stores each request number for each device and the IDs of the last request's affected records.
  3. If the client sends a request number that already exists on the server, only IDs of changed records are transferred.
  4. If the server request results in a conflict, a new request number is created.

To configure this logic:

  1. Create a new info area with the following fields in the Aurea CRM data model:
    • RequestNumber (type: integer)
    • RequestInformation (type: text [as large as possible])
    • RepId (type: integer)
    • LoginName (type: text, min. 12 characters)
    • ChildNumber (type: integer)
    • ParentKey (type: text, min. 32 characters)
  2. Add a new field group to this info area and define the Edit control as follows:
    Field Function
    RequestNumber RequestNumber
    RecordIds RecordIds
    LoginName LoginName
    RepId RepId
    ChildNumber ChildNumber
    ParentKey ParentKey
  3. Add the field group name to the new System.RequestControl Web Configuration parameter (this parameter is not included in the default configuration).