Für die Inbetriebnahme des Goobi-to-Goobi-Mechanismus müssen sowohl auf dem Ausgangssystem als auch auf dem Zielsystem verschiedene Plugins installiert und Konfigurationen vorgenommen werden. Diese werden hier detailliert beschrieben.
Zunächst einmal muss das Ausgangssystem für den Export vorbereitet werden. Hierzu gehört zunächst einmal die Installation des korrekten Plugins. Im Anschluss daran, muss lediglich eine Berechtigung für die entsprechenden Nutzer konfiguriert werden, um den Export zu erlauben.
Auf dem Ausgangssystem muss zunächst das Plugin plugin_intranda_administration_goobi2goobi_export für die Erzeugung der Export-Verzeichnisse installiert werden. Dazu müssen die folgenden beiden Dateien an die entsprechenden Pfade kopiert werden:
Zu beachten ist hierbei, dass diese Dateien für den Nutzer tomcat lesbar sein müssen.
Um dem Nutzer zu ermöglichen, dass dieser einen Export der Daten durchführen kann, muss dieser über die folgenden Rollen verfügen:
Diese Rollen können innerhalb der Benutzergruppen von Goobi workflow konfiguriert werden. Wählen Sie dazu einfach die Rollen auf der rechten Seite aus oder tragen diese in das Eingabefeld und Klicken anschließend auf das Plus-Icon.
Mit dieser Konfiguration ist die Vorbereitung auf Seiten des Ausgangssystem bereits abgeschlossen.
Auch das Zielsystem muss für den Import vorbereitet werden. Nach der Installation des entsprechenden Plugins und der zugehörigen Konfigurationsdateien, müssen noch einige Konfigurationen geprüft bzw. vorgenommen werden.
Auf dem Zielsystem muss zunächst das Plugin plugin_intranda_administration_goobi2goobi_import für die Einspielen der Export-Verzeichnisse installiert werden. Dazu müssen die folgenden beiden Dateien an die entsprechenden Pfade kopiert werden:
Nach der Installation des eigentlichen Plugins müssen ebenfalls die zugehörigen Konfigurationsdateien installiert werden. Diese befinden sich unter folgenden Pfaden:
Auch hier ist wieder zu beachten, dass die installierten Dateien alle für den Nutzer tomcat lesbar sein müssen.
Um einem Nutzer die Durchführung des Imports zu ermöglichen, muss dieser über die folgende Rolle verfügen:
Diese Rolle kann innerhalb der Benutzergruppen von Goobi workflow konfiguriert werden, indem sie auf der rechten Seite in das Eingabefeld eingetragen und mittels Klick auf das Plus-Icon übernommen wird.
Um während des Imports der Infrastruktr Einfluss auf die zu importierenden Daten zu nehmen, kann eine Anpassung der Konfigurationsdatei plugin_intranda_administration_goobi2goobi_import_infrastructure.xml erfolgen. Diese Konfiguration kann beispielhaft wie folgt aussehen:
In der dieser Konfigurationsdatei sind sämtliche Felder optional. Fehlt ein Feld, wird dessen Wert während der Konfiguration nicht überschrieben. Ist das Feld hingegen leer, wird es ebenfalls leer importiert, ansonsten wird es mit dem Wert aus dieser Konfigurationsdatei überschrieben. Die Felder zum Hinzufügen oder Entfernen sind grundsätzlich wiederholbar.
Für den Import der Daten auf dem Zielsystem kann in der Konfigurationsdatei plugin_intranda_administration_goobi2goobi_import_infrastructure.xml festgelegt werden, wo sich Daten befinden und wie diese während des Imports verarbeitet werden sollen. Diese Konfiguration kann beispielhaft wie folgt aussehen:
Im oberen Bereich der Datei werden einige generelle Einstellungen vorgenommen, die für alle Importe gelten. Im Anschluss an diese allgemeinen Einstellungen folgen die einzelnen konfigurierten Regeln.
Allgemeine Einstellungen: globalConfig
Die einzelnen Regeln für die Importdurchführungen werden innerhalb des <config> Elements definiert werden. Der Name der Regel wird in <rulename> festgelegt. Wenn während des Imports keine Regel explizit ausgewählt wurde, wird diese über den Projektnamen des Vorgangs ermittelt. Das Feld ist wiederholbar, so dass mehrere identische Regeln erzeugt werden können, wenn zum Beispiel ein gleicher Workflow in verschiedenen Projekten genutzt wird.
Mittels <step> lassen sich einzelne Schritte des Vorgangs manipulieren. Alle Felder sind optional. Wenn sie nicht angegeben wurden, wird der originale Wert genutzt. Andernfalls wird das Feld mit dem konfigurierten Feldinhalt überschrieben. Wenn das Feld vom Typ String ist, kann es auch leer angegeben werden, um es zu leeren.
In diesem Element kann der zugewiesene Laufzettel ersetzt werden. Die zu nutzende xsl-Datei muss auf dem Server existieren. Wenn bereits ein Docket mit den neuen Angaben definiert wurde, wird dieses verwendet, andernfalls wird ein neues Docket definiert und in der Datenbank gespeichert.
Mit dieser Regel kann das zugewiesene Projekt geändert werden. Das Projekt muss bereits existieren. Änderungen an den Projekten selbst können über Infrastruktur importieren vorgenommen werden.
Diese Regel dient zur Manipulation von Vorgangseigenschaften.
Mit dieser Regel kann der zugewiesene Regelsatz geändert werden. Falls der Regelsatz noch nicht existiert, wird er neu angelegt und in der Datenbank gespeichert. Die xml-Datei des Regelsatzes selbst muss auf dem Server existieren.
Mit dieser Regel können die Metadaten verändert werden. Dabei können Werte von vorhandenen Metadaten geändert, neue hinzugefügt oder existierende Metadaten gelöscht werden.
Innerhalb einer Regel können weitere allgemeine Einstellungen festgelegt werden.
| Element | Beispiel | Bedeutung |
|---|---|---|
| Element | Beispiel | Bedeutung |
|---|---|---|
| Element | Beispiel | Bedeutung |
|---|---|---|
| Element | Beispiel | Bedeutung |
|---|---|---|
| Element | Beispiel | Bedeutung |
|---|---|---|
| Element | Beispiel | Bedeutung |
|---|---|---|
| Element | Beispiel | Bedeutung |
|---|---|---|
| Element | Beispiel | Bedeutung |
|---|---|---|
dbExportPrefix
import/
Diese Angabe wird benötigt, wenn die zu importierenden Datenbankinformationen nicht als xml-Dateien im jeweiligen Vorgangsordner liegen. Die Angabe enthält den Pfad zu den Datenbankinformationen innerhalb eines s3-Buckets und wird bei Importen in ein lokales Dateisystem nicht benötigt.
importPath
/opt/digiverso/goobi/metadata/
Zielverzeichnis, in das die Daten importiert werden sollen.
bucket
example-workflow-data
Name des s3-Buckets, in dem die zu importierenden Daten liegen. Dieser Wert wird bei Importen in ein lokales Dateisystem nicht benötigt.
createNewProcessIds
false
Dieser Parameter definiert, ob die Vorgangs-Identifier aus dem alten System erneut genutzt werden sollen, oder ob neue IDs erzeugt werden sollen.
temporaryImportFolder
/opt/digiverso/transfer/
Mit diesem Parameter wird der Pfad zu dem Ordner angegeben, in dem die zu importierenden Daten liegen. Der Wert muss nur konfiguriert werden, wenn er sich vom Wert innerhalb von importPath unterscheidet.
@name
Example task
Enthält den Namen des zu ändernden Schrittes.
@type
delete
Dieser Wert enthält den Typ der Manipulation. Als Werte sind delete, change, insertBefore, insertAfter möglich.
newStepName
new step name
Neuer Name des Schrittes.
priority
5
Neue Priorität des Schrittes.
order
10
Reihenfolge des Schrittes.
useHomeDirectory
0
Steuert, ob in das Homeverzeichnis des Nutzers verlinkt werden soll.
stepStatus
0
Setzt den Schrittstatus. Erlaubte Werte sind 0 (locked), 1 (open), 2 (inwork), 3 (done), 4 (error) und 5 (deactivated).
types
automatic="true"
Enthält in Attributen die verschiedenen Einstellungen eines Schrittes.
scriptStep
scriptStep="true" scriptName1="script 1" scriptPath1="/bin/true"
Definiert Skripte für die Arbeitsschritte.
httpStep
httpStep="true" httpMethod="POST" httpUrl="http://itm.example.com/itm/service"
Definiert die Konfiguration des HTTP Aufrufs für den Schritt.
usergroup
Administration
Name der zugewiesenen Benutzergruppe. Dieser Wert ist wiederholbar, um mehrere Nutzergruppen zu definieren.
@name
Default docket
Name des bisher verwendeten Laufzettels. Die Änderung findet nur statt, wenn der Vorgang bisher einen Laufzettel mit diesem Namen verwendet hat.
newDocketName
docket
Neuer Name des Laufzettels.
newFileName
docket.xsl
Neuer Dateiname für den Laufzettel.
@name
Project A
Altes Projekt
newProjectName
Project B
Neues Projekt
@name
CollectionName
Name der anzupassenden Eigenschaft.
oldPropertyValue
Digitised
Wert der anzupassenden Eigenschaft. Wenn ein Wert angegeben wird, muss die Eigenschaft diesen Wert enthalten.
newPropertyName
Collection
Neuer Name der Eigenschaft. Optional.
newPropertyValue
default collection
Neuer Wert der Eigenschaft. Optional.
@name
Default
Name des bisher verwendeten Regelsatzes.
newRulesetName
default ruleset
Neuer Name für den Regelsatz.
newFileName
ruleset.xml
Neuer Dateiname für den Regelsatz. Dieser muss auf dem Zielsystem existieren.
@name
CatalogIDDigital
Interner Name des Metadatums.
@type
change
Art der Änderung. Erlaubte Werte sind add, change und delete.
position
top
Beschreibt die Stelle, an der die Änderung durchgeführt werden soll. Erlaubte Werte sind all, anchor, top und physical.
valueConditionRegex
/PPN\d+\w?(?:_\d+)?/
Dieser reguläre Ausdruck prüft, ob der bisherige Feldinhalt einem definierten Wert entspricht. Bei dieser Angabe kann es sich um einen festen Wert oder einen regulären Ausdruck handeln.
valueReplacementRegex
s/^PPN(.+)$/$1/g
Wurde als @type der Wert change verwendet, enthält dieser Parameter einen regulären Ausdruck für die Manipulation des bisherigen Metadatums. Wurde als @type hingegen add gewählt, wird der Feldinhalt als Wert des Metadatums verwendet.
skipProcesslog
true
Festlegung, ob das Vorgangslog des Ausgangssystem übernommen werden soll (false) oder ob es ignoriert werden soll (true).
skipUserImport
true
Festlegung, ob die Benutzer von importierten Aufgaben eines Workflows innerhalb von Goobi als gelöschte Nutzer angelegt werden sollen (false) oder ob die Informationen über die Ausführung durch konkrete Personen ignoriert werden und so anonymisiert werden sollen. (true).
Nachdem die Erzeugung der Export-Verzeichnisse durchgeführt wurde, können die Vorgangsordner vom Ausgangssystem zu Zielsystem kopiert werden. Je nachdem, um welche Datenmengen es sich hierbei handelt können verschiedene Methoden für den Transfer zum Einsatz kommen.
Soll für den Transfer eine externe Festplatte zum Einsatz kommen, kann mittels des cp-Befehls der Kopiervorgang vom Ausgangssysetm auf die Festplatte und später wieder von der Festplatte auf das Zielsystem erfolgen.
Beispielaufruf für den Kopiervorgang vom Ausgangssystem auf die externe Festplatte:
Beispielsaufruf für den Kopiervorgang von der externen Festplatte auf das Zielsystem:
Wenn zwischen dem Ausgangssystem und dem Zielsystem eine Netzwerkverbinung hergestellt werden kann, ist ein Datentransfer über die Kommandos scp oder rsync möglich. Der Vorteil des Transfers mittels rsync besteht dabei darin, dass eine gegebenenfalls auftretende Unterbrechung der Verbindung wieder aufgenommen werden kann, ohne den gesamten Transfer wieder von vorn beginnen zu müssen.
Beispielhaft sieht ein solcher Aufruf folgendermassen aus:
Soll der Aufruf nur bestimmte Verzeichnisse übertragen, eine maximale Bandbreite nutzen und auch andere Daten ausschließen, könnte ein solcher Aufruf auch etwas umfangreicher werden:
Zum Export in ein S3 Bucket nach AWS kann das Skript s3sync.py verwendet werden.
Administration Plugins für eine Migration von einem Goobi workflow System zu einem anderen Goobi workflow System
| Name | Wert |
|---|---|
Mit den beiden hier beschriebenen Plugins ist ein Datentransfer von einem Goobi workflow System zu einem anderem Goobi workflow System (Goobi-to-Goobi) möglich. Diese Dokumentation erläutert die Installation, Konfiguration sowie die Verwendung der zugehörigen Plugins.
Bevor die Verwendung des Export- und Import-Mechanismus erfolgen kann, müssen verschiedene Installations- und Konfigurationsschritte durchlaufen werden. Diese sind hier im Detail beschrieben:
Der Mechanismus für einen Datentransfer von einem Goobi workflow System zu einem anderem Goobi workflow System (Goobi-to-Goobi) ist in drei große Arbeitsschritte aufgeteilt.
Diese drei Arbeitsschritte gestalten sich folgendermaßen:
Im ersten Arbeitsschritt erfolgt auf dem Ausgangssystem eine Anreicherung der Daten innerhalb des Dateisystems mit denjenigen Informationen, die Goobi intern in der Datenbank für jeden Vorgang gespeichert hat. Mit der Ausführung dieses Arbeitsschrittes wird somit in den Ordner eines jeden Goobi-Vorgangs eine zusätzliche xml-Datei geschrieben, die die Datenbankinformationen über den Workflow und einige weitere notwendigen Daten enthält.
Erzeugung der Export-Verzeichnisse
Nach der vollständigen Erzeugung und Anreicherung der Export-Verzeichnisse auf dem Ausgangssystem können diese auf den Server des Zielsystems transferiert werden. Dies kann auf verschiedene Arten erfolgen. Aufgrund der Datenmengen hat sich hierfür vorrangig ein Transfer mittels rsync bewährt.
Transfer der Export-Verzeichnisse
Nachdem die Export-Verzeichnisse erfolgreich auf das Zielsystem transferiert wurden, können die Daten dort eingespielt werden. Hierzu müssen die Daten an der richtigen Stelle im System abgelegt werden und auch einige weitere Vorkehrungen hinsichtlich der Infrastruktur vorbereitet sein.
Der Import von Daten auf dem Zielsystem findet mittels zweier verschiedener Plugins statt. Diese müssen zunächst installiert und entsprechend konfiguriert werden. Mehr Informationen über deren Installation und Konfiguration finden sich hier:
Nach der erfolgreichen Installation, kann mit dem eigentlichen Import fortgefahren werden. Hierbei ist zu unterscheiden zwischen dem reinen Import von Vorgängen und dem Import einer exportierten Infrastruktur. Je nach Projekt kann dabei der Import der Infrastruktur als erster Arbeitsschritt erforderlich zu sein.
Im Bereich für den Import der Infrastruktur kann die zuvor exportierte Infrastruktur des Ausgangssystems eingespielt werden. Öffnen Sie hierfür zunächst das Plugin Goobi-to-Goobi Import - Infrastruktur im Menü Administration.
An dieser Stelle läßt sich nun eine zip-Datei hochladen, die zuvor auf dem Ausgangssystem erzeugt wurde. Nach dem erfolgreichen Upload wird die Datei auf dem Server entpackt und analysiert. Der Nutzer erhält anschließend eine Zusammenfassung über die zu importierenden Daten.
Wenn bereits Nutzer, Projekte, Gruppen etc. im Zielsystem existieren, die den gleichen Namen wie die zu importierenden Daten besitzen, zählen sie nicht zu den neu zu importierenden Daten und können nicht überschrieben werden. Nach der Auswahl der importierenden Daten kann der Import mit einem Klick auf Import der Infrastruktur durchführen gestartet werden.
Sollte es gewünscht sein, kann während des Imports eine Manipulation der Daten erfolgen. Dies ist durch eine Anpassung der Konfigurationsdatei plugin_intranda_administration_goobi2goobi_import_infrastructure.xml möglich. Genaueres hierzu findet sich im Bereich Konfiguration für den Import der Infrastruktur hier:
Um die Vorgänge von dem Ausgangssystem importieren zu können, müssen diese zunächst erfolgreich exportiert und auf das Zielsystem transferiert worden sein. Wie der Transfer der zum Teil sehr großen Datenmengen erfolgen kann ist hier beschrieben:
Transfer der Export-Verzeichnisse
Nach dem vollständigen Transfer der Daten zum Zielsystem können Sie den Import der Daten starten. Dazu öffnen Sie im Menü Administration das Plugin Goobi-to-Goobi Import - Daten. Dort werden im oberen Bereich der Nutzeroberfläche die konfigurierten Regeln für den Import angezeigt. Werden diese Regeln auf dem Zielsystem bearbeitet, so können Sie jederzeit durch einen Klick auf den Button Regeln neu einlesen neu geladen werden.
Im unteren Bereich der Nutzeroberfläche findet der eigentliche Import statt. Dort kann der Nutzer als erstes durch einen Klick auf Dateien neu einlesen nach den zu importierenden Daten suchen. Wenn diese Suche aufgrund der großen Datenmenge länger als 10 Sekunden dauert, findet die weitere Suche im Hintergrund statt und der Nutzer bekommt die Rückmeldung, dass er die Seite bitte nach einiger Zeit noch einmal aktualisieren soll.
Wenn nach der Suche der zu importierenden Daten erfolgreich Dateien aufgelistet werden, können diese nun ausgewählt werden. Dazu können sie entweder einzeln markiert werden, oder man lässt Goobi durch einen Klick auf Select all alle auswählen. Dazu muss die Regel ausgewählt werden, die für den Import angewendet werden soll. Diese lässt sich entweder direkt auswählen oder kann mittels Autodetect rule ermittelt werden. In diesem Fall wird geprüft, ob es eine Regel gibt, die dem Namen des Projektes entspricht, dem der Vorgang zugeordnet wurde.
Ein Klick auf den Button Import der Daten durchführen startet anschließend den eigentlichen Import. Während dieses Imports wird für jeden ausgewählten Vorgang ein internes Goobi-Ticket erstellt und an die interne Warteschlange (Message Queue) übermittelt. Die einzelnen Tickets werden im Hintergrund abgearbeitet und die Vorgänge so sukzessive importiert.
Eine genaue Konfiguration des Imports sowie der zugrundeliegenden Regeln kann innerhalb der Konfigurationsdatei plugin_intranda_administration_goobi2goobi_import_data.xml erfolgen. Weitere Informationen über diese Konfiguration findet sich im im Abschnitt Konfiguration für den Import der Daten:
Der Export aus dem Ausgangssystem besteht aus bis zu drei Teilschritten. Bevor der Export jedoch stattfinden kann, muss zunächst innerhalb des Rollensystems von Goobi workflow festgelegt werden, dass der Nutzer über die Berechtigungen für den Export verfügen muss. Informationen über die vorzunehmenden Konfigurationen finden sich hier:
Nach der Konfiguration der benötigen Benutzerrechte kann der eigentliche Export beginnen. In den meisten Fällen wird hierfür lediglich der erste der folgenden drei Teilschritte notwendig sein.
Für die meisten Einsatzzwecke wird lediglich dieser Teilschritt zum Erzeugen der Export-Dateien für alle gewünschten Vorgänge benötigt. Hierbei wird für alle ausgewählten Vorgänge innerhalb des Dateisystems im Ordner jedes ausgewählten Vorgangs eine xml-Datei mit allen relevanten Informationen über den Vorgang aus der Datenbank erzeugt.
Um einen solchen Export für mehrere Vorgänge zusammen durchzuführen, besteht die Möglichkeit, diesen mittels GoobiScript zu starten. Hierzu wird das folgende GoobiScript-Kommando benötigt:
Nach der Ausführung dieses GoobiScripts findet sich in jedem Vorgangsordner die jeweilige Export-xml-Datei (z.B. 5_db_export.xml).
Um einen solchen Export für einen einzelnen Vorgang durchzuführen, besteht die Möglichkeit, diesen innerhalb der Details eines Vorgangs zu starten. Klicken Sie hierzu einfach auf das entsprechende Icon für den Export.
Im Gegensatz zum Export über GoobiScript wird hierbei ein Download der xml-Datei gestartet, die die Datenbankinformationen beinhaltet.
Hinweis: Dieser Teilschritt ist optional und wird nur in seltenen Fällen benötigt.
Ist gewünscht, dass nicht nur Vorgänge von einem Goobi workflow zu einem anderen übertragen werden, können auch Exportdaten für Produktionsvorlagen erzeugt werden. Da GoobiScript allerdings nicht innerhalb des Bereichs für Produktionsvorlagen verfügbar ist, kann dieser Export aus dem bereitgestellten Plugin Goobi-to-Goobi Export innerhalb des Menüs Administration erfolgen.
Klicken Sie hierzu nun auf den Button Erzeuge Dateien mit Informationen über die Produktionsvorlagen. Hierdurch wird für jede Produktionsvorlage ebenfalls eine xml-Datei mit den Datenbankinformationen im Dateisystem gespeichert und kann für den Transfer zu dem Zielsystem verwendet werden.
Hinweis: Dieser Teilschritt ist optional und wird nur in seltenen Fällen benötigt.
Sollen neben den eigentlichen Goobi-Vorgängen auch weitergehende Informationen über die Infrastruktur von einem Goobi workflow zu einem anderen übertragen werden, besteht die Möglichkeit, diese innerhalb des Export-Plugins ebenfalls exportieren zu lassen. Wählen Sie hierzu innerhalb des Plugins Goobi-to-Goobi Export die bereitgestellten Checkboxen aus, um gezielt Einfluss auf den Export vorzunehmen. Folgende Parameter stehen hierfür zur Verfügung:
Nach der Auswahl der gewünschten Informationen und dem Klick auf den Button Download der Infrastruktur als zip-Datei erzeugt Goobi eine zip-Datei und bietet diese mit dem Namen goobi-to-goobi-export.zip zum Download an. Diese zip-Datei enthält nun sämtliche ausgewählten Informationen aus der Goobi-Datenbank für den Transfer zu dem Zielsystem.
| Option | Bedeutung |
|---|---|
LDAP Gruppen
Exportiert die vorhandenen LDAP Gruppen
Benutzer
Export der aktiven Nutzer
Deaktivierte Nutzer berücksichtigen
Zusätzlich zu den aktiven Nutzern ebenso die deaktivierten Nutzer mit exportieren
Erzeuge neue Passwörter
Festlegung, ob die bestehenden Passwörter der Nutzer mit exportiert werden sollen. In dem Fall, dass die Checkbox gesetzt ist, müssen auf dem Zielsystem nach dem Import für die importierten Nutzer neue Passwörter gesetzt werden.
Benutzergruppen
Export der Nutzergruppen, Berechtigungen und zusätzlichen Rollen
Zuweisung zu Benutzergruppen
Export aller dem Nutzer zugewiesenen Gruppen
Projekte
Export der Projekte
Zuweisung zu Projekten
Export aller dem Nutzer zugewiesenen Projekte
Regelsätze
Export der Regelsatzinformationen
Laufzettel
Export der Laufzettelinformationen
Inklusive der Dateien
Festlegung ob die exportierte zip-Datei die Regelsätze und Laufzettel beinhalten soll
Identifier
intranda_administration_goobi2goobi_export intranda_administration_goobi2goobi_import_infrastructure intranda_administration_goobi2goobi_import_data
Repository
Lizenz
GPL 2.0 oder neuer
Letzte Änderung
25.07.2024 11:11:13
