Installation und Konfiguration
Last updated
Last updated
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
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.
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.
@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.
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.
@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.
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.
@name
Project A
Altes Projekt
newProjectName
Project B
Neues Projekt
Diese Regel dient zur Manipulation von Vorgangseigenschaften.
@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.
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.
@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.
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.
@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.
Innerhalb einer Regel können weitere allgemeine Einstellungen festgelegt werden.
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
).