Skip to main content

Conflict handling

Configuring sync conflict resolution strategies​

Because content items can be edited both on iCL Portal and iCL Filler and those two systems are not always connected (iCL Filler could work offline), it can happen, that the same contet item is edited on iCL Portal and iCL Filler. Eventually, iCL Filler will go online and send the changes back to the server (portal). This is when iCL Portal will detect this sync conflict and has to decide how to proceed. As a best practice, central system (in this case iCL Portal) is considered to be the single source of truth. So the default behavior is, that the changes from the client are discarded and the content item will only contain the changes that were applied on the server.

While we strongly recommend to keep this default setting on all content types, in some scenarios you may want to specify that the data from the client actually is of more value and should therefore be kept in case of a sync conflict. This strategy is called ClientWins This can be configured by adding the following "syncConflictResolution":"ClientWins" attribute to the content type's json definition.

note

Note: "syncConflictResolution":"ServerWins" is the default

    {
  "$type": "contentType",
  "name": "gebaude",
  "displayName": "Gebäude",
  "canBeInspected": true,
  "titleFieldName": "bezeichnung",
  "icon": "fa-building",
  "filteredSynchronization":true,
  "syncConflictResolution":"ClientWins",
  "fields": [...]
  ...  
}

This will then be shown the following way in the content types list of iCL Portal

Tracing sync conflicts and their resolution​

In case you are interested in when a sync conflict was detected and how it was resolved, you can enable sync conflict logging on iCL Portal.

This basically logs at level INFO whenever there is a sync conflict, and will tell you which users created the conflict and how it was resolved: 'A sync conflict in table 'Inspections' row Id=b16ca1de-2750-42d2-b14f-0b49752f14c8 was resolved with 'ServerWins' (client changes by user: 1, server changes by user: 2' Also, it logs the complete rows and which row was discarded at log level DEBUG (aka TRACE). So if your system is configured to log detailed, you will (next to the line above) get the following:

 A sync conflict in table 'Inspections' row Id=b16ca1de-2750-42d2-b14f-0b49752f14c8 was resolved with 'ServerWins' (client changes by user: 1, server changes by user: 2
 client row (DISCARDED): Id: b16ca1de-2750-42d2-b14f-0b49752f14c8 | Title: Landstr. Hstr. 101 client | Closed: 09.10.2019 09:53:42 | Sent: `<null>` | WorkbookId: `<null>` | OwnerId: 2 | WorkAreaId: `<null>` | Result: `<null>` | Properties: `<null>` | TaskId: `<null>` | TenantId: 1 | TimeZoneOffset: 0 | IsDeleted: False | DeleterUserId: `<null>` | DeletionTime: `<null>` | LastModificationTime: `<null>` | LastModifierUserId: 1 | CreationTime: 09.10.2019 09:53:28 | CreatorUserId: 2 | Culture: `<null>` | create_scope_id: b9270033-54fa-4a12-9a22-9299b597cc41 | create_timestamp: 2008 | update_scope_id: `<null>` | update_timestamp: 20191009095342590
 server row (WINS)    : Id: b16ca1de-2750-42d2-b14f-0b49752f14c8 | Title: Landstr. Hstr. 101 server | Closed:  | Sent:  | WorkbookId:  | OwnerId: 2 | WorkAreaId:  | Result:  | Properties:  | TaskId:  | TenantId: 1 | TimeZoneOffset: 0 | IsDeleted: False | DeleterUserId:  | DeletionTime:  | LastModificationTime: 09.10.2019 09:53:42 | LastModifierUserId: 2 | CreationTime: 09.10.2019 09:53:28 | CreatorUserId: 2 | Culture:  | create_scope_id:  | create_timestamp: 2008 | update_scope_id:  | update_timestamp: 2014
info

To enable this logging functionality, you need to edit the Nlog.config file on each web front-end of iCL Portal. This file lives in iCL Portal's root folder right next to the Web.config file. (e.g. c:\inetpub\wwwroot\iclportal) By default, these messages are only written into the general log files. You can, however also specify, sync conflicts should be logged into a separate log file or even sent by e-mail.

If you look carefully, you can see that you can even configure the logging system to e-mail whenever a sync conflict occurred. For this, just comment out the <target xsi:type="Mail" /> and enter some valid e-mail addresses. Note: as "useSystemNetMailSettings" is set to true, you do not need to configure any SMTP related stuff - it is just inherited from iCL Portals settings.

    <target name="Synchronization"  xsi:type="AsyncWrapper" queueLimit="5000" overflowAction="Discard">
      <target xsi:type="File"
              fileName="${logDir}/${shortdate}_sync.log"
              layout="${longdate}|log:${logger}|thr:${threadid}|${uppercase:${level}}|usr:${abp-user-id}|ten:${abp-tenant-id}|${message}"
              keepFileOpen="false"
              archiveFileName="${logArchiveDir}/{#}_sync.txt"
              archiveNumbering="DateAndSequence"
              archiveAboveSize="5000000"
              archiveEvery="Day"
              archiveDateFormat="yyyyMMdd"
              maxArchiveFiles="7"
              concurrentWrites="true"/>
      <!--<target xsi:type="Mail"
              to="hansi@opti-q.com"
              cc="peter@opti-q.com;nobody@gmx.at"
              from="noreply@iclportal.com"
              useSystemNetMailSettings="true"
              layout="${longdate} ${uppercase:${level}} ${callsite:className=true:includeSourcePath=true:methodName=true} ${message}${newline}"
      />-->
   </target>

Detailed documentation on configuring NLog mail settings can be found here: https://github.com/NLog/NLog/wiki/Mail-target