Umgang mit Konflikten
Konfigurieren von Strategien zur Auflösung von Synchronisierungskonflikten
Da Inhaltselemente sowohl im iCL Portal als auch im iCL Filler bearbeitet werden können und diese beiden Systeme nicht immer miteinander verbunden sind (iCL Filler könnte offline arbeiten), kann es passieren, dass dasselbe Inhaltselement im iCL Portal und im iCL Filler bearbeitet wird. Schließlich wird iCL Filler online gehen und die Änderungen an den Server (Portal) zurücksenden. In diesem Fall stellt iCL Portal diesen Synchronisierungskonflikt fest und muss entscheiden, wie es weitergehen soll. In der Regel wird das zentrale System (in diesem Fall iCL Portal) als die einzige Quelle der Wahrheit betrachtet. Das Standardverhalten ist also, dass die Änderungen vom Client verworfen werden und das Inhaltselement nur die Änderungen enthält, die auf dem Server vorgenommen wurden.
Obwohl wir stark empfehlen, diese Standardeinstellung für alle Inhaltstypen beizubehalten, können Sie in einigen Szenarien festlegen, dass die Daten vom Client tatsächlich wertvoller sind und daher im Falle eines Synchronisierungskonflikts beibehalten werden sollen. Diese Strategie wird ClientWins genannt.
Sie können dies konfigurieren, indem Sie das folgende Attribut "syncConflictResolution": "ClientWins"
zur json-Definition des Inhaltstyps hinzufügen.
Hinweis: "syncConflictResolution": "ServerWins"
ist die Voreinstellung
{
"$type": "contentType",
"name": "gebaude",
"displayName": "Gebäude",
"canBeInspected": true,
"titleFieldName": "bezeichnung",
"icon": "fa-building",
"filteredSynchronization":true,
"syncConflictResolution":"ClientWins",
"fields": [...]
...
}
Dies wird dann in der Liste der Inhaltstypen von iCL Portal wie folgt angezeigt
Verfolgung von Synchronisierungskonflikten und deren Auflösung
Falls Sie daran interessiert sind, wann ein Synchronisierungskonflikt erkannt und wie er gelöst wurde, können Sie die Protokollierung von Synchronisierungskonflikten im iCL Portal aktivieren.
Dadurch wird jeder Sync-Konflikt auf der Ebene INFO protokolliert, und Sie erfahren, welche Benutzer den Konflikt verursacht haben und wie er gelöst wurde: 'Ein Synchronisierungskonflikt in der Tabelle 'Inspektionen' Zeile Id=b16ca1de-2750-42d2-b14f-0b49752f14c8 wurde mit 'ServerWins' gelöst (Client-Änderungen durch Benutzer: 1, Serveränderungen durch Benutzer: 2') Außerdem wird auf der Protokollebene DEBUG (auch bekannt als TRACE) protokolliert, welche Zeile verworfen wurde und welche vollständig. Wenn Ihr System also für eine detaillierte Protokollierung konfiguriert ist, erhalten Sie (neben der obigen Zeile) die folgende Meldung:
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
Um diese Protokollierungsfunktion zu aktivieren, müssen Sie die Datei Nlog.config
auf jedem Web-Frontend von iCL Portal bearbeiten. Diese Datei befindet sich im Stammverzeichnis von iCL Portal, direkt neben der Datei Web.config
. (z.B. c:\inetpub\wwwroot\iclportal)
Standardmäßig werden diese Meldungen nur in die allgemeinen Protokolldateien geschrieben.
Sie können jedoch auch festlegen, dass Synchronisierungskonflikte in einer separaten Protokolldatei protokolliert oder sogar per E-Mail verschickt werden sollen.
Wenn Sie genau hinsehen, sehen Sie, dass Sie das Protokollierungssystem sogar so konfigurieren können, dass es Sie per E-Mail benachrichtigt, wenn ein Synchronisierungskonflikt aufgetreten ist.
Dazu kommentieren Sie einfach das <target xsi:type="Mail" />
aus und geben einige gültige E-Mail-Adressen ein.
Hinweis: Da "useSystemNetMailSettings" auf true gesetzt ist, müssen Sie keine SMTP-bezogenen Einstellungen vornehmen - sie werden einfach von iCL Portals Einstellungen übernommen.
<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>
Eine ausführliche Dokumentation zur Konfiguration der NLog-Mail-Einstellungen finden Sie hier: https://github.com/NLog/NLog/wiki/Mail-target