Um die Logik der Synchronisierung in der HubEngine zu verstehen, verwenden wir ein Beispiel. Es soll unidirektional von System A zu System B synchronisiert werden. Eine bidirektionale Synchronisierung verhält sich im Grunde gleich. Der Unterschied besteht nur darin, dass noch eine Kollisionsprüfung stattfindet (vgl. unteren Abschnitt).
Wir synchronisieren unidirektional: Contacts (System A) -> Contacts (System B). Die IDs, welche in der HubEngine als Identifier festgelegt werden für die Synchronisierung, ist in beiden Fällen das Feld ID im jeweiligen System.
Im zeitlichen Ablauf arbeitet die HubEngine simplifiziert folgendermaßen. Der Plan im vorliegenden Beispiel wird jeden Tag um 20 Uhr getriggert. Das Änderungsdatum wird hierbei durch das Feld Updated indiziert. Am 05.03. finden sich folgende Daten in System A:
System A - Contacts
| ID | Name | Updated |
|---|---|---|
| A1 | John | 05.03.2022 09:21:37 |
| A2 | Jane | 05.03.2022 16:44:26 |
- Ausführung des Integrationsplans am 05.03.2022 20:00:00. Datensätze mit dem Änderungsdatum > 04.03.2022 20:00:00 (Zeitpunkt der letzten Planausführung) & Änderungsdatum < 05.03.2022 20:00:00 (aktuelles Datum) werden abgefragt. Dabei erhalten wir die Datensätze A1 und A2. Diese werden zu System B übertragen und dort neu angelegt.
System B - Contacts
| ID | Name | Updated |
|---|---|---|
| B1 | John | 05.03.2022 20:00:56 |
| B2 | Jane | 05.03.2022 20:00:57 |
- Ausführung des Integrationsplans am 06.03.2022 20:00:00. Datensätze mit dem Änderungsdatum > 05.03.2022 20:00:00 (Zeitpunkt der letzten Planausführung) & Änderungsdatum < 06.03.2022 20:00:00 (aktuelles Datum) werden abgefragt. Dabei erhalten wir keine Datensätze.
Am 07.03. 2022 sehen die Daten in System A folgendermaßen aus:
System A - Contacts
| ID | Name | Updated |
|---|---|---|
| A1 | John | 05.03.2022 09:21:37 |
| A2 | Jane | 05.03.2022 16:44:26 |
| A3 | Mary | 07.03.2022 19:55:59 |
- Ausführung des Integrationsplans am 07.03.2022 20:00:00. Datensätze mit dem Änderungsdatum > 06.03.2022 20:00:00 (Zeitpunkt der letzten Planausführung) & Änderungsdatum < 07.03.2022 20:00:00 (aktuelles Datum) werden abgefragt. Dabei erhalten wir den Datensatz A3. Dieser wird zu System B übertragen und dort neu angelegt.
System B - Contacts
| ID | Name | Updated |
|---|---|---|
| B1 | John | 05.03.2022 20:00:56 |
| B2 | Jane | 05.03.2022 20:00:57 |
| B3 | Mary | 07.03.2022 20:00:45 |
Bidirektionale Synchronisierung
Die bidirektionale Synchronisierung funktioniert nach dem gleichen Prinzip wie die unidirektionale Synchronisierung. Allerdings findet bei jeder Synchronisierung eine Kollisionsabfrage statt. Es ist möglich, dass sich ein Datensatz seit der letzten Synchronisierung in beiden Systemen geändert hat. Ist dies der Fall, wird der jüngere Datensatz bevorzugt und synchronisiert.
Wir halten bidirektional den Datensatz von John synchron. Der Relation Store speichert die Relation A1:B1. Der Plan im vorliegenden Beispiel wird jeden Tag um 20 Uhr getriggert. Das Änderungsdatum wird hierbei durch das Feld Updated indiziert. Die Daten kurz vor der Synchronisierung sehen folgendermaßen aus:
System A - Contacts
| ID | Name | Updated |
|---|---|---|
| A1 | John | 05.03.2022 16:21:37 |
System B - Contacts
| ID | Name | Updated |
|---|---|---|
| B1 | Johny | 05.03.2022 18:33:56 |
- Ausführung des Integrationsplans am 05.03.2022 20:00:00. Datensätze mit dem Änderungsdatum > 04.03.2022 20:00:00 (Zeitpunkt der letzten Planausführung) & Änderungsdatum < 05.03.2022 20:00:00 (aktuelles Datum) werden abgefragt. Dabei erhalten wir die Datensätze A1 und B1. Da diese im Relation Store einander zugeordnet sind, kommt es zu einer Kollision. Der Datensatz B1 wird bevorzugt, da er der neuere ist.
Daher erhalten wir in System A:
System A - Contacts
| ID | Name | Updated |
|---|---|---|
| A1 | Johny | 05.03.2022 20:00:17 |