Die Funktion „Backpersist“ findest du in den Connections eines Plans unter den Advanced Options.
Bei backpersist wird die ID, wenn ein Datensatz im Zielsystem angelegt wird, in ein definiertes Feld zurückgeschrieben. Es gibt drei Optionen bei Backpersist:
- backpersist creation field
- backpersist delete field
- backpersist delete value
Backpersist Creation Field
Über einen Plan wird aus System A in System B synchronisiert. Ein Datensatz aus System A wird in System B angelegt, weil er dort noch nicht existiert. Die ID des Datensatzes in System B wird nach dem Anlegen in System A in das definierte Feld zurückgeschrieben (Backpersist Creation Field).
Backpersist Delete Field
In das backpersist delete field wird ein Wert geschrieben, wenn der Datensatz im Zielsystem gelöscht wird. Der default ist 1. Sofern du einen custom value schreiben möchtest, dann trage diesen Wert in Backpersist Delete Value ein.
Zum Beispiel synchronisierst du von System A zu System B. Wird in System B nun ein Datensatz gelöscht und ist nicht mehr verfügbar, schreibt die HubEngine in das festgelegte Backpersist Delete Field.
Backpersist Delete Value
Hier legst du den Wert fest, der in das Backpersist Delete Field geschrieben werden soll.
Wir synchronisieren unidirektional von System A zu System B. Das heißt, wir legen die Backpersist-Optionen in der Connection von A -> B an.
Zur Veranschaulichung nutzen wir ein sehr reduziertes Beispiel. Die Datensätze von John und Jane werden synchronisiert. Wir mappen die Felder Name und Deleted für die Synchronisierung. Beachte, dass das Feld Deleted in beiden Systemen unterschiedliche Ausprägung hat! Damit lässt sich später die Funktion „backpersist delete“ einfacher veranschaulichen. Das Mapping:
- Name : Name, type = string
- Deleted_In_A : Deleted, type = boolean, Optionen-Mapping: 0 = False, 1 = True
In System A wird über den Integer-Wert 0 und 1 geflaggt, ob ein Datensatz gelöscht ist. In System B wird dies über Booleans.
Die Konfiguration aller Backpersist-Optionen lautet:
| Option | Wert |
|---|---|
| backpersist creation field | ID_System_B |
| backpersist delete field | Deleted_In_A |
| backpersist delete value | 1 |
System A
| ID | Name | ID_System_B | Deleted_In_A |
|---|---|---|---|
| 1 | John | 0 | |
| 2 | Jane | 0 |
Die relevanten Felder sind ID, Name, ID_System_B, Deleted_In_A. ID_System_B ist noch leer. Durch das Backpersist möchten wir genau dieses Feld füllen. Durch die Synchronisierung erhalten wir in System B folgende Daten:
System B
| ID | Name | Deleted |
|---|---|---|
| A | John | False |
| B | Jane | False |
Backpersist Create
Während der Planausführung werden die IDs der beiden erstellten Datensätze zurück in System A geschrieben, in das Feld ID_System_B, welches wir vorher in der Funktion „backpersist creation field“ hinterlegt haben. Daher sieht System A nun folgendermaßen aus:
| ID | Name | ID_System_B | Deleted_In_A |
|---|---|---|---|
| 1 | John | A | 0 |
| 2 | Jane | B | 0 |
Backpersist Delete
Wenn nun ein Datensatz in System A löschst, wird durch die Synchronisierung auch der Datensatz in System B als gelöscht geflaggt. Wenn nun aber ein Datensatz in System B gelöscht wird, kannst du durch die Backpersist Delete Option diesen auch in System A als gelöscht flaggen. Wir löschen John aus System B:
| ID | Name | Deleted |
|---|---|---|
| A | John | True |
| B | Jane | False |
Bei der nächsten Planausführung erkennt die HubEngine nun, dass John in System B gelöscht wurde. Dadurch wird die Funktion Backpersist Delete aktiv. Wir schreiben nun den Wert 1 (Backpersist Delete Value) in das Feld Deleted_In_A (Backpersist Delete Field). Somit ist John auch in System A als gelöscht geflaggt.
| ID | Name | ID_System_B | Deleted_In_A |
|---|---|---|---|
| 1 | John | A | 1 |
| 2 | Jane | B | 0 |