# Grundlagen
Im folgenden Kapitel erfahren Sie, wie der Datenabgleich und die Datenübertragung funktionieren.
# Funktionsweise
ELO Replication gleicht Einträge zwischen mehreren Repositorys ab. Die beteiligten Repositorys können an verschiedenen Standorten installiert sein. ELO Replication überträgt die Daten an die beteiligten Repositorys. Das heißt, eine direkte Erreichbarkeit der Repositorys untereinander ist nicht nötig.
ELO Replication ist eine Web-App auf Java-Basis, die auf einem Apache Tomcat installiert wird.
# Replikationskreis
Der Replikationskreis ist ein Merkmal, das Sie einzelnen Einträgen zuweisen, um sie in ein anderes Repository zu replizieren. In der webbasierten Konfiguration erstellen Sie Standorte und fügen Repositorys hinzu. Sie legen dabei anhand der ELO Indexserver-URL fest, aus welchen Repositorys Daten repliziert werden. Ein Replikationskreis wird in der Konfiguration automatisch erstellt, wenn Sie ein neues Repository hinzufügen. Ein Replikationskreis steht für ein Repository. Die Auswahl der einzelnen Einträge (Ordner, Dokumente), die repliziert werden sollen, erfolgt im ELO Java Client oder ELO Web Client. Dort ordnen Sie den Einträgen Replikationskreise zu. Das heißt, Sie wählen ein Repository aus, in das die Einträge repliziert werden.
# Datenabgleich
ELO Replication erfasst, verteilt und überträgt die Änderungen in den beteiligten Repositorys. Eine Erweiterung des ELO Indexservers erstellt den Abgleichdatensatz mit den Änderungen eines Repositorys. Das Format dieses Datensatzes ist ein komprimierter Stream an JSON-Objekten aus der ELO Indexserver-API. Die Daten in diesem Stream werden im ELO Indexserver anhand ihres Synchronisationsstatus ausgewählt. Dabei gibt es folgende Möglichkeiten:
Einträge ohne Replikationskreis: Einträgen, die nicht abgeglichen werden sollen, wurde kein Replikationskreis zugeordnet. Ein Replikationskreis bestimmt, mit welchen anderen Repositorys der Eintrag abgeglichen wird. Einträge ohne Replikationskreis werden nicht im Abgleichdatensatz aufgenommen.
Einträge mit neuem Replikationskreis: Einträgen, die abgeglichen werden sollen, wurden neue Replikationskreise zugeordnet. Die Informationen der Einträge werden in den Abgleichdatensatz aufgenommen. Die kompletten Informationen der Einträge werden nur an die Repositorys gesendet, deren Replikationskreis neu zugeordnet wurde. Wenn den Einträgen vorher schon Replikationskreise zugewiesen wurden, werden deren Repositorys nur darüber informiert, dass die Einträge nun mit weiteren Repositorys repliziert werden.
Der ELO Indexserver ordnet replizierten Einträgen beim Erstellen des Abgleichdatensatzes in der Datenbank das Feld tstampsync zu. Das Feld tstampsync erhält den Wert, den das entsprechende Feld tstamp zum Zeitpunkt des Lesens aus der Datenbank hatte. Im Abgleichdatensatz erhält das Feld tstampsync jedoch den Wert, den es beim Lesen aus der Datenbank hatte. Dieser Unterschied spielt beim Einlesen des Datensatzes eine wichtige Rolle.
Information
Der Name des Feldes tstampsync unterscheidet sich je nach Tabelle.
Einträge mit Änderung seit dem letzten Abgleich: Die Einträge wurden seit dem letzten Abgleich verändert. Um eine Änderung zu erkennen, werden die Felder tstamp und tstampsync verglichen. Das Feld tstamp wird vom ELO Indexserver bei einer Änderung automatisch auf den aktuellen Zeitpunkt in UTC (Coordinated Universal Time) gesetzt.
Einträge ohne Änderung seit dem letzten Abgleich: Die Einträge wurden seit dem letzten Abgleich nicht verändert. Bei unveränderten Einträgen sind die Werte in den Feldern tstamp und tstampsync identisch. Unveränderte Einträge werden nicht in den Abgleichdatensatz aufgenommen.
# Datenübertragung
Der Abgleichdatensatz wird durch den ELO Indexserver erstellt. ELO Replication stößt das Erstellen nach einem konfigurierten Zeitplan an. Der Abgleichdatensatz wird vom ELO Indexserver durch ELO Replication zu den anderen Standorten an ELO Replication und von dort wieder an den ELO Indexserver der anderen Repositorys zum Einlesen gestreamt. Beim Streamen zwischen den Instanzen von ELO Replication wird der Datensatz verarbeitet. An das Ziel werden nur die Daten gesendet, die dort benötigt werden.
Um Instabilitäten bei der Übertragung zu kompensieren, speichert ELO Replication die Datensätze zwischen. Bei einem Verbindungsabbruch versucht ELO Replication minütlich, den Datensatz erneut zu übertragen. Dabei wird der Datensatz komplett neu übertragen, unabhängig davon, an welcher Stelle die Übertragung abgebrochen wurde.
Für die Datenübertragung wird die SSHD-Bibliothek aus dem Apache-MINA-Projekt genutzt. Zur Authentifizierung wird ausschließlich das Verfahren mit öffentlichen und privaten Schlüsseln verwendet. Die Schlüssel werden bei der Konfiguration von ELO Replication automatisch für jeden Standort individuell generiert.
Information
Sie können über selbsterstellte Plug-ins weitere Möglichkeiten zur Datenübertragung hinzufügen.
Der ELO Indexserver importiert den Abgleichdatensatz ins Ziel-Repository. Dabei gibt es folgende Möglichkeiten:
Eintrag ist nicht im Repository vorhanden: Anhand der GUID wird geprüft, ob ein Eintrag bereits im Repository vorhanden ist. Wenn der Eintrag nicht im Repository vorhanden ist, wird er importiert.
Eintrag ist bereits im Repository vorhanden und wurde seit dem letzten Abgleich nicht verändert: Die Werte des Felds tstampsync des Eintrags sind im Abgleichdatensatz und im Repository identisch. Der Eintrag wird in das Repository importiert. Dabei wird der bereits im Repository vorhandene Eintrag mit den Werten aus dem Abgleichdatensatz überschrieben.
Eintrag ist bereits im Repository vorhanden und hat konkurrierende Änderungen erhalten: Die Werte des Felds tstamp des Eintrags unterscheiden sich im Abgleichdatensatz und im Repository. Wenn ein Eintrag in mehreren Repositorys verändert wurde, wird die neueste Änderung übernommen. Stammt die neueste Änderung aus dem Ziel-Repository, wird der Eintrag im Abgleichdatensatz ignoriert. Andernfalls werden die Werte des Eintrags im Repository durch die Werte im Abgleichdatensatz aktualisiert.
In seltenen Fällen kommt es vor, dass sich die Werte des Felds tstampsync unterscheiden. Dieser Zustand tritt auf, wenn ein Abgleichdatensatz im lokalen Repository erstellt wurde, bevor der Abgleichdatensatz des anderen Repositorys eingelesen wurde und der Eintrag in beiden Repositorys verändert wurde. Auch in diesem Fall wird die neueste Änderung übernommen.
# Welche Daten werden repliziert?
Die folgenden Daten werden bei einer Replikation abgeglichen:
- Ordner
- Dokumente
- Haftnotizen
- Relationen
- Stichwortlisten
- Workflows
- Workflow-Vorlagen
- Map-Daten
- Feed
- Übersetzungen
- Stammdaten: Benutzer und Gruppen (über Eigentümer und ACLs), Masken, Maskenzeilenvorlagen, Aspekte, Farben, Replikationskreise
Stammdaten werden rekursiv aufgelöst. Wenn z. B. ein Benutzer in der ACL eines Ordners aufgeführt ist, werden auch die Gruppen dieses Benutzers in den Abgleichdatensatz aufgenommen.
Beachten Sie
Die Änderungschroniken von Dateien werden nicht repliziert.
# Wie werden Stammdaten repliziert?
Bei einem Datenexport prüft der ELO Indexserver, welche Stammdaten zu einem SORD gehören.
Es werden nur Benutzer repliziert, auf die ein SORD explizit verweist. Wenn Sie einen bestimmten Benutzer replizieren wollen, muss dieser Benutzer von einem SORD referenziert werden, z. B. über Berechtigungen (Metadaten > Berechtigungen) oder Eigentümerrechte (z. B. Ordner anlegen, Dokument ablegen, Stempel/Anmerkung anbringen oder Workflow starten).
Beachten Sie
Wenn ein Benutzer repliziert wird, werden auch die Gruppen, zu denen der Benutzer gehört, repliziert (ohne die einzelnen Mitglieder).
Wenn eine Gruppe repliziert wird, weil sie z. B. auf ein SORD berechtigt ist, werden die einzelnen Gruppenmitglieder nicht repliziert.
Wenn eine Maske repliziert worden ist, wird in der Datenbank ein Zeitstempel im Feld masktstampsync der Tabelle docmasks gesetzt. Masken, die schon einmal repliziert worden sind, werden in den Abgleichdatensatz aufgenommen, wenn es Änderungen an den Masken gab.
Vorlagen für Maskenzeilen werden erstmalig anhand ihrer Verwendung in replizierenden Masken repliziert. Danach werden Änderungen an den Maskenzeilenvorlagen über die Werte der Felder tstamp und tstampsync erfasst und jeweils auch repliziert.
Aspekte werden anhand ihrer Verwendung in replizierten Masken repliziert. Änderungen werden durch die Werte der Felder tstamp und tstampsync erfasst. Im Konfliktfall überschreibt der "gewinnende" Aspekt komplett den "verlierenden" Aspekt. Zukünftig sollen Aspekte nach erstmaliger Replikation durch Maskenverwendung auch bei jeder Änderung repliziert werden.
# Wie werden Workflows repliziert?
Im Folgenden wird das Verhalten ab ELO Indexserver-Version 23 beschrieben.
Ein Workflow kann standardmäßig nur in einem Repository laufen. Bei einem Datenexport bekommt der Workflow ein Flag, das anzeigt, in welchem Repository er läuft. Im Ziel-Repository wird der Workflow nach der Replikation angezeigt, aber er läuft nicht weiter. Der Workflow kann im Ziel-Repository nicht gestartet, bearbeitet oder gelöscht werden.
Um den Workflow auch im Ziel-Repository nutzen zu können, muss das Flag beim Export geändert werden. Dies geschieht über einen Serverübergabe-Knoten, der im Workflowdesigner hinzugefügt wird. Wenn ein Serverübergabe-Knoten gesetzt ist, wird der Workflow bei diesem Knoten angehalten. Nach der Datenübertragung durch die Replikation läuft der Workflow im Ziel-Repository weiter. Es wird immer der gesamte Workflow inklusive aller Subworkflows repliziert.
Beachten Sie
Die Serverübergabe darf nur in einem Hauptworkflow stattfinden, nicht in einem Subworkflow. Wenn Sie also an Standort B einen Subworkflow starten wollen, muss die Serverübergabe im Hauptworkflow an Standort A stattfinden. Wenn eine Gruppe repliziert wird, weil sie z. B. auf ein SORD berechtigt ist, werden die einzelnen Gruppenmitglieder nicht repliziert.
Ein Subworkflow sollte nur an einem Standort laufen. Sie sollten einen Subworkflow nicht an Standort A starten und an Standort B weiterlaufen lassen, da es zu nicht automatisch lösbaren Konflikten kommen kann, wenn Hauptworkflow und Subworkflow in unterschiedlichen Repositorys gleichzeitig ausgeführt werden.
# Wie werden Workflow-Vorlagen repliziert?
Workflow-Vorlagen werden erstmalig anhand ihrer Verwendung in replizierten Workflows repliziert. Danach werden Änderungen an Workflow-Vorlagen auch mit den Werten der Felder tstamp und tstampsync getrackt und bei jeder Änderung repliziert. Im Konfliktfall überschreibt die "gewinnende" Vorlage komplett die "verlierende" Vorlage.
# Wie werden Map-Daten repliziert?
Map-Daten werden anhand ihrer Zugehörigkeit zum SORD/Dokument der jeweiligen zugeordneten Replikationskreise repliziert. Map-Daten sind in unterschiedlichen Map-Domänen angeordnet. Diese werden auch repliziert. In der Map-Domäne lässt sich durch ein Flag bestimmen, ob diese ebenfalls mit repliziert werden soll. Steht dieses Flag auf false, wird die komplette Domäne und alle Map-Daten darin von der Replikation ignoriert.
Änderungen werden je Map und je Sord getrackt und mithilfe der Werte der Felder tstamp und tstampsync erfasst. Eine Konfliktbehandlung beim Import findet dementsprechend auf Map-Ebene und nicht auf einzelne Map-Zeilen statt. Das "gewinnende" Map überschreibt also komplett das "verlierende" Map.
# Wie werden Stichwortlisten repliziert?
Stichwortlisten werden erstmalig anhand ihrer Verwendung in zu replizierenden Masken und Aspekten repliziert. Danach werden Änderungen an den Stichwortlisten über die Werte der Felder tstamp und tstampsync erfasst und jeweils auch repliziert.
# Wie werden Übersetzungen repliziert?
Übersetzungen, die in der Übersetzungstabelle abgelegt sind, werden erstmalig bei Verwendung des Übersetzungsschlüssels in zu replizierenden Objekten repliziert. Danach werden Änderungen an Übersetzungen über die Werte der Felder tstamp und tstampsync erfasst und jeweils auch repliziert.