Übersicht

Einführung

Die vorliegende Dokumentation beschreibt die Installation, die Konfiguration und den Einsatz des Administration Plugins für die automatisierte Übernahme einer zentralen Anchor-Datei eines Bandes (z.B. von Zeitschriften oder Mehrbändigen Werken) zu anderen Bänden innerhalb von Goobi workflow.

Installation

Um das Plugin nutzen zu können, müssen folgende Dateien installiert werden:

/opt/digiverso/goobi/plugins/administration/plugin-administration-copyanchor-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin-administration-copyanchor-gui.jar

Es existiert derzeit keine Konfigurationsdatei für dieses Plugin.

Überblick und Funktionsweise

Wenn das Plugin korrekt installiert und konfiguriert wurde, ist es innerhalb des Menüpunkts Administration zu finden.

Definition eines Master-Anchors

Nach der vollständigen Einrichtung des Plugins kann dieses verwendet werden. Dazu wird zunächst innerhalb desjenigen Bandes, der als Master-Anchor markiert werden soll, das neu definierte Metadatum InternalNote hinzugefügt und als Wert AnchorMaster eingetragen. Im folgenden Screenshot wird dies einmal verdeutlicht:

Der somit angepasste Zeitschriftenband wurde mit dieser Änderung als Master definiert. Von nun an dienen die dort verwendeten Metadaten des übergeordneten Werkes (z.B. der Zeitschrift) als Vorgabe für alle anderen zugehörigen Bände. Änderungen, die für alle Bände innerhalb der Anchor-Dateien vorgenommen werden sollen, erfolgen daher von nun an innerhalb dieses Datensatzes.

Übernahme der Metadaten für alle zugehörigen Bände

Sowie innerhalb eines Goobi-Vorgangs ein Band als Master festgelegt wurde, kann das Plugin dazu genutzt werden, alle Metadaten des Masters auf alle zugehörigen Bände zu übertragen. Gehen Sie dazu folgendermaßen vor:

Öffnen Sie zunächst das Plugin mittels des Menüs Administration und darin des Menüpunktes Kopieren von Master-Anchor Daten.

Geben Sie in dem Inputfeld des Plugins den Katalog-Identifier des übergeordneten Werkes ein (z.B. die ID der Zeitschrift) und klicken sie anschließend auf den Butten Kopiervorgang starten. Hiermit wird der Kopiervorgang aufgerufen, der die Metadaten des Master-Anchor-Datensatzes automatisch in alle zugehörigen Bände (z.B. alle Bände der Zeitschrift) übernimmt.

Konfiguration

Das Plugin verfügt nicht über eine eigene Konfigurationsdatei. Dennoch ist eine Anpassung des verwendeten Regelsatzes zwingende Voraussetzung für den Betrieb des Plugins. Beispielhaft soll dies an einem Regelsatz aufgezeigt werden, der sich beispielsweise unter folgendem Pfad findet:

/opt/digiverso/goobi/rulesets/ruleset.xml

Innerhalb des Regelsatzes muss das Metadatum InternalNote definiert werden:

<MetadataType>
  <Name>InternalNote</Name>
  <language name="de">Interne Goobi-Anmerkung</language>
  <language name="en">Internal Note for Goobi</language>
</MetadataType>

Dieses Metadatum muss nun innerhalb der Definition der Bände erlaubt werden. Anhand eines Zeitschriftenbandes erfolgt dies beispielhaft so:

<DocStrctType topStruct="true">
  <Name>PeriodicalVolume</Name>
  <language name="de">Zeitschriftenband</language>
  <language name="en">Periodical volume</language>
  <!-- Definitions of other metadata and structure elemtents skipped here -->
  <metadata num="*">InternalNote</metadata>
</DocStrctType>

Mittels dieser Anpassung am Regelsatz sind die Vorbereitungen für die Verwendung des Plugins bereits abgeschlossen.

Auf den folgenden Seiten finden Sie die einzelnen zumeist kleineren Dokumentationen für verschiedene Plugins und Erweiterungen für Goobi workflow. Bitte wählen Sie zunächst im linken Bereich innerhalb des Inhaltsverzeichnisses das gewünschte Plugin aus, um zu Dokumentation zu gelangen.

Bitte beachten Sie, dass es innerhalb von Goobi workflow verschiedene Arten von Plugins für die jeweiligen Anwendungsszenarien gibt:

Export Plugins

Export Plugins dienen für den Export von Daten aus Goobi workflow zu einem anderen System. Sie werden entweder automatisch im Rahmen des Workflows ausgeführt oder durch einen manuellen Klick auf das entsprechende Icon in der Vorgangsliste. Installiert werden sie üblicherweise innerhalb dieses Pfades:

/opt/digiverso/goobi/plugins/export/

Die Einrichtung von Export Plugins innerhalb von Goobi erfolgt so, dass sie innerhalb eine Workflows für einen Arbeitsschritt aus der Liste der Step-Plugins ausgewählt werden und zusätzliche die Checkbox Export aktiviert wird. Üblicherweise wird ausserdem auch die Checkbox Automatische Aufgabe mit ausgewählt, um die Exporte automatisch in Verlauf des Workflows ausführen zu lassen.

Manche Export Plugins verfügen über eine eigene Konfigurationsdatei. Diese ist im allgemeinen so benannt wie das Plugin selbst und befindet sich üblicherweise unter folgendem Pfad:

/opt/digiverso/goobi/config/

Step Plugins

Step Plugins dienen für eine Erweiterung von Aufgaben innerhalb des Goobi Workflows. Mit solchen Plugins läßt sich beispielsweise eine individuelle Funktionalität in den Workflow integrieren, die Goobi nicht out-of-the-box mitbringt. Beispiele für solche Plugins sind unter anderem besondere Konvertierungsplugins, Erfassungsmasken, Bildmanipulationen etc.

Installiert werden solche Step Plugins in den Ordner:

/opt/digiverso/goobi/plugins/step/

Verfügt ein Plugin neben der eigentlichen Funktionalität ausserdem über eine Nutzeroberfläche, so muss der Teil der Nutzeroberfläche zusätzlich in diesen Ordner installiert werden:

/opt/digiverso/goobi/plugins/GUI/

Grundsätzlich werden Step Plugins in Goobi so eingerichtet, dass diese innerhalb einer Aufgabe als Plugin ausgewählt werden.

Zu beachten ist noch, dass es innerhalb von Step Plugins derzeit drei unterschiedliche Typen gibt:

Manche Step Plugins verfügen über eine eigene Konfigurationsdatei. Diese ist im allgemeinen so benannt wie das Plugin selbst und befindet sich üblicherweise unter folgendem Pfad:

/opt/digiverso/goobi/config/

Opac Plugins

Opac Plugins dienen zur Kommunikation mit externen Datenquellen. Typische Beispiele hierfür sind Plugins für die Anbindung von Bibliothektskatalogen oder Datenbanken. Hierfür existieren je nach Datenquelle verschiedene Implementierungen, um die jeweilig zu verwendende Schnittstelle korrekt anzusprechen.

Opac Plugins werden üblicherweise unterhalb dieses Pfads installiert:

/opt/digiverso/goobi/plugins/opac/

Nach der Installation eines solchen Plugins steht es innerhalb der Anlegemaske für Vorgänge in Goobi in dem Feld Suche im Opac zur Verfügung.

Import Plugins

Import Plugins dienen für die Ausführung von größeren Massenimporten. Anders als bei Opac Plugins wird hier nicht Vorgang für Vorgang aus einer Datenquelle abgefragt. Stattdessen werden bei den Import Plugins die Daten meist zugleich für hunderte oder tausende Daten übernommen, die oft in unterschiedlichsten Formaten vorliegen. Gängige Beispiele sind hier unter anderem Import Plugins für das Einspielen von SQL-Dumps, Excel-Tabellen oder sonstigen proprietären Datenquellen.

Die Installation der Import Plugins erfolgt im Ordner:

/opt/digiverso/goobi/plugins/import/

Der Einsatz dieser Plugins erfolgt in einer eigenen Maske für Massenimporte, in der man den unterschiedlichen Importmechanismus sowie das gewünschte Plugin auswählt, bevor anschließend eine Auswahl der Daten erfolgt.

Einige Import Plugins verfügen über eine eigene Konfigurationsdatei. Diese ist im allgemeinen so benannt wie das Plugin selbst und befindet sich üblicherweise unter folgendem Pfad:

/opt/digiverso/goobi/config/

Administration Plugins

Für einige besondere Anwendungsfälle stehen Administration Plugins bereit. Die Besonderheit dabei ist, dass diese Plugins funktionell nicht eingeschränkt sind. Sie sind nicht explizit an einer vorgegebenen Stelle innerhalb des Workflows integriert noch werden sie zu einem definierten Moment ausgeführt. Stattdessen bieten sie zumeist eine eigenen Nutzeroberfläche und bieten eine eigenständige Funktionalität als Erweiterung von Goobi an. Beispiele hierfür sind unter anderem administrative Eingriffe in mehrere Vorgangsdaten oder auch die Verwaltung von kontrollierten Vokabularen.

Die Installation der Administration Plugins erfolgt im Ordner:

/opt/digiverso/goobi/plugins/administration/

Da die meisten Administration Plugins neben der eigentlichen Funktionalität ausserdem über eine Nutzeroberfläche verfügen, so muss diese zusätzlich in folgenden Ordner installiert werden:

/opt/digiverso/goobi/plugins/GUI/

Manche Administration Plugins verfügen über eine eigene Konfigurationsdatei. Diese ist im allgemeinen so benannt wie das Plugin selbst und befindet sich üblicherweise unter folgendem Pfad:

/opt/digiverso/goobi/config/

Workflow Plugins

Die Workflow Plugins sind technisch sehr ähnlich zu den Administration Plugins. Auch sie können eine eigenständige Nutzeroberfläche für die Bereitstellung zusätzlicher Funktionalität anbieten. Im Gegensatz zu den Adminstration Plugins ist der Zugriff auf diese Plugins jedoch auch ohne administrative Rechte innerhalb von Goobi möglich, so dass üblicherweise ein größerer Benutzerkreis Zugriff auf diese Funktionen erhält.

Die Installation der Workflow Plugins erfolgt im Ordner:

/opt/digiverso/goobi/plugins/workflow/

Da die meisten Workflow Plugins neben der eigentlichen Funktionalität ausserdem über eine Nutzeroberfläche verfügen, so muss diese zusätzlich in folgenden Ordner installiert werden:

/opt/digiverso/goobi/plugins/GUI/

Manche Administration Plugins verfügen über eine eigene Konfigurationsdatei. Diese ist im allgemeinen so benannt wie das Plugin selbst und befindet sich üblicherweise unter folgendem Pfad:

/opt/digiverso/goobi/config/

Dashboard Plugins

Mit den Dashboard Plugins besteht die Möglichkeit, dass statt der Standardstartseite ein besonderes Dashboard mit zusätzlicher Funktionalität bereitgestellt wird. Diese könnte beispielsweise bereits einige statistische Informationen anzeigen, die integration mit anderen Systemen aufzeigen und auch einen Einblick in das aktuelle Monitoring geben.

Die Installation der Dashboard Plugins erfolgt im Ordner:

/opt/digiverso/goobi/plugins/dashboard/

Die Nutzeroberfläche der Dashboards muss zusätzlich in folgenden Ordner installiert werden:

/opt/digiverso/goobi/plugins/GUI/

Einige Dashboard Plugins verfügen über eine eigene Konfigurationsdatei. Diese ist im allgemeinen so benannt wie das Plugin selbst und befindet sich üblicherweise unter folgendem Pfad:

/opt/digiverso/goobi/config/

Außerdem ist zu beachten, dass individuelle Dashboards stets innerhalb der Hauptkonfigurationsdatei goobi_config.properties aktiviert werden müssen. Dies erfolgt beispielsweise wie folgt:

dashboardPlugin=intranda_dashboard_extended

Statistik Plugins

Zur Bereitstellung individueller Statistiken stehen die Statistik Plugins zur Verfügung. Abhängig davon, welche dieser Plugins installiert sind, können so verschiedenste Statistische Auswertungen erfolgen, die entweder als Diagramme, als Tabellen oder auch als Download in verschiedenen Formaten erfolgen können.

Die Installation der Statistik Plugins erfolgt im Ordner:

/opt/digiverso/goobi/plugins/statistics/

Die Nutzeroberfläche der Dashboards muss zusätzlich in folgenden Ordner installiert werden:

/opt/digiverso/goobi/plugins/GUI/

Validation Plugins

Die Validation Plugins dienen in Goobi dafür, dass vor Abschluß eines Arbeitsschrittes zunächst sichergestellt wird, dass Daten so vorliegen wie gewünscht. Ist die Durchführung der Validierung nicht erfolgreich, so kann der Nutzer die Aufgabe nicht abschließen und somit auch nicht aus seiner Aufgabenliste entfernen.

Die Installation der Validation Plugins erfolgt im Ordner:

/opt/digiverso/goobi/plugins/validation/

Anschließend muss für den gewünschten Arbeitsschritt das Validierungsplugin innerhalb der Aufgabe im Feld Validierungsplugin entsprechend ausgewählt werden.

Einige Validation Plugins verfügen über eine eigene Konfigurationsdatei. Diese ist im allgemeinen so benannt wie das Plugin selbst und befindet sich üblicherweise unter folgendem Pfad:

/opt/digiverso/goobi/config/

Generische Plugins

Bei den generischen Plugins handelt es sich um Plugins, die perspektivisch an verschiedenen Stellen der Nutzeroberfläche integriert werden können. Derzeitig können sie entweder direkt in die Menüleiste oben oder in die Fußleiste unten integriert werden.

Die Installation der generischen Plugins erfolgt im Ordner:

/opt/digiverso/goobi/plugins/generic/

Die Nutzeroberfläche der generischen Plugins muss zusätzlich in folgenden Ordner installiert werden:

/opt/digiverso/goobi/plugins/GUI/

REST Plugins

Mittels der REST Plugins verfügt Goobi über eine weitere Möglichkeit, dass externe Systeme mit Goobi kommunizieren. Im Gegensatz zur Web-API erfolgt hier die Kommunikation allerdings über REST und findet größtenteils über JSON statt.

Die Installation von REST Plugins erfolgt in folgendem Ordner:

/opt/digiverso/goobi/lib/

Ebenso wie die Web-API Plugins verfügen auch die REST Plugins über keine eigene Nutzeroberfläche. Auch wird die Berechtigung für den Zugriff über die gleiche Konfigurationsdatei gesteuert und kontrolliert damit den Zugriff von ausgewählten IP-Adressen und unter Prüfung einer Authentifizierung. Für die REST Plugins erfolgt die Konfiguration dabei in folgender Datei:

/opt/digiverso/goobi/config/goobi_rest.xml

Nach der Durchführung der Installation des Plugins und der zugehörigen Datenbank muss ebenfalls noch eine Konfiguration des Plugins erfolgen. Diese findet innerhalb der Konfigurationsdatei plugin_intranda_administration_archive_management.xml statt und ist beispielhaft wie folgt aufgebaut:

Allgemeine Konfiguration

Im Bereich <export> wird die Anbindung an den Goobi viewer konfiguriert. Hier wird der Ort festgelegt, an den ein Export als EAD-XML erfolgt und welche Bestände exportiert werden sollen. Der Export erfolgt automatisch in regelmäßigen Abständen oder kann manuell aus der Nutzeroberfläche gestartet werden.

Im zweiten Bereich <backup> kann ein automatisches Backup der einzelnen Bestände konfiguriert werden. Dabei wird für jeden Bestand eine eigene Datei erzeugt. Es kann definiert werden, wie viele Backups vorgehalten werden sollen und welches Tool zum Erzeugen der Backups genutzt werden soll. Falls ein Passwort für den Datenbank-Zugriff benötigt wird, kann dies hier ebenfalls konfiguriert werden.

Anschließend folgt ein wiederholbarer <config> Block. Über das wiederholbare Element <archive> kann festgelegt werden, für welche Dateien der <config>-Block gelten soll. Soll es einen Default-Block geben, der für alle Dokumente gelten soll, kann * genutzt werden.

Mittels <processTemplateId> wird festgelegt, auf Basis welcher Produktionsvorlage die Goobi-Vorgänge erstellt werden sollen.

Konfiguration der Generierung von Vorgangstiteln

Die Parameter <lengthLimit> <separator> <useIdFromParent> und <title> werden verwendet, um die Benennung des zu erzeugenden Vorgangs zu konfigurieren:

• Der Wert <lengthLimit> setzt ein Längenlimit für alle Tokens außer dem manuell gesetzten Präfix und Suffix. Die Voreinstellung ist 0, begrenzt die Länge also nicht.

• Der Parameter <separator> definiert das Trennzeichen, das verwendet werden soll, um alle separaten Tokens zu kombinieren. Die Voreinstellung ist _.

• Der Parameter <useIdFromParent> konfiguriert, wessen ID für die Erstellung des Vorgangstitels verwendet werden soll. Wenn er auf true gesetzt ist, wird die ID des übergeordneten Knotens verwendet. Andernfalls wird die ID des aktuellen Knotens verwendet.

• Der Parameter <title> konfiguriert, welche Metadaten für die Titelgenerierung genutzt werden sollen. Dabei kann das Attribut value einen statischen Text oder das Attribut name den Namen eines Metadatenfeldes beinhalten. Mittels type wird gesteuert, was mit dem Wert geschehen soll NORMAL fügt das Feld unverändert ein, CAMEL_CASE ersetzt Leerzeichen und lässt jedes Wort mit einem Großbuchstaben starten, AFTER_LAST_SEPARATOR fügt das Feld immer am Ende an, BEFORE_FIRST_SEPARATOR fügt es immer am Anfang an. Wenn kein title konfiguriert wurde, wird der Vorgangstitel auf Basis der node ID gebildet.

Konfiguration der Verknüpfung zwischen Knoten und Vorgang

Die beiden Parameter <nodeIdentifierField> und <processIdentifierField> dienen zur Verknüpfung zwischen Knoten und Vorgang. Im Feld <nodeIdentifierField> steht der Name des Feldes, das den Identifier des Knotens enthält. Dabei kann jedes konfigurierte Feld genutzt werden. Wenn nicht anders angegeben, wird id genutzt. In <processIdentifierField> steht das Metadatum, in dem der Identifier des Knotes gespeichert werden soll. Üblicherweise ist dies NodeId.

Wenn eine neue EAD Datei importiert wird oder der Button "Verweise zu Vorgängen aktualisieren" genutzt wird, wird in allen Vorgängen nach dem konfigurierten Metadatum gesucht. Anschließend wird verglichen, ob das Metadatum den Wert enthält, der im Feld in einem Knoten eingetragen ist. Wenn dies der Fall ist, wird eine Verknüpfung zwischen Knoten und Vorgang erstellt. Bei allen Knoten, zu denen kein Treffer gefunden wurde, werden eventuell vorhandene Verweise entfernt.

Konfiguration der Metadatenfelder

Anschließend folgt eine Liste von <metadata> Elementen. Darüber wird gesteuert, welche Felder angezeigt werden, importiert werden können, wie sie sich verhalten sollen und ob es Validierungsregeln gibt.

Pflichtangaben

Jedes Metadatenfeld besteht aus mindestens den folgenden Pflichtangaben:

Optionale Angaben

Des weiteren gibt es noch eine Reihe weiterer optionaler Angaben:

Beispiele für verschiedene Feld-Konfigurationen

Einfaches Eingabefeld

Textfeld

Auswahlliste

Mehrfachauswahl

Validierung von Datumsangaben im ISO 8601 Format

Validierung von Datumsangaben im EDTF Format

Anbindung eines kontrollierten Vokabulars

Verknüpfung auf einen anderen Knoten innerhalb des Bestandes

Suche in der GND

Suche in Geonames

Suche in VIAF

Konfiguration der Anzeige der Bereiche

In der Standardeinstellung sind die einzelnen Bereiche 1. Identifikation, 2. Kontext, 3. Inhalt und innere Ordnung, 4. Zugangs- und Benutzungsbedingungen, 5. Sachverwandte Unterlagen, 6. Anmerkungen und 7. Verzeichnungskontrolle aus Platzgründen eingeklappt und werden nicht angezeigt. Damit sie bereits beim auswählen eines Knotens ausgeklappt und angezeigt werdden, kann das Element <showGroup level="1" /> verwendet werden. Über die Ordnungsnummer im Attribut level wird gesteuert, welcher Bereich ausgeklappt wird. Um auch unausgefüllte Metadaten gleich anzuzeigen, ohne sie mittels Badge hinzuzufügen, kann innerhalb der <metadata> Definition das Attribut showField="true" genutzt werden.

Konfiguration des XML Namensraums

Die beiden Elemente <eadNamespaceRead> und <eadNamespaceWrite> legen fest, welche XML Namespaces zum lesen und schreiben von EAD Dokumenten verwendet werden sollen. Üblicherweise enthalten beide den gleichen Wert. Es können jedoch auch EAD2 Dokumente gelesen und als EAD3 Dokumente exportiert werden. Dann müssen die entsprechenden Namespaces definiert werden und bei den xpath Ausdrücken der einzelnen Metadaten darauf geachtet werden, dass beide Varianten angeggeben sind. Daher ist es einfacher, den beigelegten Konverter zu nutzen und die Konvertierung von EAD2 nach EAD3 vor dem einspielen der Dokumente zu machen.

• Namespace für ead2 (deprecated): urn:isbn:1-931666-22-9

• Namespace für ead3 (aktuell): http://ead3.archivists.org/schema/

• Namespace für ead4 (im draft Status): https://archivists.org/ns/ead/v4

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.

1. Teilschritt: Erzeugung der Export-Dateien für Vorgänge

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.

Export mittels GoobiScript

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:

action:exportDatabaseInformation

Nach der Ausführung dieses GoobiScripts findet sich in jedem Vorgangsordner die jeweilige Export-xml-Datei (z.B. 5_db_export.xml).

Manueller Export für einzelne Vorgänge

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.

2. Teilschritt: Export der Produktionsvorlagen

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.

3. Teilschritt: Export der Infrastruktur

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.

Übersicht

Einführung

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.

Installation und Konfiguration

Bevor die Verwendung des Export- und Import-Mechanismus erfolgen kann, müssen verschiedene Installations- und Konfigurationsschritte durchlaufen werden. Diese sind hier im Detail beschrieben:

Arbeitsweise

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:

a) Erzeugung der Export-Verzeichnisse

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.

b) Transfer 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.

c) Einspielen 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.

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.

Transfer mittels einer externen Festplatte

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:

Transfer über das Internet

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:

Transfer in ein S3 Bucket eines AWS-Systems

Zum Export in ein S3 Bucket nach AWS kann das Skript s3sync.py verwendet werden.

Übersicht

Einführung

Dieses Plugin für Goobi workflow stellt Bildordner wieder her, die zuvor mit dem Plugin goobi-plugin-step-archiveimagefolder archiviert wurden.

Installation

Das Plugin besteht insgesamt aus den folgenden zu installierenden Dateien:

Diese Dateien müssen in den richtigen Verzeichnissen installiert werden, so dass diese nach der Installation in folgenden Pfaden vorliegen:

Für eine Nutzung dieses Plugins muss der Nutzer über die korrekte Rollenberechtigung verfügen. Bitte weisen Sie daher der Benutzergruppe die Rolle Plugin_administration_restorearchivedimagefolders zu.

Überblick und Funktionsweise

Das Plugin bietet eine grafische Oberfläche an, die über das Menü Administration geöffnet werden kann. Dort kann dann ein Suchfilter verwendet werden, wie er auch an anderen Stellen von Goobi workflow (z.B. für die Vorgangsliste) verwendet wird. Mit einem Klick auf Plugin ausführen, werden dann die für die über den eingegebenen Filter gefundenen Vorgänge die Bilder wieder hergestellt. Die Nutzeroberfläche aktualisiert sich automatisch.

Konfiguration

Die Konfigurationsdatei ist im Moment leer, muss aber trotzdem vorliegen.

Die Information, woher die Daten geholt werden sollen, sind im jeweiligen Vorgangsordner in einer XML-Datei vom Archivierungs-Plugin hinterlegt worden.

Für die Authentifizierung an ssh-Servern wird an den üblichen Stellen ($USER_HOME/.ssh) nach public keys gesucht. Andere Authentifizierungsmethoden wie username/password sind nicht vorgesehen.

Die folgenden Funktionen stehen innerhalb des Plugins für das Archive-Management zur Verfügung:

Auswahl von vorhandenen Beständen

Nachdem das Plugin geöffnet wurde, wird zunächst eine Liste der zur Verfügung stehenden Archivbestände angezeigt. Hier kann der Nutzer einen Archivbestand auswählen und mit der Bearbeitung beginnen.

Alternativ dazu kann ebenfalls ein neuer Archivbestand erzeugt werden. In diesem Fall muss zunächst ein Name für den Bestand vergeben werden. Der Name muss eindeutig sein, da darüber die Identifikation erfolgt. Außerdem sollten keine Sonderzeichen wie :/\ genutzt werden, da der Name auch Grundlage für den Dateiname des EAD-Exports ist.

Als dritte Möglichkeit kann eine vorhandene Datei importiert werden. Hier kann eine EAD-Datei ausgewählt und hochgeladen werden. Wenn noch kein Bestand mit dem Namen der Datei existiert, wird die Datei als neuer Bestand importiert und direkt geöffnet. Falls der Name schon in Verwendung ist, kann nach einer Rückfrage der bestehende Bestand mit dem Inhalt der EAD-XML Datei überschrieben werden.

Sofern der Nutzer über die Berechtigung zur Erstellung neuer Bestände verfügt, kann mit dem entsprechenden Button ebenfalls eine Kopie eines Bestandes erstellt werden. Dabei wird ein neuer Bestand erstellt und alle Knoten mit all ihren Metadaten kopiert. Einzige Ausnahme ist hierbei die ID der Knoten. Diese werden automatisch neue erstellt und den Knoten zugewiesen.

Nach der Auswahl des zu bearbeitenden Archivbestandes wird der Nutzer in die Bearbeitungsmaske weitergeleitet. Hier läßt sich nun im linken Bereich der Strukturbaum bearbeiten. Im rechten Bereich können die Details des jeweils ausgewählten Knoten bearbeitet werden.

Durch einen Klick auf die Buttons Abbrechen (Leserechte) oder Archivbestand speichern und verlassen (Schreibrechte) wird man wieder auf die Seite zur Auswahl eines Archivbestandes geleitet.

Strukturbaum bearbeiten

Im linken Bereich der Bearbeitungsmaske lässt sich die Struktur des Archivbestandes bearbeiten. Hier lassen sich alle Knoten inklusive ihrer Hierarchie auf einen Blick einsehen. Vor jedem Element befindet sich ein Icon, mit dem sich die Unterelemente des Knotens anzeigen oder ausblenden lassen. Um einen Knoten auszuwählen, kann er angeklickt werden. Er wird dann farbig hervorgehoben und die Details des ausgewählten Knotens werden auf der rechten Seite angezeigt. Wenn ein Knoten im linken Bereich der Bearbeitungsmaske ausgewählt wurde, können ausserdem die Buttons am rechten Rand der linken Box genutzt werden, um den Knoten zu ändern. Folgende Optionen sind hierbei möglich:

Um mehrere Unterknoten auf einmal zu generieren, muss die Anzahl der zu erstellenden Knoten und deren Typ festgelegt werden. Anschließend können verschiedene Metadaten definiert werden, die in alle neuen Knoten eingetragen werden. Dabei kann entweder der gleiche Text in allen Feldern genutzt werden, ein Identifier generiert werden oder ein Text mit anschließendem Zähler generiert werden. Hierbei lässt sich das Zählerformat und der Startwert festlegen.

Im oberen Bereich der Hierarchieanzeige kann darüber hinaus auch eine Suche innerhalb der Metadaten der Knoten erfolgen. Dabei werden die gefundenen Knoten samt Hierarchie angezeigt und farbig hervorgehoben. Um die Suche wieder zurückzusetzen genügt es, den Inhalt des Suchbegriffs wieder zu leeren und entsprechen eine leere Suche auszuführen. Alternativ kann der Button auf der linken Seite des Suchfeldes genutzt werden.

Rechts neben dem Feld kann die erweiterte Suche genutzt werden. Hier kann gezielt in einzelnen Feldern gesucht werden. Welche Felder zur Verfügung stehen, kann über die Konfigurationsdatei gesteuert werden (Attribut searchable="true" innerhalb von <metadata>).

Bearbeitung eines ausgewählten Knotens

Sofern im linken Bereich ein Knoten ausgewählt wurde, werden im rechten Bereich die Details des ausgewählten Knotens angezeigt.

Der rechte Bereich ist dabei in mehrere Kategorien aufgeteilt. Im obersten Teil des rechten Bereichs wird der dazugehörige Goobi-Vorgang angezeigt, sowie eine Möglichkeit zum Erzeugen des Laufzettels. Wenn für den Knoten noch kein Goobi-Vorgang erzeugt wurde, kann ein neuer Vorgang auf der Basis der konfigurierten Produktionsvorlage erstellt werden. Als Dokumententyp wird entprechend der Konfiguration der ausgewählte Knotentyp verwendet. Abhängig von der Konfiguration und dem verwendeten Regelsatz stehen bespielsweise folgende Optionen zur Verfügung:

• Folder / Ordner

• File / Akte

• Image / Bild

• Audio

• Video

• Other / Sonstiges

Unterhalb des Dokumententyps werden die einzelnen Metadaten des Knotens aufgelistet. Sie sind gemäß des ISAD(G)-Standards in die folgenden Bereiche aufgeteilt:

• Identifikation

• Kontext

• Inhalt und innere Ordnung

• Zugangs- und Benutzungsbedingungen

• Sachverwandte Unterlagen

• Anmerkungen

• Verzeichnungskontrolle

Jeder dieser Bereiche lässt sich einzeln auf- und zuklappen. Auch wenn hierbei ein Bereich zugeklappt ist, läßt sich sehr einfach erkennen, welche Metadaten pro Bereich möglich und welche bereits ausgefüllt sind. Die einzelnen Metadaten werden dabei als verschieden hervorgehobene Badges angezeigt. Ein dunkler Hintergrund zeigt an, dass für diese Metadatum bereits ein Wert erfasst wurde. Ein heller Hintergrund hingeben bedeutet, dass dieses Feld noch ohne Inhalt ist. Sofern ein Feld wiederholbar angelegt werden kann, enthält der Badge ein Plus-Icon.

Wenn die Details eines Bereiches ausgeklappt werden, erfolgt eine Anzeige der einzelnen Metadaten. Standardmäßig werden dabei nur diejenigen Felder angezeigt, die bereits über einen Wert verfügen. Weitere Felder lassen sich durch einen Klick auf eines der Badges hinzufügen. Über das Minus-Icon lassen sich Felder wieder entfernen.

Validierung der Metadaten

Sowohl der Button Download als EAD Datei als auch der Button Validierung ausführen stellen sicher, dass die Metadaten valide sind. Dabei werden die konfigurierten Regeln angewendet und es wird geprüft, ob einzelne Werte dagegen verstoßen. Ist dies der Fall, werden die betroffenen Knoten im linken Bereich farbig hervorgehoben. Wird ein solcher invalider Knoten ausgewählt, werden die betroffenen Badges rot dargestellt und in den Metadaten wird neben der Umrandung auch der konfigurierte Fehlertext angezeigt.

Eine fehlgeschlagene Validierung verhindert nicht das Speichern des Archivbestandes oder das Erzeugen von Goobi-Vorgängen.

Speichern der Daten

Sofern die Bearbeitung nicht nur im read-only Modus erfolgt, werden Daten immer automatsich gespeichert, wenn man Knoten einfügt oder löscht, zu einem anderen Knoten wechselt, den Bestand exportiert, eine Kopie davon erstellt oder Verweise erstellt oder die Bearbeitung mittels Speichern und verlassen beendet.

Export und Download

Die beiden Buttons zum Download als EAD Datei und Viewer export erzeugen eine neue EAD auf Basis des aktuellen Zustandes der Knoten. Dabei wird mit Ausnahme des obersten Knoten jeder Knoten als eigentständiges <c>-Element dargestellt. Die Daten des obersten Knoten werden innerhalb von <archdesc> unterhalb des <ead> Elements geschrieben.

Beim Viewer export wird die erzeugte Datei in den Hotfolder des Goobi viewers geschrieben, beim Download hingegen kann sie lokal gespeichert werden.

Die erzeugte Datei enthält dabei alle Metadaten in der Form, in der sie in der Konfigurationsdatei angegeben wurden. Dabei wird der Inhalt des xpath Attributs der Metadaten genutzt. Wenn für ein Feld keine Angabe existiert, handelt es sich um ein intenes Metadatum, das nicht als EAD exportiert wird.

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.

1. Ausgangssystem

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.

1.1. Installation

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:

/opt/digiverso/goobi/plugins/administration/plugin_intranda_administration_goobi2goobi_export.jar
/opt/digiverso/goobi/plugins/GUI/plugin_intranda_administration_goobi2goobi_export-GUI.jar

Zu beachten ist hierbei, dass diese Dateien für den Nutzer tomcat lesbar sein müssen.

1.2. Konfiguration

Um dem Nutzer zu ermöglichen, dass dieser einen Export der Daten durchführen kann, muss dieser über die folgenden Rollen verfügen:

Datenbankdetails exportieren
Plugin_goobi2goobi_export

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.

2. Zielsystem

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.

2.1. Installation

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:

/opt/digiverso/goobi/plugins/administration/plugin_intranda_administration_goobi2goobi_import.jar
/opt/digiverso/goobi/plugins/GUI/plugin_intranda_administration_goobi2goobi_import-GUI.jar

Nach der Installation des eigentlichen Plugins müssen ebenfalls die zugehörigen Konfigurationsdateien installiert werden. Diese befinden sich unter folgenden Pfaden:

/opt/digiverso/goobi/config/plugin_intranda_administration_goobi2goobi_import_data.xml
/opt/digiverso/goobi/config/plugin_intranda_administration_goobi2goobi_import_infrastructure.xml

Auch hier ist wieder zu beachten, dass die installierten Dateien alle für den Nutzer tomcat lesbar sein müssen.

2.2. Allgemeine Konfiguration

Um einem Nutzer die Durchführung des Imports zu ermöglichen, muss dieser über die folgende Rolle verfügen:

Plugin_goobi2goobi_import

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.

2.3. Konfiguration für den Import der Infrastruktur

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:

<config_plugin>
    <config>
        <project name="intranda test project">
            <newProjectName>new project name</newProjectName>
            <!-- filegroups -->
            <filegroup name="SDB">
                <newFilegroupName>OBJECTS</newFilegroupName>
                <path>file:///opt/digiverso/viewer/media/$(meta.CatalogIDDigital)/</path>
                <mimeType>image/jp2</mimeType>
                <fileSuffix>jp2</fileSuffix>
                <folderValidation></folderValidation>
            </filegroup>
            <fileFormatInternal>Mets</fileFormatInternal>
            <fileFormatDmsExport>Mets</fileFormatDmsExport>
            <exportConfiguration useDmsImport="true" dmsImportCreateProcessFolder="false" dmsImportTimeOut="0" dmsImportRootPath="/opt/digiverso/viewer/hotfolder" dmsImportImagesPath="/opt/digiverso/viewer/hotfolder" dmsImportSuccessPath="/opt/digiverso/viewer/success" dmsImportErrorPath="/opt/digiverso/viewer/error" />
            <metsConfiguration metsRightsOwnerLogo="" metsRightsOwnerSite="" metsRightsOwnerMail="" metsDigiprovReference="" metsDigiprovPresentation="" metsDigiprovReferenceAnchor="" metsPointerPath="" metsPointerPathAnchor="" metsPurl="" metsContentIDs="" metsRightsSponsor="" metsRightsSponsorLogo="" metsRightsSponsorSiteURL="" metsRightsLicense="" />
        </project>

        <docket name="example docket">
            <newDocketName>first docket</newDocketName>
            <newFileName>docket.xsl</newFileName>
        </docket>

        <ruleset name="example ruleset">
            <newRulesetName>default ruleset</newRulesetName>
            <newFileName>ruleset.xml</newFileName>
        <ruleset>

        <ldap name="default ldap">
            <newLdapName>default ldap</newLdapName>
            <ldapConfiguration homeDirectory="" gidNumber="" dn="" objectClass="" sambaSID="" sn="" uid="" description="" displayName="" gecos="" loginShell="" sambaAcctFlags="" sambaLogonScript="" sambaPrimaryGroupSID="" sambaPwdMustChange="" sambaPasswordHistory="" sambaLogonHours="" sambaKickoffTime="" />
        </ldap>

        <usergroup name="Administration">
            <newUsergroupName>Admin</newUsergroupName>
            <addRole>administration_import_data</addRole>
            <removeRole>administration_export_data</removeRole>
            <addUser>johndoe</addUser>
            <removeUser>testadmin</removeUser>
        </usergroup>

        <user name="testadmin">
            <addAssignedProject>test project</addAssignedProject>
            <removeAssignedProject>example project</removeAssignedProject>
            <configuration place="" ldapgroup="" tablesize="" shortcut="" displayDeactivatedProjects="" displayFinishedProcesses="" displaySelectBoxes="" displayIdColumn="" displayBatchColumn="" displayProcessDateColumn="" displayLocksColumn="" displaySwappingColumn="" displayModulesColumn="" displayMetadataColumn="" displayThumbColumn="" displayGridView="" displayAutomaticTasks="" hideCorrectionTasks="" displayOnlySelectedTasks="" displayOnlyOpenTasks="" displayOtherTasks="" metsDisplayTitle="" metsLinkImage="" metsDisplayPageAssignments="" metsDisplayHierarchy="" metsDisplayProcessID="" customColumns="" customCss=""/>
        </user>
    </config>
</config_plugin>

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.

2.4. Konfiguration für den Import der Daten

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:

<?xml version="1.0"?>
<config_plugin>
    <globalConfig>
        <dbExportPrefix>import/</dbExportPrefix>
        <importPath>/opt/digiverso/goobi/metadata/</importPath>
        <bucket>example-workflow-data</bucket>
        <createNewProcessIds>true</createNewProcessIds>
        <temporaryImportFolder>/opt/digiverso/transfer/</temporaryImportFolder>
    </globalConfig>
    <config>
        <rulename>Project A</rulename>
        <rulename>Project B</rulename>
        <step name="Example to delete" type="delete" />
        <step name="Example to change" type="change">
            <newStepName>New step name</newStepName>
            <priority>5</priority>
            <order>3</order>
            <useHomeDirectory>0</useHomeDirectory>
            <stepStatus>0</stepStatus>
            <types metadata="true" automatic="false" readImages="false" writeImages="false" export="false" validateOnExit="true" finalizeOnAccept="false" delayStep="false" updateMetadataIndex="false" generateDocket="false" batchStep="false" stepPlugin="" validationPlugin="" />
            <scriptStep scriptStep="true" scriptName1="script 1" scriptPath1="/bin/bash ..." scriptName2="" scriptPath2="" scriptName3="" scriptPath3="" scriptName4="" scriptPath4="" scriptName5="" scriptPath5="" />
            <httpStep httpStep="true" httpMethod="POST" httpUrl="http://itm.example.com/itm/service" httpJsonBody="{ .... } " httpCloseStep="false" />
            <usergroup>Administration</usergroup>
            <usergroup>AutomaticTasks</usergroup>
        </step>
        <step name="Example to change" type="insertAfter" >
            <newStepName>Export task</newStepName>
            <order>120</order>
            <stepStatus>0</stepStatus>
            <types automatic="true" export="true" stepPlugin="special_export_plugin" />
            <usergroup>AutomaticTasks</usergroup>
        </step>
        <docket name="Default docket">
            <newDocketName>docket</newDocketName>
            <newFileName>docket.xsl</newFileName>
        </docket>
        <project name="Project A">
            <newProjectName>Project B</newProjectName>
        </project>
        <property name="CollectionName">
            <oldPropertyValue>Digitised</oldPropertyValue>
            <newPropertyName>Collection</newPropertyName>
            <newPropertyValue>default_collection</newPropertyValue>
        </property>
        <ruleset name="Default">
            <newRulesetName>default ruleset</newRulesetName>
            <newFileName>ruleset.xml</newFileName>
        </ruleset>
        <metadata name="CatalogIDDigital" type="change">
            <valueConditionRegex>/b\d+(?:_\d+)?/</valueConditionRegex>
            <valueReplacementRegex>s/^(.+)$/IMPORT_$1/g</valueReplacementRegex>
            <position>all</position>
        </metadata>
        <metadata name="PhysicalLocation" type="delete">
            <position>top</position>
        </metadata>
        <metadata name="Testmetatda" type="add">
            <valueReplacementRegex>example text</valueReplacementRegex>
            <position>top</position>
        </metadata>
        <skipProcesslog>true</skipProcesslog>
        <skipUserImport>true</skipUserImport>
    </config>
</config_plugin>

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.

Arbeitsschritte innerhalb der Workflows: step

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.

Laufzettel: docket

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.

Projekt: project

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.

Eigenschaften: property

Diese Regel dient zur Manipulation von Vorgangseigenschaften.

Regelsatz: ruleset

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.

Metadaten: metadata

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.

Weitere Konfigurationen

Innerhalb einer Regel können weitere allgemeine Einstellungen festgelegt werden.

Übersicht

Einführung

Die vorliegende Dokumentation beschreibt die Installation, die Konfiguration und den Einsatz des Administration Plugins für die Verwaltung von Archivbeständen aus Goobi workflow heraus. Dabei werden die Daten mehrerer Bestände verwaltet und erlauben auch kleinen Archiven eine standardisierte Datenerfassung ohne Inbetriebnahme einer kostenpflichtigen Drittsoftware. Der Export als standardisierte EAD-Dateien ist jederzeit möglich und kann auch automatisch in regelmäßigen Abständen durchgeführt werden.

Installation

Installation des Plugins

Das Plugin besteht insgesamt aus den folgenden zu installierenden Dateien

plugin-administration-archive-management-base.jar
plugin-administration-archive-management-gui.jar
plugin-administration-archive-management-job.jar
plugin-administration-archive-management-lib.jar
plugin_intranda_administration_archive_management.xml

Diese Dateien müssen in den richtigen Verzeichnissen installiert werden, so dass diese nach der Installation in folgenden Pfaden vorliegen:

/opt/digiverso/goobi/plugins/administration/plugin-administration-archive-management-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin-administration-archive-management-gui.jar
/opt/digiverso/goobi/plugins/GUI/plugin-administration-archive-management-job.jar
/opt/digiverso/goobi/plugins/GUI/plugin-administration-archive-management-lib.jar

Darüber hinaus benötigt das Plugin noch zusätzlich eine Konfigurationsdatei, die an folgender Stelle liegen muss:

/opt/digiverso/goobi/config/plugin_intranda_administration_archive_management.xml

Überblick und Funktionsweise

Das Plugin für die Bearbeitung von Archivbeständen findet sich unterhalb des Menüpunkts Administration.

Zur Nutzung des Plugins ist zunächst notwendig, dass der Nutzer über das Recht Plugin_Administration_Archive_Management verfügt. Sollte dieses Recht noch noch nicht zugewiesen worden sein, erhält der Nutzer folgenden Hinweis:

Die entsprechenden Rechte müssen den jeweiligen Benutzergruppen daher zunächst zugewiesen werden.

Nachdem die benötigten Rechte zugewiesen wurden und ggf. ein neuer Login erfolgte, kann die Nutzung des Plugins erfolgen.

Dabei hat der Nutzer erst einmal nur lesenden Zugriff. Um auch Daten ändern zu können, stehen folgende weitere Rechte zur Verfügung, die ggf. zusätzlich zugeweisen werden können:

Eine detaillierte Erläuterung über die Bedienung des Plugins bzw. dessen Funktionen findet sich auf dieser Seite:

Konfiguration

Nach erfolgter Installation erfolgt die Konfiguration des Plugins und der zugehörigen Oberfäche innerhalb der Konfigurationsdatei plugin_intranda_administration_archive_management.xml. Diese ist auf der folgenden Seite detailliert beschrieben:

Übersicht

Einführung

Die vorliegende Dokumentation beschreibt die Installation, die Konfiguration und den Einsatz des Administration-Plugins für die automatisiert wiederholte Abfrage von Daten (z.B. aus einem Katalog) zur Aktualisierung von Datensätzen in Goobi workflow.

Installation

Das Plugin besteht insgesamt aus den folgenden zu installierenden Dateien

plugin-administration-data-poller-base.jar
plugin-administration-data-poller-gui.jar
plugin-administration-data-poller-job.jar
plugin-administration-data-poller-lib.jar

Diese Dateien müssen in den richtigen Verzeichnissen installiert werden, so dass diese nach der Installation in den folgenden Pfaden vorliegen:

/opt/digiverso/goobi/plugins/administration/plugin-administration-data-poller-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin-administration-data-poller-gui.jar
/opt/digiverso/goobi/plugins/GUI/plugin-administration-data-poller-job.jar
/opt/digiverso/goobi/plugins/GUI/plugin-administration-data-poller-lib.jar

Daneben gibt es eine Konfigurationsdatei, die an folgender Stelle liegen muss:

/opt/digiverso/goobi/config/plugin_intranda_administration_data_poller.xml

Überblick und Funktionsweise

Das Data Poller Plugin wird automatisch durch Goobi aktiviert. Seine Laufzeit beginnt zu der konfigurierten Startzeit und wiederholt sich entsprechend der konfigurierten Anzahl an Stunden, bspw. alle 24 Stunden, also einmal täglich.

Möchte ein Nutzer zusätzlich zu dieser Automatik ebenfalls Zugriff auf die Nutzeroberfläche des Plugins haben, so muss er einer Benutzergruppe angehören, die hierfür das folgende Plugin-spezifische Recht erhalten hat:

Plugin_Goobi_DataPoller

Um dieses Recht zuzuweisen, muss der gewünschten Nutzergruppe zunächst die Berechtigung im rechten Bereich eingetragen werden.

Sollte die Berechtigung für die Benutzergruppe neu eingetragen werden, so muss sich der Nutzer zunächst einmal neu in Goobi einloggen, um diese Berechtigungsstufe verwenden zu können. Anschließend kann er im Menü Administration auf das Plugin Data Poller klicken und dort auch jederzeit eine Aktualisierung der Datensätze mittels Abfrage manuell neu anstoßen.

Automatische Backups

Sollte das Plugin für einen Vorgang aktualisierte Metadaten finden und daher die METS-Datei aktualisieren, so wird zunächst automatisch ein Backup der aktuellen METS-Datei meta.xml und sofern relevant auch der meta_anchor.xml erzeugt. Das Backup wird neben der aktualisierten METS-Datei gespeichert.

Logging innerhalb des Journals

Die Updates der Metadaten durch das Plugin finden üblicherweise vollautomatisch im Hintergrund statt. Um dennoch jederzeit für einen Datensatz nachvollziehen zu können, was mit diesem zwischenzeitlich passierte, werden die Ereignisse geloggt. Zu jedem Vorgang, für den es Änderungen aus diesem Plugin gab, werden daher automatisch detaillierte Einträge innerhalb des Journals eingefügt. Diese enthalten neben dem Zeitstempel unter anderem eine genaue Auflistung der geänderten Metadatenfelder samt der Inhalte. Somit ist es jederzeit möglich, auch den vorherigen bzw. den neuen Wert nachvollziehen zu können.

Konfiguration

Die Konfiguration des Plugins erfolgt über die Konfigurationsdatei plugin_intranda_administration_data_poller.xml und kann im laufenden Betrieb angepasst werden. Im folgenden ist eine beispielhafte Konfigurationsdatei aufgeführt:

<?xml version="1.0" encoding="UTF-8"?>
<config_plugin>

	<!-- multiple different rules can be defined for individual use cases.
        you can specify a start time and a delay in hours. the rule will only be executed if
        enabled is true. A rule can be of type filter or hotfolder. If the type hotfolder is
        used you must specify the path inside a path element in the rule.
    -->
	<rule title="SampleProject" enabled="false" startTime="22:00:00" delay="24">

		<!-- filter which items to run through please notice that filters that contain blanks
        need to be surrounded by quotation marks -->
		<filter>project:SampleProject</filter>
		<!--
		<filter>"project:Manuscript items"</filter>
        <path>/opt/digiverso/goobi/import/</path>
        -->

		<!-- which catalogue to use (GBV, Wiener, CBL Adlib ...) -->
		<catalogue>Wiener</catalogue>
		
		<!-- which catalogue field to use and which identifier to use for the 
		catalogue request (use standard variable replacer compatible value here) -->
		<catalogueField fieldName="12" fieldValue="$(meta.CatalogIDDigital)" />

		<!-- define if existing structure subelements shall be kept (true),
        otherwise a complete new mets file is created and overwrites the
        existing one (false) -->
		<mergeRecords>true</mergeRecords>

		<!-- define if children shall be analysed as well. If a sub element contains an 
		identifier, the metadata will get imported as well -->
		<analyseSubElements>true</analyseSubElements>

		<!-- execute an automatic export of updated records;
        this is only executed if mergeRecords is set to true -->
		<exportUpdatedRecords>false</exportUpdatedRecords>

       <!-- fieldList: Must have a mode attribute which can contain either blacklist or whitelist as a value.
            blacklist: All fields are updated except the defined ones. This is a potential dangerous setting!
            whitelist: Only the definied fields are updated. All others are skipped. 
            field: Use the internal metadata names from the ruleset as field definition
        -->
         <fieldList mode="blacklist">
            <field>viewerinstance</field>
            <field>singleDigCollection</field>
            <field>pathimagefiles</field>
            <field>_urn</field>
            <field>_representative</field>
         </fieldList>
        
		<!-- alwaysExecuteStepList: specify steps that shall be performed after each run of the rule
            step: name of the step that shall be executed
         -->
        <alwaysExecuteStepList>
            <step>resize images</step>
       </alwaysExecuteStepList>

        <!-- internal timestamp for the plugin to know when the rule was last executed -->
        <lastRun>1551731078691</lastRun>

	</rule>

	<rule type="filter" title="Archive project" enabled="false" startTime="21:00:00" delay="48">
		<filter>project:Archive</filter>
		<catalogue>K10Plus</catalogue>
		<catalogueField fieldName="12" fieldValue="$(meta.CatalogIDDigital)" />
		<mergeRecords>true</mergeRecords>
		<analyseSubElements>true</analyseSubElements>
		<exportUpdatedRecords>false</exportUpdatedRecords>
        <fieldList mode="whitelist">
		  <field>Author</field>
		  <field>PublicationYear</field>
		  <field>Subject</field>
		  <field>CreatorsAllOrigin</field>
        </fieldList>
	</rule>

	<rule type="filter" title="Manuscript project" enabled="false" startTime="23:00:00" delay="24">
		<filter>"project:Manuscript items"</filter>
		<catalogue>K10Plus</catalogue>
		<catalogueField fieldName="12" fieldValue="$(meta.CatalogIDDigital)" />
		<mergeRecords>true</mergeRecords>
		<analyseSubElements>true</analyseSubElements>
		<exportUpdatedRecords>false</exportUpdatedRecords>
        <fieldList mode="blacklist">
		  <field>TitleDocMain</field>
		  <field>CatalogueIDDigital</field>
		  <field>DocLanguage</field>
        </fieldList>fieldList mode="blacklist">
	</rule>

</config_plugin>

Attribute des rule Elementes

Unterelemente des rule Elementes

zusätzliche Elemente/Parameter - rule type filter

Zusätzliche Elemente/Parameter - rule type hotfolder

Übersicht

Einführung

Dieses Plugin dient zur direkten Bearbeitung der verschiedenen Konfigurationsdateien von Goobi workflow direkt aus der Benutzeroberfläche innerhalb des Webbrowsers.

Installation

Das Plugin besteht insgesamt aus den folgenden zu installierenden Dateien:

plugin_intranda_administration_config_file_editor_base-base.jar
plugin_intranda_administration_config_file_editor_gui-base.jar
plugin_intranda_administration_config_file_editor.xml

Diese Dateien müssen in den richtigen Verzeichnissen installiert werden, so dass diese nach der Installation unter den folgenden Pfaden vorliegen:

/opt/digiverso/goobi/plugins/administration/plugin_intranda_administration_config_file_editor-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin_intranda_administration_config_file_editor-gui.jar
/opt/digiverso/goobi/config/plugin_intranda_administration_config_file_editor.xml

Dieses Plugin verfügt über eine eigene Berechtigungsstufe für die Verwendung. Aus diesem Grund müssen Nutzer über die erforderlichen Rechte verfügen.

Bitte weisen Sie daher der Benutzergruppe der entsprechenden Nutzer das folgende Recht zu:

Plugin_administration_config_file_editor

Überblick und Funktionsweise

Nach der Installation ist das Plugin in einem eigenen Eintrag im Menü Administration zu finden, von wo es geöffnet werden kann.

Nach dem Öffnen werden auf der linken Seite alle Konfigurationsdateien von Goobi aufgelistet. Diese kann man durch Anklicken des jeweiligen Icons öffnen, um sie zu bearbeiten.

Bitte beachten Sie, dass die Konfigurationsdatei dieses Plugins aus Sicherheitsgründen standardmäßig nicht in der Liste erscheint und nur für Superadministratoren bearbeitbar ist.

Es werden außerdem keine versteckten Dateien und keine Dateien aus versteckten Ordnern angezeigt.

Öffnet man eine Datei, erscheint auf der rechten Seite ein Texteditor, in dem die Datei bearbeitet werden kann. Bearbeitet und speichert man eine Datei, wird im definierten Backupverzeichnis automatisch ein Backup angelegt.

Entsprechend des eingestellten Wertes in der Konfigurationsdatei bleibt hier eine gewisse Anzahl an älteren Backups erhalten, bevor diese durch neuere ersetzt werden.

Wurde eine Datei verändert und wird ohne zuvor zu speichern ein Wechsel zu einer anderen Datei versucht, bekommt der Bearbeiter eine Rückfrage, wie mit den Änderungen zu verfahren ist.

Innerhalb von Goobi können für Konfigurationsdateien Hilfetexte definiert werden, die für die Bearbeitung in diesem Editor behilflich sein können. Die hinterlegten Hilfetexte werden dabei abhängig von der derzeit geöffneten Datei im linken Bereich angezeigt und verfügen auch über die Möglichkeit, dass hier mit Formatierungen gearbeitet wird.

Konfiguration

Die Konfiguration des Plugins erfolgt über die Konfigurationsdatei plugin_intranda_administration_config_file_editor.xml und kann im laufenden Betrieb angepasst werden. Im folgenden ist eine beispielhafte Konfigurationsdatei aufgeführt:

<?xml version="1.0" encoding="UTF-8" ?>
<config_plugin>
    <!--
    The configFileDirectories element contains a list of directories
    that are used to collect all displayed files in the browser interface.

    Each directory should be an absolute path that contains xml or properties files.
    Other file types are not supported until now.
    The directory name may end with a slash (/), otherwise it will be added automatically.

    Backups are automatically created in a subfolder called "backup/".
    You can override this with the optional attribute backupFolder="myOwnBackupPath/".
    IMPORTANT: The directory must be an absolute path while the backupFolder parameter must be a relative path.
    The backup directory name may end with a slash (/), otherwise it will be added automatically.
    To save backup files in the selected configuration directory, overwrite the backup folder with backupFolder="".

    By default 8 backup files are kept, older files will be deleted.
    You can override this with the optional attribute backupFiles="".

    You can filter the displayed configuration files in a directory with the fileRegex="" parameter.
    If the parameter is not used or is empty, it will be ignored.
    -->

    <configFileDirectories>
        <directory backupFiles="16">/opt/digiverso/goobi/config/</directory>
        <directory backupFolder="wizzardBackup/" backupFiles="4">/opt/digiverso/layoutwizzard/</directory>
        <directory backupFolder="itmPluginsBackup/" backupFiles="4" fileRegex=".*\.xml">/opt/digiverso/itm/plugins/config/</directory>
        <directory backupFolder="itmBackup/" fileRegex=".*\.xml">/opt/digiverso/itm/config/</directory>
        <!--
        Example:
        <directory backupFolder="exampleBackup/" backupFiles="12" fileRegex="*\.xml">/opt/digiverso/example/config/</directory>
        -->
    </configFileDirectories>

</config_plugin>

Die Parameter innerhalb dieser Konfigurationsdatei haben folgende Bedeutungen:

Sollen Hilfetexte zu einzelnen Konfigurationsdateien angezeigt werden, so müssen diese innerhalb der messages-Dateien hinterlegt werden. Hierzu wird beispielsweise in diesen Dateien eine Anpassung vorgenommen:

/opt/digiverso/goobi/config/messages_de.properties
/opt/digiverso/goobi/config/messages_en.properties

Für jede Konfigurationsdatei kann dort in der jeweiligen Datei ein Wert wie die folgenden eingetragen werden.

Deutsche Fassung innerhalb der Datei messages_de.properties:

plugin_administration_config_file_editor_help_goobi_projects.xml = Dies ist ein Hilfetext für die Konfiguration der Anlegemaske. <br/>Hier kann eine <i>Beschreibung</i>, die <b>formatiert</b> ist.<br/><br/><pre>Und auch Quellcode kann hier stehen</pre>

Englische Fassung innerhalb der Datei messages_en.properties:

plugin_administration_config_file_editor_help_goobi_projects.xml = This is a help text for the creation mask. <br/>You can add a <i>Description</i> here, which is <b>formatted</b>.<br/><br/><pre>And you can put source code here as well</pre>

Zu beachten ist hierbei, dass jeweils der Präfix plugin_administration_config_file_editor_help_ vor dem Namen der Konfigurationsdatei angefügt wird.

Übersicht

Einführung

Dieses Dashboard-Plugin wurde entwickelt, um die Verwendung eines Barcode-Scanners in Goobi Workflow zu erleichtern. Es ermöglicht auf der rechten Seite der Oberfläche verschiedene Aktionen, wie z.B. das Annehmen und Abschließen von Aufgaben oder auch das Ändern des Standorts für Objekte.

Installation

Um das Plugin nutzen zu können, müssen folgende Dateien installiert werden:

Um zu konfigurieren, wie sich das Plugin verhalten soll, können verschiedene Werte in der Konfigurationsdatei angepasst werden. Die Konfigurationsdatei befindet sich üblicherweise hier:

Für eine Nutzung dieses Plugins muss der Nutzer innerhalb der Einstellungen für das Dashboard den Wert intranda_dashboard_barcode auswählen.

Überblick und Funktionsweise

Um dieses Dashboard-Plugin zu nutzen, muss man es zunächst über Einstellungen -> Allgemein -> Dashboard aktivieren und sich dann ggf. neu anmelden. Wenn das Plugin korrekt installiert und konfiguriert wurde, sollte es bereits unter dem Menüpunkt Dashboard aktiviert sein.

Auf der rechten Seite befindet sich ein Formular mit verschiedenen Aktionen. Sie können eine auswählen, indem Sie darauf klicken. Wird die Aktion Nur Ortsänderung gewählt, gibt es ein zusätzliches Eingabefeld, das den Namen des neuen Orts erwartet.

Für alle Aktionen gibt es ein obligatorisches Eingabefeld, in dem der Titel des Goobi-Vorgangs erwartet wird. Dieses Feld wird nach dem Laden automatisch fokussiert, um die Verwendung eines Barcodescanners zu erleichtern. Durch Anklicken des Buttons Ausführen wird die gewählte Aktion ausgeführt, und es werden Meldungen über den Erfolg ausgegeben. Die durchgeführte Aktion sowie der Eingabeort werden zur Erleichterung weiterer Anwendungen gespeichert. Sie bleiben unverändert, bis eine manuelle Änderung vorgenommen wird.

Im Fall, dass Ortwechsel erfasst werden, sind diese auch zu einem späteren Zeitpunkt jederzeit innerhalb des Journals noch nachvollziehbar.

Der jeweils aktuelle Aufenthaltsort des Objektes wird darüber hinaus in einer eigenen Eigenschaft gespeichert.

Konfiguration

Die Konfiguration des Plugins erfolgt in der Datei plugin_intranda_dashboard_barcode.xml wie hier aufgezeigt:

Die folgende Tabelle enthält eine Zusammenstellung der Parameter und ihrer Beschreibungen:

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.

1. Importieren der Infrastruktur

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:

2. Importieren von Vorgängen

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:

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:

Übersicht

Einführung

Die vorliegende Dokumentation beschreibt die Installation, die Konfiguration und den Einsatz des Administration Plugins für das automatisierte Zurücksetzen der Paginierung innerhalb einer großen Anzahl an Vorgängen innerhalb von Goobi workflow.

Installation

Das Plugin besteht insgesamt aus den folgenden zu installierenden Dateien:

plugin-intranda-administration-reset-pagination-base.jar
plugin-intranda-administration-reset-pagination-gui.jar
plugin_intranda_administration_reset_pagination.xml

Diese Dateien müssen in den richtigen Verzeichnissen installiert werden, so dass diese nach der Installation in folgenden Pfaden vorliegen:

/opt/digiverso/goobi/plugins/administration/plugin-intranda-administration-reset-pagination-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin-intranda-administration-reset-pagination-gui.jar
/opt/digiverso/goobi/config/plugin_intranda_administration_reset_pagination.xml

Überblick und Funktionsweise

Wenn das Plugin korrekt installiert und konfiguriert wurde, ist es innerhalb des Menüpunkts Administration zu finden. Nach dem Betreten können in der Oberfläche die oben beschriebenen Parameter noch einmal individuell angepasst werden.

Nach dem Klick auf den Button Plugin ausführen startet die Aktualisierung der METS-Dateien. Ein Fortschrittsbalken informiert über den Fortschritt. Innerhalb der Tabelle werden die bereits verarbeiteten Vorgänge aufgelistet und der jeweilige Status über den Erfolg der Durchführung angezeigt.

Konfiguration

Die Konfiguration des Plugins erfolgt über die Konfigurationsdatei plugin_intranda_administration_reset_pagination.xml und kann im laufenden Betrieb angepasst werden. Im folgenden ist eine beispielhafte Konfigurationsdatei aufgeführt:

<config_plugin>
	
	<!-- default filter to use -->
	<filter>stepdone:export</filter>
	
</config_plugin>

Für eine Nutzung dieses Plugins muss der Nutzer über die korrekte Rollenberechtigung verfügen. Bitte weisen Sie daher der Benutzergruppe die Rolle Plugin_administration_reset_pagination zu.

Übersicht

Einführung

Die vorliegende Dokumentation beschreibt die Installation, die Konfiguration und den Einsatz des Administration Plugins für das automatisierte Prüfung einer großen Anzahl an Vorgängen innerhalb von Goobi workflow mit dem zugewiesenen Regelsatz. Eventuelle Inkompatibilitäten mit den jeweiligen Regelsätzen werden ermittelt und eine entsprechende Meldung über die konkrete Inkompatibilität angezeigt.

Installation

Das Plugin besteht insgesamt aus den folgenden zu installierenden Dateien:

plugin_intranda_administration_ruleset_compatibility-base.jar
plugin_intranda_administration_ruleset_compatibility-gui.jar
plugin_intranda_administration_ruleset_compatibility.xml

Diese Dateien müssen in den richtigen Verzeichnissen installiert werden, so dass diese nach der Installation in folgenden Pfaden vorliegen:

/opt/digiverso/goobi/plugins/administration/plugin_intranda_administration_ruleset_compatibility-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin_intranda_administration_ruleset_compatibility-gui.jar
/opt/digiverso/goobi/config/plugin_intranda_administration_ruleset_compatibility.xml

Für eine Nutzung dieses Plugins muss der Nutzer über die korrekte Rollenberechtigung verfügen. Bitte weisen Sie daher der Benutzergruppe die Rolle Plugin_administration_ruleset_compatibility zu.

Überblick und Funktionsweise

Wenn das Plugin korrekt installiert und konfiguriert wurde, ist es innerhalb des Menüpunkts Administration zu finden. Nach dem Betreten können in der Oberfläche die oben beschriebenen Parameter noch einmal individuell angepasst werden.

Nach dem Klick auf den Button Plugin ausführen startet die Prüfung der METS-Dateien. Ein Fortschrittsbalken informiert über den Fortschritt. Innerhalb der Tabelle werden die bereits verarbeiteten Vorgänge aufgelistet. Eventuelle Inkompatibilitäten werden unmittelbar angezeigt. Darüber hinaus besteht die Möglichkeit, direkt den Metadateneditor einzelner Vorgänge zu betreten.

Konfiguration

Die Konfiguration des Plugins erfolgt über die Konfigurationsdatei plugin_intranda_administration_ruleset_compatibility.xml und kann im laufenden Betrieb angepasst werden. Im folgenden ist eine beispielhafte Konfigurationsdatei aufgeführt:

<config_plugin>
	
	<!-- default filter to use -->
	<filter>stepdone:export</filter>
	
</config_plugin>

Übersicht

Einführung

Dieses Plugin dient zur direkten Bearbeitung der Regelsatzdateien von Goobi workflow direkt aus der Benutzeroberfläche innerhalb des Webbrowsers.

Installation

Das Plugin besteht insgesamt aus den folgenden zu installierenden Dateien:

plugin-intranda-administration-ruleset-editor-base.jar
plugin-intranda-administration-ruleset-editor-gui.jar
plugin_intranda_administration_ruleset_editor.xml

Diese Dateien müssen in den richtigen Verzeichnissen installiert werden, so dass diese nach der Installation unter den folgenden Pfaden vorliegen:

/opt/digiverso/goobi/plugins/administration/plugin-intranda-administration-ruleset-editor-base.jar
/opt/digiverso/goobi/plugins/GUI/plugin-intranda-administration-ruleset-editor-gui.jar
/opt/digiverso/goobi/config/plugin_intranda_administration_ruleset_editor.xml

Dieses Plugin verfügt über eine eigene Berechtigungsstufe für die Verwendung. Aus diesem Grund müssen Nutzer über die erforderlichen Rechte verfügen.

Bitte weisen Sie daher der Benutzergruppe der entsprechenden Nutzer das folgende Recht zu:

Plugin_administration_ruleset_editor

Überblick und Funktionsweise

Nach der Installation ist das Plugin in einem eigenen Eintrag im Menü Administration zu finden, von wo es geöffnet werden kann.

Nach dem Öffnen werden auf der linken Seite alle Regelsätze von Goobi aufgelistet. Diese kann man durch Anklicken des jeweiligen Icons öffnen, um sie zu bearbeiten.

Öffnet man eine Datei, erscheint auf der rechten Seite ein Texteditor, in dem die Datei bearbeitet werden kann. Bearbeitet und speichert man eine Datei, wird im definierten Backupverzeichnis automatisch ein Backup angelegt.

Entsprechend des eingestellten Wertes in der Konfigurationsdatei bleibt hier eine gewisse Anzahl an älteren Backups erhalten, bevor diese durch neuere ersetzt werden.

Wurde eine Datei verändert und wird ohne zuvor zu speichern ein Wechsel zu einer anderen Datei versucht, bekommt der Beareiter eine Rückfrage, wie mit den Änderungen zu verfahren ist.

Konfiguration

Die Konfiguration des Plugins erfolgt über die Konfigurationsdatei plugin_intranda_administration_ruleset_editor.xml und kann im laufenden Betrieb angepasst werden. Im folgenden ist eine beispielhafte Konfigurationsdatei aufgeführt:

<config_plugin>
	
	<!-- By editing a ruleset file in the browser GUI, a backup file will be stored in the backup directory -->
	<rulesetBackupDirectory>/opt/digiverso/goobi/rulesets/backup/</rulesetBackupDirectory>

	<!-- backup files will be stored as ruleset.xml.1, ruleset.xml.2, ..., ruleset.xml.n -->
	<numberOfBackupFiles>10</numberOfBackupFiles>
	
</config_plugin>

Die Parameter innerhalb dieser Konfigurationsdatei haben folgende Bedeutungen:

Übersicht

Einführung

Dieses Plugin dient für einen speziellen Export von mehreren METS-Dateien pro Vorgang. Aus einer einzigen METS-Datei innerhalb von Goobi workflow entstehen so während des Exports für jedes enthaltene Strukturelement eine eigene METS-Datei mit den zugehörigen Bilddateien.

Diese Plugin wurde für das Bundesdenkmalamt in Österreich entwickelt und ist funktionell auf dessen Bedürfnisse ausgerichtet und somit gegebenenfalls nicht für andere Anwendungsfälle unmittelbar einsetzbar.

Installation

Das Plugin besteht insgesamt aus den folgenden zu installierenden Dateien:

Diese Datei muss in dem folgenden Verzeichnis installiert werden:

Überblick und Funktionsweise

Zur Inbetriebnahme des Plugins muss dieses für einen oder mehrere gewünschte Aufgaben im Workflow aktiviert werden. Dies erfolgt wie im folgenden Screenshot aufgezeigt durch Auswahl des Plugins intranda_export_singleImage aus der Liste der installierten Plugins.

Da dieses Plugin üblicherweise automatisch ausgeführt werden soll, sollte der Arbeitsschritt im Workflow als automatisch konfiguriert werden. Darüber hinaus muss die Aufgabe als Export-Schritt markiert sein.

Nachdem das Plugin vollständig installiert und eingerichtet wurde, wird es üblicherweise automatisch innerhalb des Workflows ausgeführt, so dass keine manuelle Interaktion mit dem Nutzer erfolgt. Stattdessen erfolgt der Aufruf des Plugins durch den Workflow im Hintergrund und führt die folgenden Arbeiten durch:

Für jedes Strukturelement innerhalb der METS-Datei wird während des Exports eine eigenständige METS-Datei erzeugt, zu der die jeweiligen Bilddateien zugehörig mitexportiert werden. Die Gesamt-METS-Datei wird nicht mit exportiert. Die Anzahl der somit erzeugten METS-Dateien weicht entsprechend von der Anzahl der Goobi Vorgänge ab und entspricht der Anzahl der vorhandenen Strukturelemente.

Konfiguration

Dieses Plugin verfügt über keine eigene Konfigurationsdatei.

Übersicht

Einführung

Dieses Dashboard Plugin ermöglicht durch eine detaillierte Darstellung einen verbesserten Überblick. Es können beispielsweise die zuletzt bearbeiteten Aufgaben oder relevante Statistiken angezeigt werden.

Installation

Um das Plugin nutzen zu können, müssen folgende Dateien installiert werden:

Für eine Nutzung dieses Plugins muss der Nutzer innerhalb der Einstellungen für das Dashboard den Wert intranda_dashboard_extended auswählen.

Überblick und Funktionsweise

Wenn das Plugin korrekt installiert ist und Nutzer sich dieses als Dashboard eingestellt haben, ist es nach dem Login in Goobi workflow anstelle der Startseite sichtbar.

Konfiguration

Die Konfiguration des Plugins erfolgt in der Datei plugin_intranda_dashboard_extended.xml wie hier aufgezeigt:

Die folgende Tabelle enthält eine Zusammenstellung der Parameter und ihrer Beschreibungen:

Übersicht

Einführung

Die vorliegende Dokumentation beschreibt die Installation, Konfiguration und den Einsatz des Export-Plugins für die Erzeugung spezieller Exportpakete für die Software Imagen Media Archive Management. Innerhalb des Plugins werden hierbei derzeit 5 spezielle Publikationstypen berücksichtigt und jeweils individuell verarbeitet.

Installation

Um das Plugin nutzen zu können, müssen folgende Dateien installiert werden:

Nach der Installation des Plugins kann dieses innerhalb des Workflows für die jeweiligen Arbeitsschritte ausgewählt und somit automatisch ausgeführt werden. Ein Workflow könnte dabei beispielhaft wie folgt aussehen:

Für die Verwendung des Plugins muss dieses in einem Arbeitsschritt ausgewählt sein:

Überblick und Funktionsweise

Dieses Plugin wird innerhalb des Workflows automatisch als Export-Plugin ausgeführt und erzeugt innerhalb eines konfigurierten Verzeichnisses die jeweils benötigten Daten. Dabei handelt es sich je nach Publikationstyp um:

• Bilddateien

• Plaintext-Dateien mit OCR-Ergebnissen

• ALTO-Dateien mit OCR-Ergebnissen

• METS-Dateien

• METS-Anchor-Dateien

• XML-Export-Dateien

Insbesondere der Aufbau der XML-Export-Dateien ist je nach Publikationstyp sehr unterschiedlich. Hier einmal ein Beispiel für ein Generic Print-Publikationstyp:

Konfiguration

Die Konfiguration des Plugins erfolgt in der Datei plugin_intranda_export_adm_bsme.xml wie hier aufgezeigt:

Die darin verwendeten Parameter werden hier detailliert:

Für eine einfachere Inbetriebnahme befindet sich in install-Ordner des Plugins einn Verzeichnis mit den zwei passende Regelsätze als Referenz, die zu der hier aufgeführte Konfigurationsdatei passen.

Übersicht

Einführung

Die vorliegende Dokumentation beschreibt die Installation, die Konfiguration und den Einsatz des Fedora Export Plugins in Goobi workflow.

Installation

Das Plugin muss in den folgenden Ordner installiert werden:

Daneben gibt es eine Konfigurationsdatei, die an folgender Stelle liegen muss:

Überblick und Funktionsweise

Es muss ein Export Schritt konfiguriert werden:

• Export DMS

• Automatische Aufgabe

• Plugin für Arbeitsschritt: FedoraExport

Bei der Ausführung des Schrittes wird ein Export des Goobi Vorgangs (analog zum Export ins Dateisystem) in das konfigurierte Fedora Repository unter Berücksichtigung der Konfiguration (siehe oben) eingespielt.

Die Daten des Vorgangs lassen sich anschließend über das folgende URL-Muster im Repository abrufen:

Beispiele für die URLs nach erfolgreichem Ingest nach Fedora

URL des Datensatzes

URL für die METS-Datei

URL für die Master-Bilder

URL für die Derivate der Bilder

Konfiguration

Die Konfiguration erfolgt über die Konfigurationsdatei intranda_export_fedora.xml und kann im laufenden Betrieb angepasst werden.

Übersicht

Einführung

Das Plugin dient zur Erstellung der METS Struktur für den Import in das Zeitungsportal der Deutschen Digitalen Bibliothek. Dabei wird für die Gesamtaufnahme einer Zeitung eine METS-Anchor Datei erzeugt, für jeden exportierten Jahrgang wird eine weitere METS-Anchor Datei erzeugt und innerhalb der Gesamtaufnahme verlinkt. Der Jahrgang enthält weitere Strukturen für Monat und Tag.

Jede Ausgabe wird als einzelne METS Dateien erstellt und in der METS-Anchor Datei des Jahrgangs verlinkt. Die Ausgabe kann weitere Strukturdaten wie Artikelbeschreibungen oder Beilagen enthalten. Hier wird auch auf die digitalisierten Bilder verwiesen.

Installation

Das Plugin besteht aus der folgenden Datei:

Diese Datei muss in dem richtigen Verzeichnis installiert werden, so dass diese nach der Installation an folgendem Pfad vorliegt:

Daneben gibt es eine Konfigurationsdatei, die an folgender Stelle liegen muss:

Überblick und Funktionsweise

Zur Inbetriebnahme des Plugins muss dieses für eine Aufgabe im Workflow aktiviert werden. Dies erfolgt wie im folgenden Screenshot aufgezeigt durch Auswahl des Plugins intranda_export_newspaper aus der Liste der installierten Plugins.

Da dieses Plugin üblicherweise automatisch ausgeführt werden soll, sollte der Arbeitsschritt im Workflow als automatisch konfiguriert werden. Darüber hinaus muss die Aufgabe als Export-Schritt markiert sein.

Daneben muss es noch einen weiteren, regulären Export Schritt geben, damit die verlinkten Bilder und ALTO Dateien über die Schnittstellen des Goobi viewers ausgeliefert werden können.

Nachdem das Plugin vollständig installiert und eingerichtet wurde, wird es üblicherweise automatisch innerhalb des Workflows ausgeführt, so dass keine manuelle Interaktion mit dem Nutzer erfolgt. Stattdessen erfolgt der Aufruf des Plugins durch den Workflow im Hintergrund und führt die folgenden Arbeiten durch:

Für jede Ausgabe wird eine eigene METS Datei erstellt, die zur Ausgabe gehörenden Bilder und OCR Daten verlinkt. Die Ausgabe kann weitere Unterelemente wie Artikel oder Beilagen haben.

Die einzelnen Ausgaben werden dann in einer METS Datei für den Jahrgang zusammengefasst. Die METS Dateien der Ausgaben sind innerhalb einer Struktur für Monat und Tag verlinkt.

Als letztes wird geprüft, ob im Zielverzeichnis ein Datensatz mit den Metadaten der Gesamtaufnahme existiert. Wenn nicht, wird eine METS Datei erstellt, ansonsten wird der Jahrgang in die Strukturdaten der Gesamtaufnahme eingetragen.

Konfiguration

Die Konfiguration des Plugins erfolgt über die Konfigurationsdatei plugin_intranda_export_newspaper.xml und kann im laufenden Betrieb angepasst werden. Im folgenden ist eine beispielhafte Konfigurationsdatei aufgeführt:

Im ersten Bereich <export> werden einige globale Parameter gesetzt. Hier wird festgelegt, ob neben den Metsdateien auch Bilder exportiert werden sollen (<images> true/false), ob diese pro Ausgabe oder pro Jahrgang exportiert und in den Datensätzen verlinkt werden (<subfolderPerIssue> true/false), in welches Verzeichnis der Export durchgeführt werden soll (<exportFolder>) und welche Resolver für die METS Datei (<metsUrl>) und den Link auf den veröffentlichten Datensatz (<resolverUrl>) geschrieben werden sollen.

Im zweiten Bereich <metadata> werden eine Reihe von Metadaten definiert. Diese Felder müssen im Regelsatz existieren und werden zum Teil während des Exports von der Gesamtaufnahme in die einzelnen Ausgaben kopiert.

Der dritte Bereich <docstruct> definiert einige zu erzeugende Strukturelemente. Diese müssen ebenfalls im Regelsatz konfiguriert sein.

Übersicht

Einführung

Die vorliegende Dokumentation beschreibt die Installation, die Konfiguration und den Einsatz des Fedora Export Plugins in Goobi workflow.

Überblick und Funktionsweise

Es muss ein Export Schritt konfiguriert werden:

• Export DMS

• Automatische Aufgabe

• Plugin für Arbeitsschritt: FedoraExport

Bei der Ausführung des Schrittes wird ein Export des Goobi Vorgangs (analog zum Export ins Dateisystem) in das konfigurierte Fedora Repository unter Berücksichtigung der Konfiguration (siehe oben) eingespielt.

Es werden für die Bildung der Container-URLs bzw. von zusätzlichen Container-Attributen folgende Vorgangseigenschaften hinzugezogen (und sind unter Umständen zwingend erforderlich):

• barcode (enthält einen 10-stelligen Barcode oder eine 36-stellige PID)

• unit_Item_code (nur bei Barcodes)

• full_partial

Die Daten des Vorgangs lassen sich anschließend über das folgende URL-Muster im Repository abrufen:

Beispiele für die URLs nach erfolgreichem Ingest nach Fedora

Beispiel mit Barcode (barcode=“barcode123”):

Hauptcontainer für die Bilder

Container für die Master-Bilder

Container für die JP2-Derivate

Beispiel mit PID (barcode=“DB0027DB-F83B-11E9-AE98-A392051B17E6”):

Hauptcontainer für die Bilder

Container für die Master-Bilder

Container für die JP2-Derivate

Konfiguration

Die Konfiguration erfolgt über die Konfigurationsdatei intranda_export_fedora.xml und kann im laufenden Betrieb angepasst werden.

Der Block <config> ist wiederholbar und kann so in unterschiedlichen Projekten verschiedene Metadaten definieren. Die Unterelemente <workflow> wird zur Prüfung genutzt, ob der vorliegende Block für den aktuellen Schritt genutzt werden soll. Dabei wird geprüft, ob es einen Eintrag gibt, der sowohl den Workflow-Namen enthält. Ist dies nicht der Fall, wird der Block mit <workflow>*</workflow> verwendet.

Übersicht

Einführung

Die vorliegende Dokumentation beschreibt die Installation, Konfiguration und den Einsatz des Heris-Export-Plugins in Goobi.

Mithilfe dieses Plugins für Goobi workflow können die in einem vorherigen Arbeitsschritt ausgewählten Bilder und dazugehörige Metadaten in eine JSON-Datei exportiert werden. Der Export erfolgt anschließend via SFTP auf einen externen Server.

Installation

Um den Heris Export nutzen zu können, müssen folgende Dateien installiert werden:

Im Workflow muss ein automatischer Schritt eingefügt werden, bei dem das Plugin intranda_export_heris ausgewählt wurde. Dieser Schritt muss nach dem Arbeitsschritt mit dem Plugin Image Selection ausgeführt werden, in dem die Auswahl der zu exportierenden Bilder erfolgt.

Überblick und Funktionsweise

Wenn das Plugin ausgeführt wird, prüft es als erstes, ob in dem Arbeitsschritt mit dem Plugin Image Selection mindestens ein Bild ausgewählt wurde. Wenn dies der Fall ist, werden die folgenden Arbeiten durchgeführt:

• Kopieren der ausgewählten Bilder in einen temporären Ordner

• Prüfung, ob es bereits einen älteren Export für die aktuelle HERIS ID gibt

  • Falls ja, Erstellung eines Backups der alten JSON Datei, Download der alten JSON Datei

  • Prüfung, ob die ausgewählten Dateien den Bildnamen in der alten JSON Datei entsprechen

    • für jedes gleich bleibende Bild wird der alte Bild-Identifier ermittelt, um im neuen JSON wiederverwendet zu werden

    • jedes schon exportierte Bild, das im neuen Export nicht mehr vorhanden ist, wird remote gelöscht

    • jedes neue Bild, das im alten Export noch nicht existierte, wird wie ein komplett neuer Export behandelt

• Ermittlung der Metadaten für die ausgewählten Bilder

• Erstellung der JSON-Datei aus den ermittelten Metadaten, gegebenfalls unter Beibehaltung der alten Bild-IDs

• Kopieren der erzeugten Daten an das Ziel

• Löschen der temporären Daten

Konfiguration

Die Konfiguration erfolgt in der Datei plugin_intranda_export_heris.xml wie hier aufgezeigt:

Dabei ist der Bereich <config> wiederholbar und erlaubt so unterschiedliche Exporte für verschiedene Projekte oder Schritte.

Im Feld <propertyName> wird definiert, in welcher Eigenschaft die ausgewählten Bilder gespeichert sind. Dieser Wert muss mit der Konfiguration des Plugins Image Selection übereinstimmen.

Anschließend wird die JSON-Datei beschrieben. Das Feld <herisId> enthält das Metadatum, in dem die HERIS-ID gespeichert wird und im <jsonRootElement> wird der Name des JSON-Objects konfiguriert, in dem die einzelnen Bilder beschrieben werden.

Die einzelnen Felder der Bild-Objekte werden in der <field> Liste beschrieben. Jedes Feld verfügt über drei Angaben.

• Im Attribut name wird definiert, wie das Element innerhalb der JSON Datei heißen soll.

• Im Element selbst wird der Wert beschrieben.

• Mittels type wird angegeben, um was für einen Typen es sich handelt. Je nach Typ wird der Wert anders interpretiert.

Dabei sind folgende Angaben möglich:

• static: Der Wert wird unverändert als Text in das JSON geschrieben.

• filename: Hier wird der Bildname gespeichert.

• representative: Kann die Werte true/false enthalten. Das erste Bild der Liste wird als Repräsentant genutzt.

• identifier: Enthält den Identifier des Bildes aus der HERIS-Datenbank. Bei einem Re-Export wird der vorherige Identfier wiederverwendet. Bei neuen Exporten bleibt das Feld leer.

• metadata: Der Wert wird als Metadatum interpretiert und aus den Metadaten ermittelt. Das Metadatum wird zuerst im Unterelement Foto gesucht, dass dem Bild zugewiesen wurde. Wenn das nicht existiert, wird das Metadatum im Hauptelement Dokument erwartet.

Im letzten Block wird die SFTP Verbindung konfiguriert. Hier stehen Optionen für die Authentifizierung mittels Nutzername und Passwort, Nutzername und Key oder Nutzername und passwortgeschützten Key zur Verfügung.

Übersicht

Einführung

Die vorliegende Dokumentation beschreibt die Installation, Konfiguration und den Einsatz eines Export-Plugins in Goobi.

Mithilfe dieses Export-Plugins für Goobi können die Goobi-Vorgänge innerhalb eines Arbeitsschrittes gleichzeitig an mehrere Orte exportiert werden.

Installation

Dieses Plugin wird in den Workflow so integriert, dass es automatisch ausgeführt wird. Eine manuelle Interaktion mit dem Plugin ist nicht notwendig. Zur Verwendung innerhalb eines Arbeitsschrittes des Workflows sollte es wie im nachfolgenden Screenshot konfiguriert werden.

Das Plugin muss zunächst in folgendes Verzeichnis kopiert werden:

Daneben gibt es eine Konfigurationsdatei, die an folgender Stelle liegen muss:

Konfiguration

Die Konfiguration des Plugins erfolgt über die Konfigurationsdatei plugin_intranda_export_configurable-base.jar und über die Projekteinstellungen. Die Konfiguration kann im laufenden Betrieb angepasst werden. Im folgenden ist eine beispielhafte Konfigurationsdatei aufgeführt:

Der config-Block

Der Block <config> ist wiederholbar und kann so in unterschiedlichen Projekten verschiedene Metadaten definieren. Der Block mit <project>*</project> wird angewendet, wenn kein Block mit der Projektbezeichnung des Projektes existiert.

Der includeFolders-Block

Der includeFolders Block befindet sich innerhalb von jedem config-Element. Er steuert, welche Verzeichnisse für den Export berücksichtigt werden sollen.

Wird das jeweilige Attribut enabled als false konfiguriert wird, findet kein Export des entsprechenden Ordners statt.

Die Konfiguration des Zielordners kann innerhalb der Projekteinstellungen in der Nutzeroberfläche von Goobi workflow vorgenommen werden. Wenn dort die Checkbox für Erzeuge Vorgangsverzeichnis gesetzt ist, wird der Vorgang in einen Unterordner mit seinem Titel als Namen im Zielverzeichnis abgelegt.