Goobi verfügt seit der Version 1.9.2 über die Möglichkeit vollautomatische Arbeiten in Form von Plugins innerhalb des Workflows auszuführen.
Ein solches vollautomatisches Arbeitsschritt-Plugin ist das Löschen von nicht mehr benötigten Images. Dieses ImageDeletion-Plugin sollte innerhalb des Workflows der letzte Arbeitsschritt sein. Für die Konfiguration des Arbeitsschritts muss hierbei beachtet werden, dass es sich um eine Automatische Aufgabe handeln muss und als Schritteplugin der Identifier intranda_step_imageDeletion definiert wird.
Innerhalb des Workflows wird somit das konfigurierte Schritteplugin automatisch aufgerufen. Dabei arbeitet dieses folgendermaßen:
Zunächst startet das Plugin eine Validierung des generierten JP2-Derivats. Anschließend erfolgt eine Prüfung auf Vorhandensein und Validität einer AMD-Ergebnisdatei von SDB, innerhalb der zumindest ein Objekt beschrieben ist. Die darauffolgende letzte Validierung stellt sicher, dass die Anzahl der Objekte innerhalb der Verzeichnisse master und media sowie die Anzahl der beschriebenen Objekte innerhalb der AMD-Datei identisch ist.
Erst nach erfolgreichem Abschluss der vorhergehenden Validierungen erfolgt abschließend der Löschvorgang. Dabei werden die Verzeichnisse master und media gelöscht.
Für den Fall, dass die vorhergegangenen Valdierungen fehlschlagen, bleibt der Arbeitsschritt offen stehen und verhindert das automatische Löschen, so dass ein manueller Eingriff erfolgen muss, um zunächst die Validität sicherzustellen, bevor eine Löschung von Daten aus dem entsprechenden Vorgang erfolgen kann.
In den meisten Fällen wird ein automatischer Schritt mit einem Skript-Schritt kombiniert. Goobi reagiert dann auf die Ausgabe des Skriptes. Wenn Meldungen auf der Standard-Ausgabekonsole ausgegeben werden, werden diese von Goobi als reine Statusmeldungen gewertet und führt die Arbeiten weiter fort. Werden von den Skripten hingegen Fehlermeldungen auf der Fehler-Ausgabekonsole ausgegeben, erkennt Goobi dieses als Fehler und unterbricht die weitere Verarbeitung des Workflows.
Ein Beispiel für die Kombination eines automatischen Workflowschritts mit einem Skript-Schritt ist die Konvertierung von Bildern zu TIFF/JPEG. Goobi ruft automatisch ein Skript auf und konvertiert die Bilder in dem angegeben Ordner in das Format TIFF/JPEG:
In dem folgenden Beispiel wird das Skript des intranda image improvers aufgerufen:
Ihm werden zwei Parameter übergeben. Der eine Parameter convert_images ist im Skript selbst definiert. Der Parameter {tifpath} wird von Goobi dynamisch mit dem Pfad zu dem Ordner ersetzt, innerhalb dessen sich das Imageset befindet.
Parameter können mit Anführungszeichen (") zusammengefasst werden, damit sie als ein Argument an den aufgerufenen Prozess durchgereicht werden. Wenn ein Anführungszeichen als Argument direkt an den neuen Prozess durchgereicht werden soll, muss es mit einem vorangeführten zweiten Anführungszeichen (dann also: "") escaped werden.
Goobi bietet die Möglichkeit Workflowschritte als automatisch zu kennzeichnen. Diese Schritte werden automatisch geöffnet und ausgeführt, wenn der jeweils vorherige Schritt innerhalb des Workflows erfolgreich abgeschlossen wurde. Sobald im automatischen Workflowschritt ein Fehler auftritt, bleibt dieser Arbeitsschritt stehen und wird nicht weiter bearbeitet.
Um einen Workflowschritt als automatisch zu kennzeichnen, muss die Checkbox Automatische Aufgabe aktiviert sein. Diese befindet sich in den Aufgabendetails für eine Aufgabe, wie in der nachfolgenden Abbildung ersichtlich:
Goobi exportiert automatisch die METS-Dateien in einen definierten Ordner. Dies ist zumeist das folgende Verzeichnis:
In diesem Verzeichnis wird für jeden Vorgang ein Unterordner erzeugt. Innerhalb dieses erzeugten Ordners werden nun alle zu exportierenden Daten kopiert. Das beinhaltet neben der eigentlichen METS-Datei unter Umständen ebenso die Anchor-Datei, die Bilder sowie OCR Daten.
Nachdem der Export erfolgreich durchgeführt wurde, wird ein Programm namens PostExport.jar aufgerufen. Dieses Programm greift auf die exportierte METS Datei zu, benennt diese um, so dass der Dateiname der b-Nummer entspricht und merged diese mit der SDB-AMD Datei.
Im ersten Schritt wird dabei die AMD-Datei eingelesen und für jedes File-Element ein Element mets:techMD innerhalb der Sektion mets:amdSec der METS Datei angelegt. Im zweiten Schritt werden die FileGroups durchlaufen und Dateiname, Checksum und Mimetype aus den Werten der AMD Datei gebildet. Als letztes werden die Strukturelemente der physischen structMap mit den einzelnen techMD verbunden.
Anschließend wird die so angereicherte METS Datei an den definierten Ordner geschrieben, von dem aus die Präsentation die Daten einlesen kann.
Für den Fall, dass es sich bei den Daten um multiple manifestation objects handelt, bei denen bereits eine oder mehrere manifestations exportiert wurden, werden nun noch die anchor-Dateien gemerged. Hierbei wird ein neues Child-Element in die logische structMap eingetragen, das die Informationen des neuen Objekts enthält. Die Reihenfolge innerhalb der structMap wird durch das Metadatum order number definiert.
