Help Center

Du hast noch keinen HubEngine Account?

Du möchtest einen HubEngine Plan konfigurieren?

Marini Systems Trainings - Businesswoman during presentation in board room.

Academy

Erlerne gefragte Skills im Bereich Datenintegration und -management.

Typ: Doku
Komponente: HubEngine
Bereich: Funktionen

HubEngine: 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.

Eine HubEngine Relation bezeichnet die Zuordnung eines Datensatzes aus System A zu einem Datensatz aus System B. Somit ist eine Relation ein ID-Pärchen.

Under the tab "Relations" you can manage the relations of the selected plan. Search for, download, upload, share or delete relations.

Relation Store aktiviert

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.

Fall 1: KEINE Datensätze, die sich auf das gleiche Objekt in der realen Welt beziehen, vor erster Synchronisierung in beiden Systemen möglich

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:

System A

ID Mail Name
1 john@info.com John
2 jane@info.com Jane
3 thomas@info.com Thomas

System B

ID Mail Name
A mary@info.com Mary

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.

Unidirektionale Synchronisierung

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

ID Mail Name
A mary@info.com Mary
B john@info.com John
C jane@info.com Jane
D thomas@info.com Thomas

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:

ID System A ID System B
1 B
2 C
3 D

Bidirektionale Synchronisierung

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:

ID System A ID System B
1 B
2 C
3 D
4 A

System A sieht folgendermaßen aus:

ID Mail Name
1 john@info.com John
2 jane@info.com Jane
3 thomas@info.com Thomas
4 mary@info.com Mary

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

Fall 2: Datensätze, die sich auf das gleiche Objekt in der realen Welt beziehen, vor erster Synchronisierung in beiden Systemen möglich

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:

System A

ID Mail Name
1 john@info.com John
2 jane@info.com Jane
3 thomas@info.com Thomas

System B

ID Mail Name
A john@info.com John
B jane@info.com Jane
C mary@info.com Mary

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:

ID Mail Name
A john@info.com John
B jane@info.com Jane
C mary@info.com Mary
D john@info.com John
E jane@info.com Jane
F thomas@info.com Thomas

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:

ID System A ID System B
1 A
2 B

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:

ID Mail Name
A john@info.com John
B jane@info.com Jane
C mary@info.com Mary
D thomas@info.com Thomas

Relation Store deaktiviert

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.

System A - Tracking_A

Event_ID_A Contact_ID Mail_ID Date Creation_Date
E_A1 1 M1 05.03.2022 09:19:14 05.03.2022 09:21:37
E_A2 2 M1 05.03.2022 16:42:49 05.03.2022 16:44:26
E_A3 3 M2 07.03.2022 19:54:35 07.03.2022 19:55:59

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.

System B - Tracking_B

Event_ID_B Contact_ID Mail_ID Date Creation_Date
E_B1 1 M1 05.03.2022 09:19:14 05.03.2022 20:00:56
E_B2 2 M1 05.03.2022 16:42:49 05.03.2022 20:00:57
E_B3 3 M2 07.03.2022 19:54:35 07.03.2022 20:00:45

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:

System B - Contacts

ID Mail Name ID_A
A mary@info.com Mary 4
B john@info.com John 1
C jane@info.com Jane 2
D thomas@info.com Thomas 3

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

Warum wird kein Relation Store benötigt?

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.
Event_ID_A Contact_ID Mail_ID Date Creation_Date
E_A1 1 M1 05.03.2022 09:19:14 05.03.2022 09:21:37
E_A2 2 M1 05.03.2022 16:42:49 05.03.2022 16:44:26
  • 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.
Event_ID_A Contact_ID Mail_ID Date Creation_Date
E_A3 3 M2 07.03.2022 19:54:35 07.03.2022 19:55:59

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.

Weitere Dokumente aus den Bereichen

Bereich: Funktionen

Deine Frage - Wir antworten gerne

Hast du bereits geprüft, ob deine Frage nicht schon beantwortet wurde?

Häufige Fragen und Antworten, die sich im Laufe der Projekte ergeben, veröffentlichen wir im Help Center. Die Wahrscheinlichkeit, dass die von dir gesuchten Informationen dort zu finden sind, ist hoch. Falls deine Fragen dort noch nicht beantwortet wurden, nehmen wir uns sehr gerne die Zeit für die Beantwortung. Sende uns dazu ein Support Ticket.

Menü