The configuration file goobi_digitalCollections.xml is responsible for controlling the selection list of digital collections. It is usually located at the following path in the file system:

/opt/digiverso/goobi/config/goobi_digitalCollections.xml

In this configuration file you define which collections basically exist and within which projects they should be available for selection.

<?xml version="1.0" encoding="UTF-8"?>
<DigitalCollections>
	<default>
		<DigitalCollection>General</DigitalCollection>
		<DigitalCollection>Biology</DigitalCollection>
		<DigitalCollection>Physics</DigitalCollection>
		<DigitalCollection>Mathematics</DigitalCollection>
	</default>
</DigitalCollections>

If collections are to be configured with sub collections, these are separated from each other by the # separator. This looks like the following example:

<?xml version="1.0" encoding="UTF-8"?>
<DigitalCollections>
	<default>
		<DigitalCollection>General</DigitalCollection>
		<DigitalCollection>Biology</DigitalCollection>
		<DigitalCollection>Biology#Animals</DigitalCollection>
		<DigitalCollection>Biology#Plants</DigitalCollection>
	</default>
</DigitalCollections>

If the collections are to be configured differently depending on the project, this can be done as follows:

<?xml version="1.0" encoding="UTF-8"?>
<DigitalCollections>
  <default>
    <DigitalCollection>General</DigitalCollection>
  </default>
  <project>
    <name>Archive Project</name>
    <DigitalCollection>Monographs</DigitalCollection>
    <DigitalCollection>Files</DigitalCollection>
    <DigitalCollection>Maps</DigitalCollection>
  </project>
  <project>
    <name>Newspapers</name>
    <DigitalCollection>1920 - 1930</DigitalCollection>
    <DigitalCollection>1930 - 1940</DigitalCollection>
    <DigitalCollection>1940 - 1950</DigitalCollection>
  </project>
</DigitalCollections>

In the configuration file goobi_normdata.xml links to databases are specified, which can be used for universal purposes. A main application is to obtain metadata to digitized objects. The file is usually located at the following location:

/opt/digiverso/goobi/config/goobi_normdata.xml

For example, this configuration file looks as follows:

<?xml version="1.0" encoding="UTF-8"?>
<normdatabases>
    <normdatabase name="goobi" url="https://goobi.intranda.com/" abbreviation="" />
    <normdatabase name="kulturnav" url="https://kulturnav.org/" abbreviation="kulturnav" />
    <normdatabase name="GND" url="http://d-nb.info/gnd/" abbreviation="gnd" />
    <normdatabase name="geonames" url="http://www.geonames.org/" abbreviation="geonames" />
    <normdatabase name="dante" url="https://dante.gbv.de/" abbreviation="dante" />
    <normdatabase name="viaf" url="http://www.viaf.org/viaf/" abbreviation="viaf" />
    <normdatabase name="easydb" url="https://easydb.prizepapers.gbv.de/" abbreviation="easydb" />
<!--
    <normdatabase name="REFGEO" url="http://normdata.intranda.com/normdata/refgeo/" abbreviation="intranda Geo Datenbank" />
    <normdatabase name="REFBIO" url="http://normdata.intranda.com/normdata/refbio/" abbreviation="intranda PND" />
    <normdatabase name="RVK" url="http://rvk.uni-regensburg.de/index.php?option=com_rvko&amp;view=show&amp;mode=searchNotation&amp;rvkoNotationKey=" abbreviation="rvk" />
-->
</normdatabases>

The file goobi_normdata.xml contains a simple list of norm databases that can be used in Goobi, for example also by plugins. For each registered database there is a <normdatabase> element, which contains the further information.

The parameter url specifies the URL of the database. This should point to an API that can be queried by Goobi. Depending on the usage or plugin, the start page of the database can also be specified here, where a user can query object data in the browser.

The abbreviation parameter is used to specify an abbreviation that uniquely identifies this database. The abbreviation can be used, for example, for configurations and file imports and exports.

The additional name parameter is not currently used by Goobi Workflow. It is used for completeness in the configuration file and contains the full, human readable, name of the database. Alternatively, a common abbreviation can be specified here. This parameter can also be used by plugins when they read the file themselves.

The goobi_activemq.xml configuration file specifies the settings for the org.apache.activemq Java library used by Goobi Workflow.

Goobi Workflow does not use the file itself, but passes it directly to the library as configuration. This documentation only presents the most important settings that are relevant for Goobi. More detailed documentation can be found on the activemq website.

The file is usually located at the following location:

/opt/digiverso/goobi/config/goobi_activemq.xml

For example, this configuration file looks as follows:

<beans
    xmlns="http://www.springframework.org/schema/beans"
    xmlns:amq="http://activemq.apache.org/schema/core"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
    http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd">
    <broker xmlns="http://activemq.apache.org/schema/core" brokerName="localhost" schedulerSupport="true" schedulerDirectory="/opt/digiverso/goobi/activemq/scheduler">
        <transportConnectors>
            <transportConnector name="stomp" uri="stomp://localhost:61613" />
            <transportConnector name="tcp" uri="tcp://localhost:61616" />
        </transportConnectors>
        <persistenceAdapter>
            <kahaDB directory="/opt/digiverso/goobi/activemq/messages" journalMaxFileLength="32mb" />
        </persistenceAdapter>
        <systemUsage>
            <systemUsage>
                <memoryUsage>
                    <memoryUsage limit="64 mb"/>
                </memoryUsage>
                <storeUsage>
                    <storeUsage limit="512 mb"/>
                </storeUsage>
                <tempUsage>
                    <tempUsage limit="128 mb"/>
                </tempUsage>
            </systemUsage>
        </systemUsage>
        <managementContext>
            <managementContext createConnector="false"/>
        </managementContext>
        <plugins>
            <redeliveryPlugin fallbackToDeadLetter="true"
                sendToDlqIfMaxRetriesExceeded="true">
                <redeliveryPolicyMap>
                    <redeliveryPolicyMap>
                        <redeliveryPolicyEntries>
                            <redeliveryPolicy queue="goobi_fast"
                                maximumRedeliveries="5"
                                initialRedeliveryDelay="10000"
                                backOffMultiplier="1.5"
                                useExponentialBackOff="true"/>
                        </redeliveryPolicyEntries>
                        <defaultEntry>
                            <!-- the fallback policy for all other destinations -->
                            <redeliveryPolicy maximumRedeliveries="10"
                                initialRedeliveryDelay="300000"
                                backOffMultiplier="1.5"
                                useExponentialBackOff="true"/>
                        </defaultEntry>
                    </redeliveryPolicyMap>
                </redeliveryPolicyMap>
            </redeliveryPlugin>
            <simpleAuthenticationPlugin>
                <users>
                    <authenticationUser username="goobi" password="goobi"
                        groups="admins,publishers,consumers"/>
                    <authenticationUser username="worker" password="worker"
                        groups="consumers"/>
                </users>
            </simpleAuthenticationPlugin>
            <authorizationPlugin>
                <map>
                    <authorizationMap>
                        <authorizationEntries>
                            <authorizationEntry topic=">" read="admins" write="admins" admin="admins" />
                            <authorizationEntry queue=">" read="admins" write="admins" admin="admins" />
                            <authorizationEntry queue="goobi_fast" read="consumers" write="publishers" admin="publishers" />
                            <authorizationEntry queue="goobi_slow" read="consumers" write="publishers" admin="publishers" />
                            <authorizationEntry queue="goobi_status" read="admins" write="consumers" />
                        </authorizationEntries>
                    </authorizationMap>
                </map>
            </authorizationPlugin>
        </plugins>
    </broker>
</beans>

XML namespaces used

This configuration file can use multiple XML namespaces in more complex applications.

The root element <beans> always uses this default namespace:

xmlns="http://www.springframework.org/schema/beans"

The <broker> sub-element always uses this default namespace:

xmlns="http://activemq.apache.org/schema/core"

Settings for the Message Broker

All settings that are important for using the Message Broker of Goobi Workflow are made inside the <broker> element.

The brokerName parameter is used to specify the name of the message broker. Since this is the only one on localhost (on this computer system), the name defaults to localhost.

The schedulerSupport parameter specifies whether a scheduler is used for multithreading.

The schedulerDirectory parameter specifies a full file path to an executable scheduler.

Enabling URIs with specific protocol

The <transportConnectors> element is used to specify a list of enabled endpoints along with the protocols that can be used. Each <transportConnector> element contained in it specifies an endpoint.

An endpoint usually has two parameters. The name parameter specifies a name for the enablement. For example, this can be the name of the protocol. The uri parameter specifies a Uniform Resource Identifier consisting of a protocol, an IP address or domain, a port number, a path and any parameters. From the URL specified here, activemq can later be accessed using the specified port and protocol.

Database used

It can happen that transmitted information is not directly accepted by the receiver. If this information is not requested for a long enough time, activemq stores it in its own database. This is configured with the <persistenceAdapter> element.

By default kahaDB is used, so the configuration includes an element <kahaDB> with the parameter directory, specifying the full file path to the database.

Additionally, the journalMaxFileLength parameter can be specified to limit the file size in the database. One of the units mb or gb will be used.

Memory limit

The <systemUsage> element can be used to limit the available memory for the transferred data in the queue.

The <memoryUsage> element defines the maximum size of used memory.

The <storeUsage> element defines the maximum size of the internal database.

The <tempUsage> element defines the maximum size of temporary files.

The most common units for the limit parameter are mb and gb.

Custom connection for JMX

The <managementContext> element is usually used to turn off a custom connection for JMX (Java Management Extensions). The createConnector parameter is set to false by default to use the default connection.

Plugins

This configuration of the Message Broker by default comes with three plugins that handle authentication and the redelivery system.

Plugin for user groups

The <authenticationPlugin> is used to define user groups and their access rights to different queues.

With each <authorizationEntry> a queue and its details are specified. The queue parameter specifies the used queue. The topic parameter can be used to configure access to specific topics instead of read and write permissions for a queue.

Instead of a name, the value > can be set for a queue or topic. This is a universal operator and applies to all queues and topics.

The read, write and admin parameters specify user groups that have read, write and administrator access to the respective queue or topic respectively. Multiple user groups in one parameter can be separated with comma.

Plugin for users and passwords

The <simpleAuthenticationPlugin> is used to create users and define passwords and user groups for users. Each <authenticationUser> element specifies an authenticatable user. The username and password parameters define the username and the necessary password with which the user (or other software) must authenticate.

In addition, there is the groups parameter, which contains a comma-separated list of user groups to which the respective user belongs. These groups are relevant for the <authorizationPlugin>.

Plugin for error handling

The <redeliveryPlugin> is used to configure more detailed error handling for resending data that was transmitted with errors. This plugin has two boolean parameters that control the final save of multiple failed transmission attempts and their contents.

With the fallbackToDeadLetter parameter, messages are not retransmitted after a certain number of failed transmission attempts to keep the system load low.

With the parameter sendToDlqIfMaxRetriesExceeded a message that could not be sent several times is written to a residual memory. There it remains until it can be read manually or by a later successful transmission attempt. This prevents the queuing system from being overloaded with non-functional connections.

The sub-element <redeliveryPolicyEntries> lists error handling rules that should apply to specific queues. For each rule entered there, the element <redeliveryPolicy> and the parameter queue define the corresponding queue.

In the element <defaultEntry> the default case is defined, which will be executed if none of the above rules apply. This element <redeliveryPolicy> defines exactly one rule, but this one does not need a queue parameter, because it is used for all queues in all usual cases.

Some more parameters can be specified for the rules. For example, with the integer maximumRedeliveries parameter it is possible to specify the maximum number of attempts before a message is written to the residual memory. The initialRedeliveryDelay parameter, also an integer, is used to specify the number of milliseconds after which a new transmission attempt is started.

To avoid a permanent load on the system, the time interval between retransmission attempts can be increased exponentially each time. For this the boolean parameter useExponentialBackOff is set to true and with the parameter backOffMultiplier a multiplication factor is specified, with which the period is increased. For example, if this is set to 1.5 and the initial period is set to 60 seconds, the next send attempt will be executed after 1.5 * 60 = 90 seconds. The third follows after another 1.5 * 90 = 135 seconds.

The goobi_metadataDisplayRules.xml configuration file specifies how the metadata is to be displayed within Goobi's metadata editor. It is usually located at the following path in the file system.

/opt/digiverso/goobi/config/goobi_metadataDisplayRules.xml

This configuration file describes how individual metadata fields are to be displayed. Among other things, it can be specified that fields are displayed as input fields, selection lists, read-only fields, etc., and can be edited differently by the user. Here is an example of such a configuration file:

<?xml version="1.0" encoding="UTF-8"?>
<displayRules>
    <ruleSet>
        <context projectName="*">
            
            <!-- text field -->
            <textarea ref="TitleDocMain">
                <label></label>
            </textarea> 
             <input ref="CatalogIDSource">
                <label></label>
            </input> 
            
            <!-- text area -->
            <textarea ref="TitleDocMainShort">
                <label></label>
            </textarea> 
            <textarea ref="Description">
                <label></label>
            </textarea> 
            
            <!-- default value -->
            <input ref="PlaceOfPublication">
                <label>Göttingen</label>
            </input> 
            
            <!-- read only -->
            <readonly ref="CatalogIDDigital">
                <label></label>
            </readonly>
            
            <!-- Single select -->
            <select1 ref="singleDigCollection">
                <item selected="true">
                    <label>General</label>
                    <value>General</value>
                </item>

                <item selected="false">
                    <label>Biology</label>
                    <value>Biology</value>
                </item>

                <item selected="false">
                    <label>Physics</label>
                    <value>Physics</value>
                </item>

                <item selected="false">
                    <label>Mathematics</label>
                    <value>Mathematics</value>
                </item>
            </select1>
            
            <!-- Multi select  -->
            <select ref="Classification">
                <item selected="true">
                    <label>Blue</label>
                    <value>Blue</value>
                </item>

                <item selected="false">
                    <label>Red</label>
                    <value>Red</value>
                </item>

                <item selected="false">
                    <label>Green</label>
                    <value>Green 2</value>
                </item>

                <item selected="false">
                    <label>Yellow</label>
                    <value>Yellow</value>
                </item>
            </select>

        </context>
    </ruleSet>
</displayRules>

In this configuration file, you can define within the projectName attribute for which projects this individually configured display is to apply.

The IDs specified with ref refer to the metadata names that exist in the database for the corresponding project (or task).

Most elements have a child elements label. This can contain text to describe the input field. Normally, this is the name of the concerning meta data, but it can be different for better readability.

In addition, different field types can be selected from a list:

Input Box

The input box is displayed as a normal single-line input field.

<input ref="PlaceOfPublication">
    <label>Göttingen</label>
</input>

Text Area

The type textarea is similar to the Input Box. However, it is multiline and allows the display size of the field to be adjusted.

<textarea ref="TitleDocMain">
    <label />
</textarea>

Read only Field

The type readonly is similar to the Input Box, but it does not allow changing the field content.

<readonly ref="CatalogIDDigital">
    <label />
</readonly>

Select Box

The select box select1 allows the selection of one value from a list of values. A distinction is made between the display of the value (label) and the actual value to be stored internally (value). With the selected parameter, one <item> element can be preselected.

<select1 ref="singleDigCollection">
    <item selected="true">
        <label>Default</label>
        <value>DefaultCollection</value>
    </item>
    <item selected="false">
        <label>Biology</label>
        <value>Biology</value>
    </item>
    <item selected="false">
        <label>Physics</label>
        <value>Physics</value>
    </item>
    <item selected="false">
        <label>Mathematics</label>
        <value>Mathematics</value>
    </item>
</select1>

Multi Select Box

The Multi Select Box select allows you to select multiple values, all of which should be stored within the metadata field. Here, too, a distinction is made between the displayed value (label) and the internally stored value (value). With the selected parameter, multiple <item> elements can be preselected.

<select ref="Classification">
    <item selected="true">
        <label>Default classification</label>
        <value>DefaultClassification</value>
    </item>
    <item selected="false">
        <label>Classification 1</label>
        <value>Classification 1</value>
    </item>
    <item selected="false">
        <label>Classification 2</label>
        <value>Classification 2</value>
    </item>
    <item selected="false">
        <label>Classification 3</label>
        <value>Classification 3</value>
    </item>
</select>

HTML Input

The htmlInput field type allows you to enter texts with optical formatting options. For example, text can be marked in bold or italic and is saved in the METS file along with the formatting.

<htmlInput ref="Description">
    <label></label>
</htmlInput>

GeoNames

The geonames type allows the search and selection of locations within the GeoNames database.

<!-- Geonames as selectable field, in ruleset the PlaceOfPublication has to have this attribute then: normdata="true" -->
<geonames ref="PlaceOfPublication">
    <label></label>
</geonames>

GND

The field type gnd allows the search and data transfer of entries from the Common Standards Database of the German National Library.

<gnd ref="Subject">
    <label />
</gnd>

Dante

The dante field type allows you to use the GBV's Dante vocabulary server. All provided vocabularies can be configured. A complete list of available vocabularies can be found at the following address within the notation element:

https://api.dante.gbv.de/voc

<dante ref="DocLanguage">
    <source>languages_gnd</source>
    <field>NORM_LABEL_de, NORM_LABEL_en, NORM_LABEL_fr, NORM_LABEL_es</field>
</dante>

VIAF

The viaf field type allows data to be transferred from the VIAF database across all integrated standards databases of different national libraries.

Sample for persons:

<viaf ref="Author">
    <source>100__a; 400__a; 700_a</source>
    <field>001=NORM_IDENTIFIER; 0247_a=URI; 1001_a=NORM_NAME; 1001_d=NORM_LIFEPERIOD; 1001_q=NORM_SEX; 375__a=NORM_SEX;  700__a=NORM_ALTNAME</field>
</viaf>

Sample for places:

<viaf ref="PlaceOfPublication">
    <!-- # Format: 'mmmiis' -->
    <!-- # mmm - MARC main field -->
    <!-- # ii - indicator 1 + 2 (_ if empty) -->
    <!-- # s - MARC subfield -->
    <source>210__a; 111__a; 100__a; 110__a; 150__a; 151__a;</source>

    <!-- # Format: 'mmmiis=label' -->
    <!-- # mmm - MARC main field -->
    <!-- # ii - indicator 1 + 2 (_ if empty) -->
    <!-- # s - MARC subfield -->
    <!-- # label - label of the field, can be used as message key -->
    <field>001=NORM_IDENTIFIER; 0247_a=URI;</field>
</viaf>

Vocabulary manager - List

The vocabularyList field type allows you to transfer data from a specific vocabulary in the vocabulary manager of Goobi workflow. The vocabulary to be used is specified within source.

<vocabularyList ref="singleDigCollection">
    <source>Digital collections</source>
</vocabularyList>

If not all values of the vocabulary should be listed, field can be used to define a restriction for one or more fields that should contain a certain value:

<vocabularyList ref="singleDigCollection">
    <source>Digital collections</source>
    <field>public=true;</field>
</vocabularyList>

Vocabulary manager - Dialog selection

If you want the content of a vocabulary from the Goobi vocabulary manager to be accessible via a search box, the type vocabularySearch is used. You can use field to define which fields of the data records are to be displayed.

<vocabularySearch ref="SubjectTopic">
    <source>Languages</source>
    <field>Name; Full Name; Description</field>
</vocabularySearch>

People

With the type person, a person can be selected. The person can be specified in more details with the elements <source> and <field>.

<person ref="Name">
    <source>Source</source>
    <field>Field</field>
</person>

Corporate

With the type corporate, a corporate can be selected. The corporate can be specified in more details with the elements <source> and <field>.

<corporate ref="Name">
    <source>Source</source>
    <field>Field</field>
</corporate>

Processes

With the type process, a process can be selected. The process can be specified in more details with the elements <source> and <field>.

<process ref="Title">
    <source>Source</source>
    <field>Field</field>
</process>

Kultur Nav

The type kulturnav allows data transfer from the Kulturnav database across all integrated standards databases of different national libraries. The person reference and the <source> element can be used to retrieve personal data, for example.

<kulturnav ref="person">
    <source>entityType:Person, entity.dataset:d519f76b-5ce5-4876-906e-7d31a76eb609</source>
</kulturnav>

Database easydb

With the type easydb, an easydb database can be specified to import information from.

The element easydb defines the desired metadata type, in the attribute ref the name of the metadata is configured to which the entry should apply. The element source contains the ID of the easydb instance in which the search should be performed. The value must correspond to an instance ID from the file plugin_metadata_easydb.xml. In field is the ID of the search to be used. The mapping is done using the ID element in the search section of the file in plugin_metadata_easydb.xml. This allows an individual search query to be configured for each metadata in its own easydb instance. However, the individual search queries can also be reused and entered in field for multiple metadata.

<easydb ref="MetadataName">
    <source>Prize Papers EasyDB</source>
    <field>JourneySearch</field>
</easydb>

Generation of metadata from other values

With the type generate, a rule for generating the field can be defined. This allows referencing the content of other metadata or Goobi variables.

The attribute ref configures the name of the metadata to which the entry should apply. If the rule should only apply to certain records, an optional XPath expression can be specified in <condition> that must be satisfied. Unlike other elements, this field is repeatable and thus allows configurations for a field with different conditions. When generation is executed, all entries are processed from top to bottom, and the first entry for which the condition is met or for which no condition is set is used.

The element <value> contains the text to be generated, and arbitrary placeholders in the form of [NAME] can be used.

The individual parameters are then defined within the <item> elements. Each element contains a <label> with the name of the placeholder to be replaced and a <type>. The type can either be xpath or variable. For xpath, the value is searched within the current structure element using an XPath expression, while for variable, data from the variable replacer of the current process can be used. Using <regularExpression> and <replacement>, the retrieved value can be further manipulated. If a value is found, the placeholder in the text will be replaced.

<generate ref="TitleDocMain">
    <condition>goobi:metadata[@name='genre'][text()='Letter']</condition>
    <value>Letter from [ACTOR_FROM] to [ACTOR_TO] at [PLACE], [DATE]</value>

    <item>
        <label>ACTOR_FROM</label>
        <type>xpath</type>
        <field>goobi:metadata[@type='person'][@name='Creator']/goobi:displayName</field>
        <regularExpression>(.+), (.+)</regularExpression>
        <replacement>$2 $1</replacement>
    </item>
    <item>
        <label>ACTOR_TO</label>
        <type>xpath</type>
        <field>goobi:metadata[@type='person'][@name='Receiver']/goobi:displayName</field>
        <regularExpression>(.+), (.+)</regularExpression>
        <replacement>$2 $1</replacement>
    </item>
    <item>
        <label>PLACE</label>
        <type>xpath</type>
        <field>goobi:metadata[@type='group'][@name='location_related_place'][goobi:metadata[@name='location_holdingExternal_relation_type'][text()='is bound from']]/goobi:metadata[@name='location_physicalLocation_related_place']</field>
    </item>
    <item>
        <label>DATE</label>
        <type>variable</type>
        <field>{meta.PublicationYear}</field>
        <regularExpression>([0-9]{4})-[0-9]{2}-[(0-9]{2}</regularExpression>
        <replacement>$1</replacement>
    </item>
</generate>

In the goobi_rest.xml configuration file, the REST API endpoints used by Goobi Workflow are shared based on the respective path (as part of the URL). For each endpoint, the allowed HTTP methods and various access restrictions can be defined.

The file is usually located here:

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

A sample configuration could look like this:

<?xml version='1.0' encoding='UTF-8'?>
<config>
    <endpoint path="/seterrorstep.*">
        <method name="post">
            <allow netmask="0:0:0:0:0:0:0:1/128" token="CHANGEME"/>
            <allow netmask="127.0.0.0/8" token="CHANGEME"/>
        </method>
    </endpoint>
    <endpoint path="/addtoprocesslog.*">
        <method name="post">
            <allow netmask="0:0:0:0:0:0:0:1/128" token="CHANGEME"/>
            <allow netmask="127.0.0.0/8" token="CHANGEME"/>
        </method>
    </endpoint>
    <endpoint path="/closestep.*">
        <method name="post">
            <allow netmask="0:0:0:0:0:0:0:1/128" token="CHANGEME"/>
            <allow netmask="127.0.0.0/8" token="CHANGEME"/>
        </method>
    </endpoint>
    <endpoint path="/process/check.*">
        <method name="get">
            <allow netmask="127.0.0.0/8" token="CHANGEME"/>
        </method>
    </endpoint>
    <endpoint path="/processes/search">
        <method name="get">
            <allow netmask="127.0.0.0/8" token="CHANGEME"/>
        </method>
        <method name="post">
            <allow netmask="127.0.0.0/8" token="CHANGEME"/>
        </method>
    </endpoint>
    <endpoint path="/vocabulary/.*">
        <cors>
            <method>GET</method>
            <origin>https://intranda.com</origin>               
        </cors>
        <method name="get">
            <allow />
        </method>
        <method name="post">
            <allow />
        </method>
    </endpoint>
    <endpoint path="/mails/disable/.*">
        <method name="get">
            <allow />
        </method>
    </endpoint>

    <!-- allow all commands just locally with the token 'test'
    <endpoint path=".*">
      <method name="post">
        <allow netmask="0:0:0:0:0:0:0:1/128" token="test"/>
        <allow netmask="127.0.0.0/8" token="test"/>
      </method>
      <method name="get">
        <allow netmask="0:0:0:0:0:0:0:1/128" token="test"/>
        <allow netmask="127.0.0.0/8" token="test"/>
      </method>
      <method name="put">
        <allow netmask="0:0:0:0:0:0:0:1/128" token="test"/>
        <allow netmask="127.0.0.0/8" token="test"/>
      </method>
    </endpoint>
    -->
</config>

General structure

A configuration consists of several rules for endpoints. These are the <endpoint> elements. Each endpoint element requires a path attribute. This specifies the path to the corresponding endpoint and may contain regular expressions. The sub-elements of <endpoint> are <method> or <cors> elements.

JWT authentication (JSON Web Token).

An endpoint element may additionally contain the jwtAuth attribute and require authentication using JSON Web Token. The default value is false.

<endpoint path="." jwtAuth="true">
    ...
</endpoint>

If JWT authentication is enabled and the token is invalid, Goobi responds with HTTP status code 401 (Unauthorized).

Endpoints enabled by default

By default, the following paths are enabled without access restrictions:

/view/object/
/view/media/
/process/image/
/messages/
/processes/\\d+?/images.*
/openapi.json

The expression \\d+? describes a process id.

When Goobi Workflow is in development mode, the endpoint /developer/ is enabled by default. As long as Goobi Workflow is developed without port shares on the router in a local network, this endpoint is not publicly accessible.

Allow access to API methods

One or more allowed HTTP request methods can be specified for each API endpoint. For this purpose, a method sub-element is entered in the corresponding endpoint for each HTTP method used. A method element has exactly one name attribute. The most commonly used HTTP methods are:

get
head
post
put
delete
options

Within the method element, the allow element is used to configure the access shares and restrictions for the particular endpoint/method combination. For this, one or more shares are added as follows:

<method name="get">
    <allow netmask="0:0:0:0:0:0:0:1/128" token="CHANGEME"/>
    <allow netmask="127.0.0.0/8" token="CHANGEME"/>
    <!--
    or for public endpoints:
    -->
    <allow />
</method>

An IPv4 or IPv6 netmask is specified with the netmask attribute and the associated token with the token attribute. If the token or the netmask attribute is omitted, access is allowed without a token or with any IP address. If both are omitted, the endpoint can be accessed from any IP address without a token. This can be useful if an endpoint is to be completely public or authenticated by other methods (for example JSON web tokens). The test token can be used to allow access to endpoints from localhost only.

When checking a request, Goobi proceeds by document order and checks the first <enpoint>/<method> pair that matches the request. If no <allow> rule matching the request is found, Goobi returns status code 401 and refuses to process the request. This also implies that the order of rules in this configuration file should be respected. If Goobi returns a message with 401, it may be because an endpoint higher up was formulated too generally and Goobi does not advance to a rule lower down because processing is already denied due to the rule higher up in the document.

HTTP header fields

In addition to the shares, the header element can be used to specify one or more HTTP header fields which will be automatically written by Goobi to the header fields of the response protocol when requests are made with the corresponding request method at the respective endpoint. This can be handy if the client or browser should get certain meta information about the endpoint's behavior. To do this, the name attribute is used to specify the HTTP header field. The header element may contain one or more value sub-elements and in practice may look like the following:

<method>
    <allow />
    <header name="Content-Language">
    	<value>de-DE</value>
    	<value>en-US</value>
    </header>
</method>

In the HTTP header, following field is added:

HTTP/2 200 OK
...
Content-Language: de-DE, en-US

CORS (Cross Origin Requests)

The configuration also allows cross-origin requests to be enabled. For this purpose, a <cors> element can be created inside an endpoint, where the allowed methods are configured with <method> elements and the allowed origins with <origin> elements. If a <cors> element is configured for an endpoint, Goobi will automatically handle any preflight requests sent by the browser. For example, the configuration may look like the following:

<endpoint path="/vocabulary/.*">
    <cors>
        <method>GET</method>
        <origin>https://intranda.com</origin>               
    </cors>
    <method name="get">
        <allow />
    </method>
    <method name="post">
        <allow />
    </method>
</endpoint>

The cross-origin methods can be queried using the HTTP request method OPTIONS and the endpoint specified in the configuration. For example, if an HTTP request is sent with the following header, Goobi lists the possible cross-origin methods in the HTTP response header fields. For an OPTIONS request, the response has no content and the status code is 204 (No Content).

Request:

OPTIONS /vocabulary/.* HTTP/2
...

Answer:

HTTP/2 204 No Content
...
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: https://intranda.com
Access-Control-Allow-Headers: origin,content-type,accept,token
...

The goobi_exportXml.xml file specifies technical details about the properties and associated XML namespaces used when generating docket files.

The file is usually located at the following location:

/opt/digiverso/goobi/config/goobi_exportXml.xml

For example, this configuration file looks as follows:

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

<config_exportXml>

	<namespace name="mets" value="http://www.loc.gov/METS/" />
	<namespace name="mods" value="http://www.loc.gov/mods/v3" />
	<namespace name="goobi" value="http://meta.goobi.org/v1.5.1/" />
	<namespace name="xlink" value="http://www.w3.org/1999/xlink" />
	<namespace name="dv" value="http://dfg-viewer.de/" />
	<namespace name="wt" value="http://wellcome.ac.uk/" />

	<mets>
		<property name="shelfmarksource" value="//mets:mets/mets:dmdSec[1]/mets:mdWrap/mets:xmlData/mods:mods/mods:extension/goobi:goobi/goobi:metadata[@name='shelfmarksource']" />
		<property name="TitleDocMain" value="//mets:mets/mets:dmdSec[1]/mets:mdWrap/mets:xmlData/mods:mods/mods:extension/goobi:goobi/goobi:metadata[@name='TitleDocMain']" />
		<property name="CorporateName" value="//mets:mets/mets:dmdSec[1]/mets:mdWrap/mets:xmlData/mods:mods/mods:extension/goobi:goobi/goobi:metadata[@name='CorporateName']" />
		<property name="PublicationYear" value="//mets:mets/mets:dmdSec[1]/mets:mdWrap/mets:xmlData/mods:mods/mods:extension/goobi:goobi/goobi:metadata[@name='PublicationYear']" />
	</mets>

	<!--
	<anchor>
		<property name="ManifestationType" value="//mets:mets/mets:dmdSec[1]/mets:mdWrap/mets:xmlData/mods:mods/mods:extension/goobi:goobi/goobi:metadata[@name='_ManifestationType']" />
	</anchor>
	-->

</config_exportXml>

General

This configuration file is used to specify additional properties to be included when exporting docket files. Since these properties can be gathered from different areas, it is necessary to specify for each property where it is defined. This is done with the help of namespaces, which are also defined beforehand.

Defining namespaces

The <namespace> elements are used to define namespaces that can be used to add further properties for exporting metadata. There are some projects and institutions that define such namespaces. In this configuration file, a <namespace> element is created for each required namespace definition.

Namespaces are identified by a name or abbreviation specified with the name parameter. This should be short and descriptive, as it will be used often later. Namespace names may not occur more than once. Usually the project name or an abbreviation of it is used. The project name is usually evident from the domain in the specified URL.

Accordingly, namespaces refer to a URL defined in the value parameter. This URL must point to an XML specification that contains further information about the respective namespace and the available property names. Further information can be found in the respective documentation for the namespace specifications.

For example, if the following namespace is defined,

<namespace name="mets" value="http://www.loc.gov/METS/" />

so an element mets:xmlData can be used later. Goobi can then assign that in the namespace mets, which in turn is defined in the specification under http://www.loc.gov/METS/, the element xmlData should be searched for. There it is defined according to the project.

Define properties

Properties to be included in the export are specified in <property> elements. The title specified in the name parameter will be reused for the structure of the exported docket file. The value parameter contains one or more properties which are structured as follows.

Syntax for properties

All properties are separated with slashes (/). Additionally, the entire entry starts with two slashes. The basic syntax is as follows:

value="//field1/field2/field3"

Since no default namespace can be defined in the list of namespaces, each property is assigned a namespace, resulting in the following syntax:

value="//namespace1:field1/namespace2:field2/namespace3:field3"

Any number of elements can be specified. Only namespaces that have been previously defined in the <namespace> elements can be used. According to the namespaces, only certain properties can be specified. For example, it looks like this:

value="//mets:mets/mets:mdWrap/mets:xmlData/mods:mods/mods:extension/goobi:goobi"

It may happen that properties exist as lists. In this case the number of the list element is indicated with square brackets. It should be noted that the count starts at 0. In the following example the second element from the list dmdSec is used. (The first element would then have the number 0).

mets:dmdSec[1]

In addition, for more complex properties, it is possible to select which component of the property should be used. In the following example, the sub-element with the property name = PublicationYear is selected from the metadata element.

goobi:metadata[@name='PublicationYear']

meta.xml or meta_chanor.xml

If only a meta.xml is used to describe the process, all <property> elements are created inside a <mets> element.

If an additional meta_anchor.xml is used to describe the process, then all <property> elements are created within an <anchor> element.

For an export, only the <property> elements from one of the two elements are ever used.

If a goobi_exportXml.xml file is to be used for different projects, some of which use only the meta.xml and some of which also use the meta_anchor.xml, both elements can be specified with their respective <property> subelements without any problems. These do not influence each other.

At various points, Goobi workflow is controlled via several configuration files. At this point, the most important configuration files are listed and explained in detail.

The configuration file goobi_opac.xml defines the communication between Goobi workflow and external data sources. This usually applies to systems such as library catalogs. The file is usually located at the following storage path:

/opt/digiverso/goobi/config/goobi_opac.xml

For example, this configuration file looks as follows:

<?xml version="1.0" encoding="UTF-8"?>
<opacCatalogues>
    <doctypes>
        <type title="monograph" isContainedWork="false" isMultiVolume="false" isPeriodical="false" rulesetType="Monograph" rulesetChildType="Special Monograph" tifHeaderType="Monographie">
            <label language="de">Monographie</label>
            <label language="en">Monograph</label>
            <mapping>Aa</mapping>
            <mapping>Oa</mapping>
            <mapping>Monograph</mapping>
        </type>
        <type title="periodical" isContainedWork="false" isMultiVolume="false" isPeriodical="true" rulesetType="Periodical" rulesetChildType="PeriodicalVolume" tifHeaderType="Band_Zeitschrift">
            <label language="de">Zeitschrift</label>
            <label language="en">Periodical</label>
            <mapping>Ab</mapping>
            <mapping>Ob</mapping>
            <mapping>Periodical</mapping>
        </type>
        <type title="multivolume" isContainedWork="false" isMultiVolume="true" isPeriodical="false" rulesetType="MultivolumeWork" rulesetChildType="Volume" tifHeaderType="Band_MultivolumeWork">
            <label language="de">Mehrbändiges Werk</label>
            <label language="en">Multivolume work</label>
            <mapping>Of</mapping>
            <mapping>Af</mapping>
            <mapping>OF</mapping>
            <mapping>AF</mapping>
            <mapping>MultiVolumeWork</mapping>
        </type>
    </doctypes>
    <catalogue title="K10Plus">
        <config opacType="PICA" description="K10plus" protocol="http://" address="kxp.k10plus.de" port="80" database="2.1" charset="UTF-8" iktlist="IKTLIST-GBV.xml" ucnf="UCNF=NFC&amp;XPNOFF=1" />
        <searchFields>
            <searchField label="LCCN" value="12" />
            <searchField label="ISBN" value="7" />
            <searchField label="ISSN" value="8" />
        </searchFields>
		<specialmapping type="multivolume" />k10_multivolume</specialmapping>
		<specialmapping type="periodical" />k10_periodical</specialmapping>
    </catalogue>
    <catalogue title="Library of Congress">
        <config opacType="GBV-MARC" description="Library of Congress SRU (Voyager)" address="http://opac.intranda.com/sru/DB=1" port="80" database="1" iktlist="IKTLIST.xml" ucnf="XPNOFF=1" />
        <searchFields>
            <searchField label="LCCN" value="12" />
            <searchField label="ISBN" value="7" />
            <searchField label="ISSN" value="8" />
        </searchFields>
    </catalogue>
    <catalogue title="UBBI">
        <config opacType="ALMA-MARC" description="Katalog UB Bielefeld" address="https://hbz-ubbi.alma.exlibrisgroup.com/view/sru/49HBZ_BIE" port="80" database="1" iktlist="IKTLIST.xml" ucnf="XPNOFF=1" />
        <searchFields>
            <searchField label="HBZHT" value="alma.other_system_number_035_a_exact"/>
            <searchField label="MMS ID" value="mms_id"/>
            <searchField label="ISBN" value="alma.isbn"/>
            <searchField label="ISSN" value="alma.issn"/>
        </searchFields>
        <beautify>
            <setvalue tag="tag1" subtag="21" value="a">
                <condition tag="tag2" subtag="22" value="s" />
          	</setvalue>
 			<setvalue tag="tag3" subtag="33" value="m">
                <condition tag="tag4" subtag="33" value="s" />
            </setvalue>
		</beautify>
    </catalogue>
</opacCatalogues>

Publication types

Several publication types can be defined in the <doctypes> element. Each type is in its own <type> element and has some properties specified by parameters and subelements.

Properties of a publication type

All important properties of a publication type are specified as parameters in the <type> element. The following parameters can be used:

Translation of titles

The name of a publication type specified in the title parameter is used internally in the software and is therefore not always easily readable by users and is not translated automatically. Therefore, the publication type name can be translated into different languages using the <label> element. The language parameter specifies the language abbreviation. Depending on the configuration, the following languages are usually supported:

<type title="periodical">
    <label language="de">German translation</label>
    <label language="en">English translation</label>
    <label language="es">Spanish translation</label>
    <label language="fr">French translation</label>
    <label language="it">Italian translation</label>
    <label language="iw">Hebrew translation</label>
    <label language="nl">Dutch translation</label>
    <label language="pt">Portuguese translation</label>
</type>

Mapping to other data formats

It can happen that a publication type should be able to be found with a search function or with external data formats via certain designations or abbreviations that cannot be derived from the title. For this purpose, further designations can be specified for each type with the sub-element <mapping>id42</mapping>. If then, for example, the ID id42 is searched for, the corresponding publication type will be found.

Catalogues

Goobi can use metadata from different catalogs. These are entered with the <catalogue> element directly in the <opacCatalogues> element. For each catalog element, the title parameter specifies the official name of the respective catalog.

Configuration of a catalogue

Some other properties of a catalog are specified as parameters in the <config> subelement. The following parameters can be used:

Search options

Metadata is identified in catalogs using specific numbers (for example ISBN or ISSN). If metadata is to be imported into Goobi using a given number from the respective catalogue, the ` element can be used to list different numbering systems. A user can then enter an ISBN number in the following example and select the ISBN field to match it:

<searchFields>
    <searchField label="LCCN" value="12" />
    <searchField label="ISBN" value="7" />
    <searchField label="ISSN" value="8" />
</searchFields>

Each <searchField> element represents an option in the corresponding dropdown menu. The text specified in label is displayed on the user interface. The value defined in value is the internal ID of the numbering system. Depending on the catalog, a text-based ID can also be used. This can look like this, for example:

<searchField label="ISBN" value="alma.isbn"/>
<searchField label="ISSN" value="alma.issn"/>

Detailed information about supported numbering systems can be retrieved from the respective catalogue API. This is an XML file that can be called directly in the browser. The domain must be adapted according to the used provider.

https://opac.intranda.com/XML=1.0/IKTLIST
https://kxp.k10plus.de/XML=1.0/IKTLIST

Mapping to publication types

As described above, publication types can be found with alternative labels. In addition, it is possible in <catalogue> elements to link catalogue-specific designations (and thus also catalogues) to publication types using the <specialmapping> element. Thus, matching publication types can be defined and found via the alternative designations of a catalogue.

The type parameter of the <specialmapping> element refers to the title of the previously defined publication type. The <specialmapping> element contains an alternative name. The following example would link the search term k10plus_periodical to the publication type periodical for a K10Plus catalogue:

<doctypes>
    <type title="periodical">
    ...
    </type>
</doctypes>
...
<catalog title="K10Plus">
    <specialmapping type="periodical">k10plus_periodical</specialmapping>
</catalog>

Customizing records from MARC files

If records are retrieved from catalogs, they are imported into Goobi via MARC files, among others. Records from these files can be customized using certain replacement patterns. For this purpose, the <beautify> element is used as a direct sub-element of the corresponding <catalogue> element and can contain any number of <setvalue> commands.

Since processing MARC data with these commands can become very complex, only a few simple examples are described here based on the following MARC data excerpt.

...
<datafield tag="book" ind1="" ind2="">
    <subfield code="author">Alice April</subfield>
    <subfield code="title">Garden tips</subfield>
    <subfield code="year">1930</subfield>
    <subfield code="other_id">aaa01</subfield>
</datafield>
<datafield tag="book" ind1="" ind2="">
    <subfield code="author">John Doe</subfield>
    <subfield code="title">The small world</subfield>
    <subfield code="year">1920</subfield>
    <subfield code="other_id">aaa02</subfield>
</datafield>
<datafield tag="paper" ind1="" ind2="">
    <subfield code="author">Dr. Arthur Williams</subfield>
    <subfield code="title">Complex numbers</subfield>
    <subfield code="year">1910</subfield>
    <subfield code="other_id">aaa03</subfield>
</datafield>
...

The following command can be used to replace certain values. For example, if it turns out that some records of type book have an invalid year (year), incorrect data can be corrected. The setvalue command specifies that in each datafield with tag book addressed with the inner <condition>, the subfield with parameter code="year" should get the value 1900. The <condition> says that all datafield elements should be considered which have the tag book and where a subelement with code="year" and the value 190 exists.

<beautify>
    <setvalue tag="book" subtag="year" value="1900">
        <condition tag="book" subtag="year" value="190" />
    </setvalue>
</beautify>

Data can be filtered with the <setvalue> command. For example, if you want to remove the other_id elements, their value can be overwritten with an empty string.

Note: An asterisk (*) is a placeholder for an arbitrary value. Regular expressions are not supported.

<beautify>
    <setvalue tag="*" subtag="other_id" value="">
        <condition tag="*" subtag="other_id" value="*" />
    </setvalue>
</beautify>

Data sets can also be supplemented with new properties. However, this works only conditionally, because only the data from the MARC file and from the <setvalue> command can be accessed. For example, it is possible to assign new tags to records with certain contents:

<beautify>
    <setvalue tag="paper" subtag="target_group" value="students">
        <condition tag="paper" subtag="author" value="Dr. Arthur Williams" />
    </setvalue>
</beautify>

In the configuration file goobi_processProperties.xml further properties for projects, processes and steps can be specified. The file is usually located at the following memory path:

/opt/digiverso/goobi/config/goobi_processProperties.xml

For example, this configuration file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<config_processProperties>
	<property name="Example" container="0">
		<project>Project 1</project>
		<project>Project 2</project>
		<workflow>Workflow 1</workflow>
		<workflow>Workflow 2</workflow>
		<showStep name="Scanning" access="READ" duplicate="" />
		<showStep name="Check resolution" access="WRITE" duplicate="" />
		<showProcessCreation template="*" access="write">
          <display property="Resolution" value="undefined" />
        </showProcessCreation>
		<showProcessGroup access="write" />
		<validation>\w</validation>
		<type>LIST</type>
		<defaultvalue>Please select...</defaultvalue>
		<value>Value 1</value>
		<value>Value 2</value>
	</property>
</config_processProperties>

General

With each <property> element a property is defined. This can be configured to apply to one or more projects, one or more tasks, or one or more steps. Combinations are also possible. Instead of a project name, task title or step title, an asterisk (*) can be used to address all projects, tasks or steps.

For each <property> a name is specified with the name parameter, this should be unique and meaningful.

For each <property> a container is specified with the parameter container, in which the defined property should be internally classified.

Available configurations

The following tags are available as subelements for the <property> tag:

Available access rights

All access rights can be written in any capitalization, this will be ignored when reading.

If no value is specified or it is written incorrectly, READ is the default value.

Available data types

All data types can be written in any capitalization, this will be ignored when reading.

If no value is specified or it is written incorrectly, TEXT is the default value.

For the LIST and LISTMULTISELECT datatypes, a text such as Please select or one of the specified values can be specified as the default value with the <defaultvalue> tag. If the field is required, one of the specified values must be selected later, even if the value in <defaultvalue> differs.

Special features for processes

There are two cases where the properties defined in this file are queried. Either information about processes or about steps is queried.

In the case of a process, not all sub-elements are used. Only the elements shown in the following example are observed:

<?xml version="1.0" encoding="UTF-8"?>
<config_processProperties>
	<property name="Example" container="0">
		<project>Project 1</project>
		<project>Project 2</project>
		<showProcessGroup access="write" />
		<validation>\w</validation>
		<type>LIST</type>
		<defaultvalue>Please select...</defaultvalue>
		<value>Value 1</value>
		<value>Value 2</value>
	</property>
</config_processProperties>

The <workflow> and <showStep> elements are not used for processes.

Conditional display of properties

Properties can also be displayed conditionally. To do this, you can define that another property must have a certain value in order to control the display. The following example illustrates this:

	<property name="Resolution" container="Images">
        <project>*</project>
        <showProcessCreation template="*" access="writeRequired"/>
        <type>List</type>
        <value>300</value>
        <value>400</value>
        <value>600</value>
        <value>Other</value>
    </property>
    <property name="Special Resolution" container="Images">
        <project>*</project>
        <showProcessCreation template="*" access="write">
        	<display property="Resolution" value="Other" />
        </showProcessCreation>
		<showStep name="Scanning preparation" access="write">
		    <display property="Resolution" value="Other" />
		</showStep>
        <type>Text</type>
    </property>

The Special Resolution property is only displayed here both in the creation screen and in the Scanning preparation task if the value Other has been selected from the list in the Resolution property. If a different value is selected in the Resolution property, the Special Resolution text field is not visible.

In the translation files messages_xx.properties translations for texts in the user interface are specified. The xx mentioned here must be replaced by the corresponding language abbreviation depending on the language used. The abbreviations are described in more detail below. The files are usually located at the following memory path:

/opt/digiverso/goobi/config/messages_xx.properties

Since these files become very large and often have many thousands of entries, only a few lines are given here as examples:

English translations:

...
fileHasNLines=The file has {0} lines.
next=Next >
openFile=Open File
...

German translations

...
fileHasNLines=Die Datei hat {0} Zeilen.
next=Weiter >
openFile=Datei \u00F6ffnen
...

General

Goobi translates all texts in the user interface into the language set by the user. For this purpose, each text in Goobi has its own key, which is not displayed directly, but is searched for in the appropriate translation file. The text defined there is then displayed. The key is therefore the same for all languages, especially if additional languages are to be added.

If no entries or translations are found for a key, the key is displayed directly in the user interface. However, this is only intended for the development process. Normally all texts should be translated completely.

Standard files and user-defined files

The default translation files used by Goobi are already included in the installation and are not relevant here. The configuration directory (by default /opt/digiverso/goobi/config/) is where the user-defined files are created.

Supported languages

By default, following languages are supported:

Conventions for keys

• Keys must be unique. If a key is defined more than once, the wrong one may be used.

• Keys should have meaningful, but not too long names.

• Keys should be in English language.

• Multiple words in keys can be written in CamelCaseNotation (keyWithMultipleWords) or with underscores (key_with_multiple_words). Mixed forms are also common.

• Keys must not contain special characters and umlauts.

• Dots and dashes can be used without escaping.

• For translating process or step titles, spaces are often necessary in the key. These must be escaped (for example: 'import\ images').

Prefixes for keys

If many translations belong together or are used in the same plugin, prefixes should be used in the keys. This also has the advantage that related translations are easier to find in the messages files, since they are sorted lexicographically by keys.

Frequently used prefixes are for example:

Conventions for texts

• The file entry for a new translation should always be added at the appropriate place in all messages files to keep the files clear and compatible. This applies in particular also if a text cannot yet be translated meaningfully into a less frequently used language.

• If a text cannot yet be translated because, for example, no suitable translator is currently available, the English translation should be entered instead.

• If a translation has not yet been confirmed by an experienced interpreter or native speaker, the suffix 'zzz' is appended to the text.

The ending zzz

The suffix zzz is written as an ending to a translation to indicate that it still needs to be quality checked. This makes it easier for interpreters or native speakers to check translations, because they do not have to check all translations every time.

Goobi recognizes the ending 'zzz' by itself and displays the corresponding text without the ending.

For example, a translation may appear like this in the messages file:

choose_file=Please select a file zzz

Parameters

Messages can use parameters. This makes it possible to insert values into texts without having to split the texts at each individual inserted value. Parameters only work when texts are translated into Goobi with appropriate Java functions and associated parameters. Therefore they are only used for specific purposes.

For example, a translation with parameters may look like this:

user_is_not_allowed_to_execute_goobiscript=The user {0} is not allowed to execute the goobi script {1}.

Umlauts and special characters

There are some characters that must be escaped in the translations. These include some syntactic characters:

• ! becomes \!

• : becomes \:

• { becomes \{

• } becomes \}

• \ becomes \\

Because messages files are intended to be compatible with many languages, all special characters and umlauts are stored as Unicode sequences.

This has the advantage that files can be opened, edited and saved with any ASCII-compatible text editor without damaging the file encoding.

The disadvantage, however, is that umlauts and special characters must be entered manually as Unicode sequences.

German umlauts are given here as an example. Special characters for other languages can be taken from the Unicode character table.

• ä = \u00E4

• ö = \u00F6

• ü = \u00FC

• Ä = \u00C4

• Ö = \u00D6

• Ü = \u00DC

• ß = \u00DF

For example, a German translation would have to be coded as follows:

file_size=Dateigr\u00F6\u00DFe

The configuration file goobi_mail.xml is used to configure mail dispatch for Goobi. The file is usually located here:

/opt/digiverso/goobi/config/goobi_mail.xml

For example, this configuration file looks as follows:

<?xml version="1.0" encoding="UTF-8"?>
<goobiMail>
    <configuration enabled="true">
        <smtpServer>mail.example.com</smtpServer>
        <smtpPort>5587</smtpPort>
        <smtpUser>do-not-reply@example.com</smtpUser>
        <smtpPassword>PASSWORD</smtpPassword>
        <smtpUseStartTls>false</smtpUseStartTls>
        <smtpUseSsl>true</smtpUseSsl>
        <smtpSenderAddress>do-not-reply@example.com</smtpSenderAddress>
    </configuration>
    <apiUrl>http://example.com/goobi/api/mails/disable</apiUrl>
</goobiMail>

To deactivate the global sending of emails, it is sufficient to delete the goobi_mail.xml file or set the enabled attribute to false.

Additionally, the content of the emails can be configured. The following keys are available in the messages files for this purpose:

In addition to normal text or HTML elements, variables can also be used in the subject or body. The following variables are available for this purpose:

For example, an email text could be configured as follows:

mail_notification_openTaskBody=<html><body><h3>Hallo ${user},</h3><br /><p>folgender Schritt wurde ge\u00F6ffnet und kann nun bearbeitet werden:<ul><li>Projekt: ${projectname}</li><li>Vorgang: ${processtitle}</li><li>Schritt: ${stepname}</li></ul></p><div><a href="${url_cancelStep}">Benachrichtigungen f\u00FCr Schritte mit diesem Namen abbgestellen</a><a href="${url_cancelProject}"></div><div>Benachrichtigungen f\u00FCr dieses Projekt abbestellen</a></div><div><a href="${url_cancelAll}">Alle Benachrichtigungen abbestellen</a></div></body></html>

The goobi_webapi.xml configuration file is used to enable certain API endpoints of the Goobi Workflow Server for other servers or clients. The file is usually located at the following location:

For example, this configuration file looks as follows:

Goobi Workflow provides a REST API for communicating between the Goobi Workflow Server and other network participants using HTTPS protocol and JSON data objects.

The functions that are performed using the API are specified as endpoints in the URL. For example, the following URL returns the details of a process with the specified ID MY_ID:

However, there are also commands like process/create or process/delete that may only be executed by certain users.

A user can be another server or client. In both cases it needs a fixed IP address for which access is granted.

For each access right a <credentials> element is used. The ip parameter contains either the IPv4 address or the IPv6 address of the user. The password parameter specifies a token that must be specified as a URL parameter in a request from the respective user IP address. For example, if the password="super_user_password" token is specified in the access rule for the ip="10.20.30.40" IP address, an API request can only be answered if the user with the 10.20.30.40 IPv4 address uses the token=super_user_password URL parameter.

The token should not contain any special characters or URL syntax characters. Otherwise, these must be encoded later in the request according to the URL specification. If the My Password token is specified in the access rule, the space character in the request URL must be replaced with the hexadecimal value 0x20 and the URL parameter looks like this: token=My%20Password.

Each access rule contains one or more API commands. These commands or groups of commands can be used as soon as the combination of IP address and token described above matches. A command is defined with the <command> element and has exactly one name parameter containing the command. The command itself can optionally start with a slash (/).

In the above example, three access rules are specified that define the different access rights for different user groups. Thus, a super administrator has the ability to use all API commands (/). A normal administrator can execute all subcommands of process. For a standard user, only the process/check command is enabled.

The file goobi_projects.xml configures the mask for creating processes. Here it is defined per project which metadata and properties are allowed for certain publication types.

The file is usually located at the following location:

For example, this configuration file looks like this:

Definition of the projects

For each project a <project> element can be created. The name of the project is specified either with the name parameter or with the <name> sub-element. If a configuration is to apply to projects with different names, multiple <name> elements can be specified. Alternatively, a regex expression can be used instead of the name to address multiple projects. The default project configuration should always be a project named default. When a project is created in Goobi Workflow, a suitable configuration is searched for according to the following sequence:

1. search for the first project entry whose name matches or contains the project name

2. search for a project entry whose name, interpreted as a regular expression, matches the project name

3. search for a project entry with the name `default

4. use the first project entry

Project details

The sub-elements of <project> contain a number of details that are taken into account when loading the creation mask for tasks in the user interface.

Properties of a new process

All details around the input fields that are important for loading the creation mask are specified in the <createNewProcess> element. This includes in particular the <itemlist> element where the input fields are listed.

List of the input fields

Each input field in the user interface is described by an <item> in this list. These entries can be used to add text fields and dropdown menus. More specific fields, such as a file upload area, are described below.

Each <item> element contains as content the text that is displayed in the label column in the input mask table. This can additionally be translated into different languages by Goobi Workflow's translation mechanism using the messages files.

An <item> is displayed either as a text field or as a drop-down menu. The following parameters apply to both types of input fields:

Dropdown menus

As soon as an <item> contains the multiselect parameter and sub-items <select>, it will no longer be displayed as a text field but as a dropdown menu. The multiselect parameter can be set to true or false to allow or disallow the selection of multiple items.

Each <select> element can have a label parameter. The label text is displayed in the menu while the content of the <select> element is technically processed. This allows to specify a more readable alternative name for the display.

Even an <item> that is displayed as a dropdown menu needs a label. This is specified in parallel to the <select> elements.

For example, if a city abbreviation is to be selectable when creating an operation, it would be useful for users to have the spelled out names displayed in the menu:

Hiding input fields

The <hide> element can be used to hide input fields, i.e. <item> elements defined here. The field can contain for example the following values: collections, doctype, preferences, images and processtitle.

The collection selection can be hidden using collections, doctype controls the display of the field for selecting the document type, preferences the selection field for the ruleset, images the input for the expected number of digitised pages and processtitle the display of the generated process title.

Process title

If the process title is to be generated automatically, the <processTitle> element can be used to specify formation rules for the titles. Process titles can be generated differently for certain document types. To assign a document type to an education rule, the isdoctype parameter is used. Alternatively, all document types can be used and only a specific type can be excluded with the isnotdoctype parameter.

Between the start and end elements of <processTitle> is an expression describing the title to be generated. Text passages are written in single quotes and as variable names all properties defined above can be used. All elements are concatenated with the + operator.

For example, to generate a title for all documents that are not periodical that includes the author and the title of the document, the following entry would be useful:

The replacewith parameter can be used to specify a string to replace all invalid letters and special characters in the automatically generated operation title, if required. If the string is "", all invalid characters will be removed. Even if this parameter is missing, all special characters will be removed without replacement.

OPAC catalog selection

The OPAC catalog query can be activated by setting the use attribute to the value true within the <opac> parameter. The preselected catalog can be defined in the <catalogue> sub-element. If the value is not set or does not correspond to any entry from the goobi_opac.xml file, the first catalog defined there will be used as default value.

Using other operations as templates

To import the metadata from already existing operations, the use attribute in the <templates> element must be set to the true value. This makes the Select from existing tasks option available, which lists all tasks for which the Display in selection list checkbox was activated during creation.

Default document type

The publication type selected when opening the creation mask can be defined in the field <defaultdoctype>. The name used here comes from the doctypes definition of the configuration file goobi_opac.xml.

Metadata generation

By using the <metadatageneration /> element with the use="true" parameter, additional metadata can be automatically generated when an operation is created.

Uploading files

With the configuration of <fileupload> the upload area can be enabled. With this, files can already be uploaded to the newly created task. Which folders are available for selection can be configured in the subfield <folder>.

The regex parameter can be used to specify which file names are accepted by the upload button in the user interface. If the file selected by the user does not match the regex expression, the file will not be uploaded and an error message will be displayed. If the regex parameter is omitted or an empty string is specified, files of all file types and names are uploadable. Since the regex expression is evaluated by Primefaces, it must be enclosed in slashes:

Valid notation:

/^.*\.pdf$/

Invalid notation:

^.*\.pdf$

The messageKey parameter specifies a key which can be used in messages_xx.properties files to store individual error messages. For example, if a file upload is restricted to PDF files as shown above, then an error message indicating an incorrect file type can be specified in the messages files in all languages under the key specified here. If the parameter is omitted or the key is not found, a standard error message is displayed.

Tiff header

In the <tifheader> element, values can be specified that are to be written to the tiff headers. Here, a separate text can be defined for each publication type previously defined in a <item>.

For example, if a <item>monograph</item> has been defined, the following can be entered here:

Import from DMS

To import data from a document management system, the <dmsImport> element can be specified.

Validation

Data of the form can be validated. Validations can be specified in the <validate> element.

In the file config_contentServer.xml, technical details about the content server used in Goobi are provided. The configuration file can be used for Goobi Workflow and Goobi Viewer in the same way.

The file is usually located at the following location:

For example, this configuration file looks as follows:

Data types

In this configuration file settings are made with different data types. For overview all used types are explained briefly in the following table:

General settings and default values

In addition, the imageToPdfSizeFactor element can be used to set arbitrary parameters for file types for which a special factor should be used to scale from that file type to a PDF file (see example). In that case the image file extensions are used as parameter names and the scaling factors as values. A scaling of 1.0 means that the image size remains the same. Values below 1.0 or above 1.0 reduce or enlarge the image. The value 0 should not be used.

The size of image files can be limited on the content server. The following parameters can be used in the maxFileLength element:

For different application purposes it may be useful to scale images differently. The following parameters can be used in the scaling element:

For downloading images generated in the content server, a default file name can be specified here. The following parameters can be used in the image and pdf elements within the defaultFileNames element:

Default paths for locations of different file types can be specified for non-complete requests to the content server. The following parameters can be used in the defaultRepositoryPathImages, defaultRepositoryPathPdf, defaultRepositoryPathAlto, and defaultRepositoryPathMets elements:

The image data type initially includes all image file types which are not specified in detail. Therefore, defaultImageConfig can be used to make settings for image files. The following parameters can be used in the defaultImageConfig element:

PDF files are configured separately because they have some special properties unlike other image file formats. The following parameters can be used in the defaultPdfConfig element:

A color can be specified to mark different image elements. The following parameters can be used in the defaultHighlightColor element:

The following table shows some simple color examples:

Where alpha="255" means full opacity of the color (covers the image area completely) and alpha="0" means no opacity (invisible).

Image file types

Within the imageTypeSettings element, settings for any number of image file types can be defined. For each image file type a type element with the sub-element settings is specified.

For file types (type) the following parameters can be used:

Note: The minSize and maxSize parameters are queried as floating point numbers in the configuration, but later processed as long-numbers. Therefore, only integers should be specified.

For file type settings (settings) the following parameters can be used:

Water marks

When automatically processing and checking image files, the content server can set watermarks. These are images or parts of images that are inserted into the processed image as a kind of identity information (of the author). Watermarks can be configured with the watermark element and contain the following parameters:

Error watermarks can be used not to display errors in documents on a subsequent error web page, but to use them as watermarks (=overlay) directly in the image files. These can be configured with the errorWaterMark element and contain the following parameters:

PDF title pages

The content server can generate three different types of artificial title pages and insert them at appropriate places in multi-page PDF files. Artificial title pages are pages that contain some meta information about the document or chapter or document section that follows. Metadata is read from METS files of the corresponding process. Additionally, it is also possible to display image content linked in the METS file. The layout as well as static contents of the metadata pages are specified by XML documents, so-called templates, which can be customized according to individual needs.

With pdfTitlePage a unique title page can be generated for the entire PDF document. It is inserted before the first page and can only contain information about the entire work and the top structural element contained in the PDF file.

The pdfChapterTitlePages element can be used to insert title pages before each chapter or structure element and can contain information about the respective structure element and the overall work. For example, these pages can contain information about the document structure (tables of contents, chapters, subchapters, appendices, etc.).

The 'singlePdfTitlePage' element can be used to include additional, individual title pages in the PDF document, which provide information about special places in a book, for example. It can contain only information about the whole work.

.fo` template files can be used to generate additional PDF title pages. These can either be specified in server requests or specified in the following XML elements.

REST API

The REST API can be used to retrieve information about image files at the content server. The parameters attribution, logo and license are additional specifications that can optionally be set in the image metadata of the returned image files.

Cache storage

Caches can be used to temporarily store image data so that it is not necessary to recalculate all data for each (possibly identical) request. Different caches are used for processing different file types, which can be configured in more detail with the following XML elements. The contentCache element can be used for a general cache for image files, the pdfCache element for a cache for PDF files, and the thumbnailCache element for a cache for thumbnails.

Performance

The memoryUsage element can be used to specify some memory and runtime constraints for the content server. The memoryUsage element contains general settings and further subelements for specific file types. The following parameters can be used for memoryUsage:

For the parameter memoryUnit there are some, partly misleading, values. The following table shows in each case which values can be used and which exact numeric values they correspond to internally.

There are also several possible values for the timeoutUnit parameter. The following table shows in each case how these are interpreted internally:

With the sub-elements image, pdf and metsPdf special settings can be made for the corresponding file types. The following parameters can be used equally for all subelements:

S3 storage

The S3 element can optionally be used to include S3 cloud storage to offload data.

In the configuration file goobi_opacUmlaut.txt umlauts are specified which should be replaced when automatically generating process titles. The file is usually located at the following location:

For example, this configuration file looks as follows:

Usually, Goobi Workflow automatically generates the process titles used. These contain the first letters of the author and an abbreviation of the corresponding work name.

Since the task title cannot contain umlauts or special characters for compatibility reasons, Goobi tries to replace them with compatible letters with similar meanings.

While it is intuitive for a user that an ä can also be replaced by an a, these two letters have no technical connection. Therefore, this context must be configured in terms of language usage. Usually the configuration shown above is already present and covers most languages.

In the file goobi_opacUmlaut.txt the used replacement rules are specified. The first column contains the characters to be replaced. Behind this is the replacement character. This may not be a special character or an umlaut.

All special characters, which are not considered in this configuration file, are removed without replacement from the name when generating the process title.

The translation algorithm is implemented in such a way that also multi-letter strings can be replaced. The following configuration is also possible, whereby exactly one space character is always expected as a separator:

Please note that the process title is first generated using the original names and then the umlauts are replaced. Thereby it can happen that the length of the process title changes in case of a multi-letter substitution.

For example, if the author's name is Björn and the first four letters are used, the result is the abbreviation björ (without capitalization). Since the ö now becomes oe, the abbreviation changes to bjoer and now has five letters.

In the configuration file goobi_config.properties, some fundamental settings are done for Goobi Workflow. The file is usually located at the following file system path:

For example, this configuration file looks as follows:

General

This configuration file has been used in Goobi Workflow for a very long time and therefore contains partly obsolete settings which are supported nowadays only for compatibility reasons. These are marked separately and if necessary describe an alternative how to replace these settings.

Since the settings have been added over a long period of time and are still being added, different naming conventions have always been used in the variable names. Therefore, special attention must be paid to the correct use of upper and lower case as well as underscores and periods in the variable names.

This configuration file contains settings for many different topics. Sometimes it is unavoidable that certain settings fit to several topics and, depending on the application purpose, can also be in different categories. If certain settings cannot be found at the expected place, it is recommended to search the page with the search function of the browser (usually Ctrl+F).

Many settings have default values that are chosen to be useful for most users. Therefore, not all settings need to be specified in the configuration file or can simply be commented out.

Comments are marked with a hash symbol (#) at the beginning of the line. This is also useful to disable settings.

Data types used

Data types are specified for the settings in this configuration file. Unless otherwise specified, the following values are allowed:

Basic information about Goobi Workflow

There is some basic information about the installed Goobi Workflow instance and about Goobi in general, specified in the configuration and partially displayed on the login page in the web browser.

Directories

Some directory paths can be set in the configuration file. Most of them are specified relative to the Goobi directory. The Goobi directory is usually located in /opt/digiverso/goobi/.

Some directories contain the text sequence {processtitle}. This is used in the respective directory names to insert the automatically generated title of a process. This ensures that the corresponding directories are created and used separately for each process.

General user settings

All custom user settings are stored by Goobi Workflow in the internally used database. The settings specified here are relevant for pages where no user is logged in (for example, the login page) and therefore the user-specific settings do not exist. Other settings in this category apply to all users and are not account-specific customizable.

Minimum password length

The password length is only checked when creating an account and when changing the own password. Existing passwords that are too short can still be used as long as this value is increased afterwards.

Administrators have the possibility to generate a new random password for users. These are always generated 10 characters longer than the minimum password length.

Additional user permissions

Additional user permissions can be specified. For this purpose, a new entry with the 'userRight' property is made for each added permission. Thus, this value can occur multiple times and will be interpreted as a list by Goobi Workflow.

This could look like this

Note: You should not enter user permissions whose name already exists in Goobi Workflow. This can lead to wrong behavior of some functions.

Additional functionalities in the user interface

Goobi Workflow allows some optional functionalities for the user interface in the web browser. For this purpose there are the following switches that can be set to 'true' to enable functionalities:

The following setting is used to filter the list of displayed sessions in the session overview. The setting itself can be used multiple times, each time specifying a client name (for example browser name) to be filtered from the session list.

For example, this looks like this if there are multiple names:

Activate LDAP

The actual LDAP configuration is located in the database used by Goobi Workflow. In this database, there is a data record with numerous setting options for each LDAP group used. Whether LDAP is included can be controlled with the following parameter.

Configure truststore

The truststore is used in Goobi Workflow to manage certificates and SSH keys. These can be used, for example, for authentication to the LDAP server or to other servers. To use the truststore, the following values must be configured.

OpenID Connect

Normally, user accounts are stored in the mariadb database managed by Goobi Workflow. Additionally there is the possibility to authenticate users with OpenID accounts.

Single Sign On (SSO)

SSO can be used to allow and configure authentication via HTTP headers. This allows or disallows staying logged in to a session in the browser using HTTP header fields.

Set up external users

The following settings can be used to determine whether users with external accounts can be logged in to the system and, if so, how default values should be set that otherwise exist for normal accounts in the database.

Database settings

In Goobi Workflow it is possible to search for specific terms in processes, tasks and other records. Since the search is handled by the SQL database used in the background, there are some settings available to adapt the search to the needs of each project.

For the settings DatabaseLeftTruncationCharacter and DatabaseRightTruncationCharacter, % is specified in each case. This will cause the database search to be performed with SQL as follows (This example is for illustration purposes only and does not work this way in the actual database):

This selects all records in which the search term occurs at any position. For example, if you omit the prefix % and search for search term%, you can search at the beginning of a record. This means, for example, that all books beginning with "The" can be searched for. If the prefix and suffix are omitted, only the search term is searched for and all records are selected that exactly match the search term.

To make database searches easier, aliases can be defined to group multiple properties together as one meta-property. For example, when searching for a person, it would be quite time-consuming to search for all authors, publishers, clerks, other persons, etc. For this reason, search terms can be listed and grouped under one name.

For example, following aliases could be configured:

Processes and process log

The following settings can be used to set the process log and some details for the editing of processes.

Configuration of jobs

For automatically executed background processes, it is possible to specify when they should be executed. The first three properties in the following list, marked with daily, are executed every day. The number of milliseconds specified is the time between 0:00 and the time the task is executed. This has the advantage that certain tasks can be executed at night, for example, when the load on the server is low.

The second advantage of this configuration is that the times of day can be set according to the difference between server time and the most used user time of day. This can happen when a server is located in another country (or uses UTC) and employees worldwide from different time zones work together on the server.

If -1 is specified, the corresponding job will be disabled.

The number of milliseconds can be calculated as follows:

• One second has 1000 milliseconds

• One minute has 60 seconds and thus 60 000 milliseconds

• One hour has 60 minutes and thus 3 600 000 milliseconds

• One day has 24 hours and thus 86 400 000 milliseconds.

So the given time should be between 0 and 86 400 000 to avoid errors. A few examples:

• For 0:00 o'clock 0 is indicated

• For 3:00 o'clock (3:00 AM) 3 * 3 600 000 = 10 800 000 is indicated

• For 18:30 (6:30 PM), 18 * 3 600 000 + 30 * 60 000 = 66 600 000 is given

For the setting 'goobiAuthorityServerUploadFrequencyInMinutes' a time in minutes is specified.

Downloadable information

In Goobi Workflow, processes, templates, masterpieces and metadata can not only be searched and displayed, but also exported to various file formats and downloaded. Some data from the database are already taken into account by default:

• processes.Title The title of a process

• processes.processesID The ID of a process

• processes.creationdate The creation date of a process

• processes.sortHelperImages The number of images in the process

• processes.sortHelperMetadata The number of metadata in the process

• projects.title The title of the project in which the process is located

• log.lastError The last detected error in the editing of this process

In addition, the downloadAvailableColumn setting can be used to include other properties in the exported files. For this purpose the mentioned setting can be used multiple times. All matching rows will be read in together by Goobi Workflow and processed as a coherent list.

In each line exactly one table column name from the Goobi database is specified. The following table columns are currently available (Goobi version 22.08):

• prozesseeigenschaften.prozesseeigenschaftenID

• prozesseeigenschaften.Titel

• prozesseeigenschaften.WERT

• prozesseeigenschaften.IstObligatorisch

• prozesseeigenschaften.DatentypenID

• prozesseeigenschaften.Auswahl

• prozesseeigenschaften.prozesseID

• prozesseeigenschaften.creationDate

• prozesseeigenschaften.container

• vorlageneigenschaften.vorlageneigenschaftenID

• vorlageneigenschaften.Titel

• vorlageneigenschaften.WERT

• vorlageneigenschaften.IstObligatorisch

• vorlageneigenschaften.DatentypenID

• vorlageneigenschaften.Auswahl

• vorlageneigenschaften.vorlagenID

• vorlageneigenschaften.creationDate

• vorlageneigenschaften.container

• werkstueckeeigenschaften.werkstueckeeigenschaftenID

• werkstueckeeigenschaften.Titel

• werkstueckeeigenschaften.WERT

• werkstueckeeigenschaften.IstObligatorisch

• werkstueckeeigenschaften.DatentypenID

• werkstueckeeigenschaften.Auswahl

• werkstueckeeigenschaften.werkstueckeID

• werkstueckeeigenschaften.creationDate

• werkstueckeeigenschaften.container

• metadata.processid

• metadata.name

• metadata.value

• metadata.print

It should be noted that only the column name is specified in the configuration. Otherwise the columns cannot be found, because the column names specified here are directly composed with the expected table names and searched. This has the side effect that by specifying for example 'Title' the title of processes, the title of templates and the title of masterpieces are taken into account.

For example, the following configuration can be made:

This would result in the following additional table columns being used:

• prozesseeigenschaften.Titel

• prozesseeigenschaften.DatentypenID

• vorlageneigenschaften.Titel

• vorlageneigenschaften.DatentypenID

• werkstueckeeigenschaften.Titel

• werkstueckeeigenschaften.DatentypenID

• metadata.name

• metadata.value

• metadata.print

Success and error messages for tasks

Manual tasks can be either completed successfully or set to error state by users in Goobi. In order to provide more information about the cause and resolution of errors, error and success messages can be pre-configured to be available later as a drop-down menu when completing (or canceling) tasks.

The following examples show how such messages can be used:

Note: Messages cannot be translated automatically and should be specified in a language that is understandable to as many users involved as possible. For international projects, English should be used.

Any number of messages can be specified. The respective drop-down menus are only available if at least one corresponding message is specified. All messages for error descriptions start with the prefix task.error.. All messages for problem fixes start with the prefix task.solution..

After each prefix there is a short text which should be displayed as a dropdown item. Spaces must be escaped in it. After the equal sign follows a detailed description. This will be displayed later in the step details. At the placeholder {} the additionally specified remark (from the text field below the dropdown menu) will be inserted later.

Scripts

Scripts can be configured to set up the file system. In a Goobi installation there are already suitable scripts included, but they are not set as default values here.

Include S3 cloud

Amazon provides a cloud system where data objects can be stored in "buckets". This can be integrated by Goobi Workflow and used to exchange data with other servers.

To use S3, access data from the S3 service used is required. These must be specified in this configuration file.

Proxy server settings

A Goobi server can use a proxy server for certain transactions with other servers or clients. By default, no proxy server is configured. To use a proxy server, you must first enable its use.

The default values for http_proxyIgnoreHost are predefined as follows. The list can be extended as needed:

Server and API settings

This category includes some settings that can be used to configure URLs and credentials to specific web services. Settings are also available to determine the behavior of the internal REST API. Especially for URLs, make sure to use the correct protocol (HTTP or HTTPS) and port number if the corresponding server or service uses one other than 80.

Configure message queues

Goobi Workflow uses multiple message queues to communicate with other processes on the same server (localhost) or other servers. ActiveMQ is always used for production use. For development purposes, SQS can be used in some cases. Since the entire constellation and configuration of the message queues is somewhat confusing, all configuration possibilities are documented here for the sake of completeness, even if individual constellations are not used on production systems. In each case, it is indicated which configurations are relevant for a production system.

Message queues used

• Goobi Workflow uses one or more slow queues to transmit normal process communication notifications.

• There is a fast queue for transmitting particularly small or time-critical information.

• An internal DLQ (Dead Letter Queue) is used to catch undeliverable notifications on the same server.

• An external DLQ is used to catch undeliverable notifications between multiple servers.

• There is a separate queue for commands that can be sent either on the same server or between different servers. These can be executable scripts, for example.

Simple Queue Service (SQS)

In principle, all queues can be operated with ActiveMQ. The external DLQ and the queue for commands have the special feature that they can work either with ActiveMQ or with SQS (Simple Queue Service). As long as ActiveMQ is used for these queues, it is possible to switch between a localhost service and an external service. The localhost service is set with default parameters and does not need to be configured further. If an external service is to be used or other individual configurations are to be made, this is configured in the file goobi_activemq.xml. The SQS service, on the other hand, is always located on the same server (localhost) and does not need to be configured.

Configuration

Additionally the names of the respective queues can be configured. This is normally not required and is documented here for completeness.

Metadata editor

The metadata editor has many setting options that can be sorted both technically and thematically. As a compromise, and because there is no "one" correct sorting, all settings are sorted by categories, such as "User Interface", "Export", etc. For OCR settings, for example, this means that showing/not showing the OCR button is configured in the "User Interface" section, while technical details about OCR are described in the "Export" section.

General settings

In the General Settings you can find settings concerning the editor itself and default values for new documents.

User interface

The "User Interface" category documents settings that can be used to configure the display of content or the display/non-display of buttons.

Image files and thumbnails

This category documents settings for image files, thumbnails, the display of images, and the tiling of images in the user interface.

The maximum size of image files (in bytes) is defined with two independently configurable values. With the value MaxImageFileSize a number is specified, such as 1, 5 or 10. With the additional value MaxImageFileSizeUnit the unit of measurement is specified. These in combination give the maximum number of bytes an image file may not exceed. Important: Only integer numbers can be used.

Since there are many misunderstood units of measurement, the following table lists all accepted values and their internally used numeric values.

This can be used, for example, to make the following settings:

or

The following values can be used to configure information about supported image and tile sizes for JSON API requests. The following API request can be used to retrieve this information about images from operations:

Thereby all values can be used multiple times and return multiple values in the API request.

For example, a configuration could look like this:

When completing steps, various internal data checks are performed. Among other things, the number of existing and processed image files is checked. The historyImageSuffix value can be used to specify one or more file types that will be considered for this count.

This setting is used for file extensions and can also contain general texts with which a file name should end, but no regular expressions are interpreted.

For example, if all *.tif, *.jpg and *.jpeg files are to be considered, the following list could be used:

Validation

This category contains settings for validating operations, image files and metadata.

Export

This category describes settings that affect the export of operations to downloadable files or files that can be cached on the server.