# Konzepte
Dieser Abschnitt beschreibt die Konzepte, die für die Synchronisierung der Daten in ELO Sync verwendet werden.
# Pipeline
Für die Synchronisierung wird derzeit eine zweistufige Pipeline verwendet, bei der mehrere Middlewares registriert werden.
Jede Stufe der Pipeline muss abgeschlossen sein, bevor die nächste Stufe gestartet wird. Damit soll sichergestellt werden, dass sich verschiedene Änderungen in mehreren Systemen nicht gegenseitig beeinträchtigen können und somit weniger Komplexität bei der Verarbeitung dieser Änderungen erforderlich ist.
Ein großer Nachteil dieses Ansatzes ist, dass alle Änderungen im Speicher gespeichert werden, bis die nächste Stufe bearbeitet werden kann, was zu einem höheren Speicherverbrauch führt.
Im Allgemeinen funktioniert die gesamte Verarbeitung für die Synchronisierung von oben nach unten, d. h. Ordner werden vor ihren Inhalten verarbeitet, wodurch sichergestellt wird, dass alle Änderungen an Ordnerinhalten darauf vertrauen können, dass ihre übergeordneten Ordner bereits vollständig synchronisiert sind.
Die erste Stufe umfasst die Analyse und Durchführung von Änderungen, die nicht die Löschung betreffen. Die Daten aller synchronisierten Systeme werden abgerufen und mit den gespeicherten Metadaten in ELO Sync verglichen, um festzustellen, welche Änderungen seit der letzten Synchronisation vorgenommen wurden. Alle erkannten Änderungen werden in Modifikationen umgewandelt, die für eine spätere Ausführung geplant werden.
Werden Löschungen gefunden, so werden diese zunächst normal wie andere Änderungen eingeplant, dann aber in die zweite Stufe der Pipeline übertragen. Dies ist notwendig, um zu verhindern, dass nicht gelöschte Einträge gelöscht werden. Ein Beispiel: Ein Benutzer verschiebt eine Datei von Ordner A nach Ordner B und löscht dann Ordner A. Wenn die Löschung nicht zu einem späteren Zeitpunkt geplant wird und gewährleistet ist, dass die Eltern vor ihren Kindern synchronisiert werden, würde beim Löschen der Ordner A (einschließlich der verschobenen Datei) gelöscht.
Weitere Einzelheiten finden Sie im Kapitel Pipeline.
# System
Ein System beschreibt eine Software, einen Server oder einen Teil davon, dessen Daten synchronisiert werden sollen.
Dabei kann es sich um ein SaaS-System wie OneDrive oder SharePoint Online oder um ein lokales ELO Repository handeln.
# System Provider
Eine Softwarekomponente, die die Implementierung für den Zugriff auf ein System bereitstellt. Wird nur manchmal verwendet, wenn eine Delegation der Systemerstellung erforderlich ist.
# Collection
Collections sind eine Teilmenge der Inhalte eines Systems, die einen abstrakten Zugriff auf diese Inhalte ermöglichen.
Einige Systeme verwenden mehrere Collections (vor allem, wenn die Inhalte nicht eindeutig identifizierbar sind) oder nur eine einzige Collection.
Die genauen Einzelheiten hängen von den vom System bereitgestellten Daten ab.
# Subcollection
Der Begriff Subcollection wird für Collections verwendet, die in einer anderen Collection enthalten sind oder auf die von einem Element in einer Collection verwiesen wird.
# Synchronization Entry
Ein Synchronization Entry oder einfach Entry ist eine abstrakte Einheit, die eine Sache beschreibt, die zwischen mehreren Systemen synchronisiert wird.
Ein Entry hat keine eigenen Daten, sondern ist die Obermenge aller Items, die zusammen synchronisiert werden.
Wenn es notwendig ist, ein Entry eindeutig zu identifizieren, wird empfohlen, die Identität der zugehörigen Datenzuordnung zu verwenden. Diese Identität bleibt so lange erhalten, wie die einzelnen Elemente des Entrys existieren.
# Synchronization Item
Ein Synchronization Item beschreibt ein bestimmtes Item in einem synchronisierten System. Dabei kann es sich zum Beispiel um eine Datei oder einen Ordner handeln, muss es aber nicht. ELO Sync könnte auch abstraktere Daten wie E-Mails oder Chats synchronisieren.
# Data Mapping
Das Data Mapping beinhaltet die Metadaten eines synchronisierten Entrys. In der Regel bedeutet dies, dass das Data Mapping Hash-Werte oder ähnliche Elemente enthält, damit Änderungen zu einem späteren Zeitpunkt erkannt werden können.
Die Daten im Mapping können lange gespeichert werden und dürfen daher keine potenziell geschützten Informationen (wie PII) enthalten. Dies ist ein weiterer Grund für die Verwendung von Hash-Algorithmen (oder vergleichbaren Verfahren) zur Speicherung aller Daten in dem Mapping.
# Structure Mapping
Die structure mapping eines Entrys speichert seine relative Position in der synchronisierten Struktur.
Im Gegensatz zum Data Mapping werden im Structure Mapping keine Daten gehasht oder verschlüsselt, da diese bei späteren Synchronisationsläufen wieder rekonstruierbar sein müssen.
# Field
Auf die Daten der synchronisierten Elemente wird über Fields zugegriffen. Jedes Field ermöglicht den Zugriff auf eine einzige, nicht aufteilbare Information über das Element.
Nicht aufteilbar bedeutet in diesem Fall, dass die Synchronisation diese Information vollständig oder gar nicht synchronisieren soll. Das bedeutet nicht, dass die Informationen nicht aufgeteilt und zusammengeführt werden können.
# System Field
Die System Fields sind ein Sonderfall, der von allen synchronisierten Systemen bereitgestellt werden muss, um die Synchronisierung überhaupt zu ermöglichen.
Die derzeit definierten System Fields sind: Name, Content und Parent.
Von diesen Feldern muss nur das Feld Name einen Inhalt haben.
Die beiden Felder Content und Parent müssen angegeben werden, können aber auch leer sein.
# Field Mappings
Durch die Verwendung von Field Mappings werden einzelne Felder über verschiedene Systeme hinweg abgeglichen, sodass der Synchronisationsprozess weiß, welche Daten verglichen und ausgetauscht werden müssen.
Normalerweise konfiguriert der Benutzer die Field Mappings bei der Erstellung eines Synchronisierungsauftrags.
Die Systemfelder sind von den vom Benutzer vorgenommenen Zuordnungen ausgenommen, diese Felder werden immer automatisch zugeordnet.
In ELO ist es möglich, mehrere Dokumente mit unterschiedlichen Masken in demselben synchronisierten Ordner zu erstellen. Folglich sind die Feldzuordnungen nicht einfach Eins-zu-Eins-Zuordnungen zwischen zwei Systemen.
Die Felder im Synchronisierungsprozess werden immer als n-zu-m-Beziehungen zueinander betrachtet, aber wenn bestimmte Elemente synchronisiert werden, sollten die Zuordnungsregeln zu einer Eins-zu-Eins-Zuordnung führen.
# Beispiel
Als Beispiel sind hier die Zuordnungen für eine Synchronisierung zwischen einem ELO Repository und OneDrive definiert.
flowchart LR
subgraph system-a[ELO]
subgraph mail[Mask: E-Mail]
field-a2[Field: Subject]
end
subgraph rechnung[Mask: Bill]
field-a3[Field: Title]
end
subgraph document[Mask: *]
field-a1[Short name]
end
end
subgraph system-b[OneDrive]
field-b1[Filename]
end
field-a1 <--> field-b1
field-a2 <--> field-b1
field-a3 <--> field-b1
Die Datei in OneDrive hat nur den Dateinamen, aber im ELO Repository sind mehrere Masken verfügbar, mit denen dieser Dateiname synchronisiert werden kann.
Wenn jedoch ein bestimmtes Dokument mit der entsprechenden Datei in OneDrive synchronisiert wird, ist die Maske des Dokuments bekannt, sodass sich die Zuordnungen auf eine einzige Zuordnung reduzieren.
Information
Dies ist nur ein Beispiel.
In einem Produktionsszenario ist der Dateiname ein Systemfeld und wird immer mit dem Systemfeld Short name in ELO synchronisiert.
Wenn das Dokument in ELO die Maske Bill hat, dann würde folgende Synchronisation ausgeführt werden:
flowchart LR
subgraph system-a[ELO]
subgraph rechnung["Document (Bill)"]
field-a3[Field: Title]
end
end
subgraph system-b[OneDrive]
subgraph file[File]
field-b1[Filename]
end
end
field-a3 <--> field-b1