To understand the logic of synchronization in the HubEngine, we use an example. We want to synchronize unidirectionally from system A to system B. A bidirectional synchronization behaves basically the same. The only difference is that a collision check also takes place (cf. lower section).
We synchronize unidirectionally: Contacts (system A) -> Contacts (system B). The IDs, which are defined in the HubEngine as identifiers for the synchronization, are in both cases the field ID in the respective system.
The HubEngine works in a simplified way as follows. The plan in this example is triggered every day at 8 pm. The change date is indicated by the field Updated. On 05.03. the following data can be found 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 |
- Execution of integration plan on 05.03.2022 20:00:00. Records with change date > 04.03.2022 20:00:00 (time of last plan execution) & change date < 05.03.2022 20:00:00 (current date) are queried. Thereby we get the records A1 and A2. These are transferred to system B and newly created there.
System B - Contacts
| ID | Name | Updated |
|---|---|---|
| B1 | John | 05.03.2022 20:00:56 |
| B2 | Jane | 05.03.2022 20:00:57 |
- Execution of integration plan on 03/06/2022 20:00:00. Records with change date > 03/05/2022 20:00:00 (time of last plan execution) & change date < 03/06/2022 20:00:00 (current date) are queried. In doing so, we do not receive any records.
On 07.03.2022, the data in system A looks like this:
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 |
- Execution of integration plan on 03/07/2022 20:00:00. Records with change date > 03/06/2022 20:00:00 (time of last plan execution) & change date < 03/07/2022 20:00:00 (current date) are queried. Thereby we get the data record A3. This is transferred to system B and newly created there.
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 |
Bidirectional synchronization
Bidirectional synchronization works according to the same principle as unidirectional synchronization. However, a collision check takes place during each synchronization. It is possible that a data record has changed in both systems since the last synchronization. If this is the case, the more recent data record is prioritized and synchronized.
We bidirectionally synchronize the record of John. The Relation Store holds the relation A1:B1. The plan in this example is triggered every day at 8 pm. The change date is indicated here by the field Updated. The data just before synchronization looks like this:
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.
- Execution of integration plan on 03/07/2022 20:00:00. Records with change date > 03/06/2022 20:00:00 (time of last plan execution) & change date < 03/07/2022 20:00:00 (current date) are queried. We obtain the data sets A1 and B1. Since these are assigned to each other in the Relation Store, a collision occurs. The data set B1 is prioritized because it is the newer one.
Therefore, in system A we obtain:
System A - Contacts
| ID | Name | Updated |
|---|---|---|
| A1 | Johny | 05.03.2022 20:00:17 |