Relation Store

Der Relation Store der HubEngine enthält die Relationen, welche dem Plan zugeordnet sind. Du kannst die Relationen verwalten, wenn du einen Plän öffnest und den Reiter „Relationen“ auswählst. Wie du die Relationen verwaltest, erfährst du in diesem Tutorial.

Dieser Beitrag erläutert, in welchen Fällen der Relation Store aktiviert oder deaktiviert wird. Falls du noch nicht wissen solltest, was eine HubEngine Relation ist, dann lies dir den oben verlinkten Beitrag zuvor bitte durch. Dieser Beitrag setzt das Verständnis der Definition einer HubEngine Relation voraus.

Der Relation Store kann zu Beginn bei der Einrichtung eines Plans aktiviert oder deaktiviert werden. Um die Funktionsweise des Relation Stores zu erläutern, unterscheiden wir bei aktiviertem Relation Store zwei Fälle.

Wir synchronisieren Personendaten, uni- oder bidirektional spielt keine Rolle, von System A zu System B. Wichtige Annahme hierbei ist, dass in beiden Systemen KEINE Datensätze vorliegen können, die sich auf das gleiche Objekt in der realen Welt beziehen, in unserem Fall auf die gleiche Person. Das heißt, es liegt kein Datensatz in beiden Systemen, der die gleiche Person, z.B. Jane Doe, beschreibt.

Wir nehmen an, dass das Eindeutigkeitskriterium in den Systemen das Feld „ID“ ist und nicht die E-Mail-Adresse! Das heißt, wir legen bei der Synchronisierung jeweils das Feld „ID“ als Identifier fest für System A und B. Die Ausgangslage in den Systemen ist wie folgt:

Wichtig: Wenn wir nun basierend auf der ID synchronisieren, legen wir alle Datensätze aus System A in System B an und umgekehrt!

Das ist jedoch gewollt, da wir keine möglichen Dubletten anlegen, da eine Person als Datensatz ENTWEDER in System A ODER System B besteht.

Wir würden folgendes in System B erhalten – bei unidirektionaler Synchronisierung von A -> B:

Wir legen die Datensätze aus System A in System B an, da noch keine Relation besteht. Mary mit der ID „A“ aus System B wird keine Relation in der Relationstabelle erhalten, da wir unidirektional von A zu B synchronisieren. Folgende Relationstabelle entsteht:

Wir legen die Datensätze aus System A in System B an, da noch keine Relationen bestehen. Gleiches gilt in die Gegenrichtung. Wir legen die Datensätze (in unserem Beispiel nur ein Datensatz) aus System B in System A an, da wir eine bidirektionale Synchronisierung einrichten. Folgende Relationstabelle entsteht:

System A sieht folgendermaßen aus:

System B sieht genau gleich aus wie bei der unidirektionalen Synchronisierung.

Wir synchronisieren Personendaten, uni- oder bidirektional spielt keine Rolle, von System A zu System B. Wichtige Annahme hierbei ist, dass in beiden Systemen Datensätze vorliegen können, die sich auf das gleiche Objekt in der realen Welt beziehen, in unserem Fall auf die gleiche Person. Das heißt, es könnte vorkommen, dass eine Person als Datensatz in beiden Systemen gespeichert ist.

Wir nehmen an, dass das Eindeutigkeitskriterium in den Systemen das Feld „ID“ ist und nicht die E-Mail-Adresse! Das heißt, wir legen bei der Synchronisierung jeweils das Feld „ID“ als Identifier fest für System A und B. Die Ausgangslage in den Systemen ist wie folgt:

Wichtig: Wenn wir nun einfach synchronisieren basierend auf der ID, legen wir Dubletten an!

Wir würden folgendes in System B erhalten – bei unidirektionaler Synchronisierung von A -> B:

Wir legen Dubletten für John und Jane an, da wir das Eindeutigkeitskriterium „ID“ gewählt haben. Da das Feld „Mail“ nicht eindeutig in den Systemen ist, können wir es als Identifier nicht wählen. Die Dubletten kommen zustande, da in der HubEngine noch keine Informationen hinterlegt sind, welche Datensätze aus beiden Systemen zusammengehören (dies wird als Relation im Relation Store gespeichert).

Wie lösen wir das Problem? Vor der ersten Synchronisierung werden Relationen per CSV-Datei in den Relation Store hochgeladen. Die Datei muss manuell erstellt werden. Die Relationen müssen eine 1:1-Beziehung haben. Wir laden folgende Tabelle hoch:

Wenn wir nun synchronisieren, werden keine Dubletten angelegt, da die HubEngine vor der Synchronisierung im Relation Store die Zuordnung der Datensätze nachschlagen kann. Wir erhalten ordnungsgemäß in System B:

Es gibt Fälle, in denen eine Deaktivierung des Relation Stores sinnvoll ist. Das häufigste Beispiel ist die Übertragung von Event-Logs oder Transaktionsdaten. Es werden also Daten nur einmalig übertragen, da sie sich nach Erstellung nicht mehr verändern, wie z.B.:

• Öffnen einer E-Mail
• Ausfüllen eines Formulars
• Klick eines Links

Zur Verdeutlichung nehmen wir folgendes Beispiel: Das Öffnen einer E-Mail. Wir übertragen die Daten von System A („Tracking_A“) zu System B. Wir übertragen in ein Custom Module („Tracking_B“) in System B. Wir können nicht in das Kontakt-Modul übertragen, da 1:n-Relationen  zwischen Contacts und dem Custom Module bestehen müssen. Einem Kontakt können n Events, z.B. das Öffnen einer E-Mail, zugeordnet werden.

Wir erweitern Fall 1 um die zwei oberen Module: Tracking_A und Tracking_B. Tracking_A enthält folgende Daten, während Tracking_B noch keine Datensätze enthält.

Nun übertragen wir unidirektional Tracking_A -> Tracking_B. Dementsprechend sieht Tracking_B nahezu identisch aus. Der einzige Unterschied besteht in der beim Anlegen eines Datensatzes vom System vergebenen ID, also in System A Event_ID_A und in System B Event_ID_B.

Wir erinnern uns, dass die Kontakte aus System A und B bereits unidirektional synchronisiert werden (Fall 1). Das Kontakt-Modul in System B ergänzen wir um das Feld ID_A, das die ID aus System A enthält:

Jetzt kann eine Zuordnung in System B zwischen den Modulen Contacts und Tracking_B über die IDs Contact_ID und ID_A erstellt werden.

So weit die Grundidee der Datensynchronisierung- und übertragung. Wir übertragen unidirektional aus dem Modul Tracking_A. Die IDs, welche in der HubEngine als Identifier festgelegt werden für die Synchronisierung, sind in diesem Fall die Felder Event_ID_A und Event_ID_B. Wir übertragen den Datensatz, ein Event, nur einmalig, da sich der Datensatz nicht mehr ändern wird. Dementsprechend muss die HubEngine nicht mehr erneut anfragen, ob sich ein Datensatz geändert hat und diesen synchron halten.

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 Creation_Date indiziert.

• 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 E_A1 und E_A2. Diese werden zu System B übertragen und dort neu angelegt.

• 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.
• 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 E_A3. Dieser wird zu System B übertragen und dort neu angelegt.

Jetzt wird deutlich, weshalb keine Relationen benötigt werden. Da sich das Änderungsdatum (Feld Creation_Date) in Modul Tracking_A in System A garantiert nicht ändern wird (das Event ist abgeschlossen), kann ein einmalig übertragener Datensatz nicht erneut übertragen und angelegt werden – Dubletten anzulegen ist durch die gegebene Datenstruktur ausgeschlossen. Daher benötigen wir keine Zuordnung zu den Datensätzen im Modul Tracking_B, also keine Relationen. Der HubEngine Plan wird mit der Option „create only“ konfiguriert.