This documentation describes how to install, configure and use the Administration plugin to automatically repeat a catalog query to update records in Goobi workflow.
GPL 2.0 or newer
Goobi workflow 3.0.4 and newer
The plugin consists of the following files to install:
These files must be installed in the correct directories so that they are available in the following paths after the installation:
There is also a configuration file, which must be located at the following location:
The plugin is configured via the configuration file
plugin_intranda_administration_catalogue_poller.xml and can be adapted during operation. The following is an example configuration file:
plugin_intranda_administration_catalogue_poller.xml<?xml version="1.0" encoding="UTF-8"?><config_plugin><!-- multiple different rules can be defined for individual use cases --><rule title="SampleProject"><!-- filter which items to run through (can be more then one, otherwise use *)please notice that blanks inside of the filter query need to be surrounded by quotation marks --><filter>project:SampleProject</filter><filter>"project:Manuscript items"</filter><!-- which catalogue to use (GBV, Wiener, CBL Adlib ...) --><catalogue>Wiener</catalogue><!-- which identifier to use for the catalogue request (usestandard variable replacer compatible value here) --><catalogueIdentifier>$(meta.CatalogIDDigital)</catalogueIdentifier><!-- define if existing structure subelements shall be kept (true),otherwise a complete new mets file is created and overwrites theexisting one (false) --><mergeRecords>true</mergeRecords><!-- execute an automatic export of updated records;this is only executed if mergeRecords is set to true --><exportUpdatedRecords>false</exportUpdatedRecords><!-- if records shall be merged: which existing fields shall notbe replace with new values? (use the metadatatypes from ruleset)--><skipField>viewerinstance</skipField><skipField>singleDigCollection</skipField><skipField>pathimagefiles</skipField></rule><!-- internal timestamp for the plugin to know when it was last executed --><lastRun>1551731078691</lastRun></config_plugin>
At this point, an internal name is specified, which is mainly used for the user interface to distinguish between the different rules
The filter can be used to define one or more Goobi projects for which the rules defined here apply. With
Here you can define which catalog is to be used for querying new data. This is the name of a catalog as it was defined within the global Goobi catalog configuration within
Definition of the metadata from the METS file to be used for the catalog query. Usually this is the same identifier that was used for the first catalog query and is usually stored within the metadata
If this value is set to
If the value
If the value is set to
Several metadata fields can be defined here, which should not be changed by a catalog query. This is particularly useful for those fields that do not come from a catalog query and were therefore previously entered in addition to the catalog data. Typical examples for such fields are
The Catalogue Poller Plugin is automatically activated by Goobi. Its runtime starts at 22:00 and repeats itself every 24 hours.
If, in addition to this automatic process, a user also wants access to the plugin's user interface, he or she must belong to a user group that has been granted the following plugin-specific right to do so:
In order to assign this right, the desired user group must first be assigned the right authorization in the right-hand area.
If the authorization for the user group is re-entered, the user must first log into Goobi again in order to be able to use this authorization level. The user can then click on the Catalogue Poller plugin in the Administration menu and manually trigger an update of the records at any time.
If the plugin finds updated metadata for a process and therefore updates the METS file, a backup of the current METS file
meta.xml and, if relevant, the
meta_anchor.xml is created automatically. The backup is saved next to the updated METS file.
The updates of the metadata by the plugin usually take place fully automatically in the background. In order to be able to track what happened to a data record at any time, the events are logged. Detailed entries are automatically added to the process log for each process for which there were changes from this plugin. In addition to the timestamp, these entries also contain an exact list of the changed metadata fields and their contents. Thus, it is possible to trace the previous or the new value at any time.