Installation and configuration

To start up the Goobi-to-Goobi mechanism, various plugins must be installed and configured on both the source and target systems. These are described in detail here.

1. Source system

First of all, the source system must be prepared for export. This includes first of all the installation of the correct plugin. Afterwards, only a permission for the appropriate users has to be configured to allow the export.

1.1 Installation

On the source system, the plugin plugin_intranda_administration_goobi2goobi_export must first be installed to create the export directories. To do this, the following two files must be copied to the appropriate paths:


Please note that these files must be readable by the user tomcat.

1.2 Configuration

To enable the user to export data, the user must have the following roles:

Export database details

These roles can be configured within the Goobi workflow user groups. To do this, simply select the roles on the right-hand side or enter them in the input field and then click on the plus icon.

With this configuration the preparation on the side of the initial system is already completed.

2. Target system

The target system must also be prepared for the import. After the installation of the corresponding plugin and the corresponding configuration files, some configurations have to be checked or made.

2.1 Installation

On the target system, the plugin plugin_intranda_administration_goobi2goobi_import must first be installed to import the export directories. To do this, the following two files must be copied to the appropriate paths:


After the installation of the actual plugin, the corresponding configuration files must also be installed. These can be found under the following paths:


Again, please note that the installed files must all be readable for the user tomcat.

2.2 General configuration

To enable a user to perform the import, the user must have the following role:


This role can be configured within the Goobi workflow user groups by entering it in the input field on the right-hand side and clicking on the plus icon.

2.3 Configuration for importing the infrastructure

To influence the data to be imported during the import of the infrastructure, the configuration file plugin_intranda_administration_goobi2goobi_import_infrastructure.xml can be adapted. This configuration can look like the following example:

        <project name="intranda test project">
            <newProjectName>new project name</newProjectName>
            <!-- filegroups -->
            <filegroup name="SDB">
            <exportConfiguration useDmsImport="true" dmsImportCreateProcessFolder="false" dmsImportTimeOut="0" dmsImportRootPath="/opt/digiverso/viewer/hotfolder" dmsImportImagesPath="/opt/digiverso/viewer/hotfolder" dmsImportSuccessPath="/opt/digiverso/viewer/success" dmsImportErrorPath="/opt/digiverso/viewer/error" />
            <metsConfiguration metsRightsOwnerLogo="" metsRightsOwnerSite="" metsRightsOwnerMail="" metsDigiprovReference="" metsDigiprovPresentation="" metsDigiprovReferenceAnchor="" metsPointerPath="" metsPointerPathAnchor="" metsPurl="" metsContentIDs="" metsRightsSponsor="" metsRightsSponsorLogo="" metsRightsSponsorSiteURL="" metsRightsLicense="" />

        <docket name="example docket">
            <newDocketName>first docket</newDocketName>

        <ruleset name="example ruleset">
            <newRulesetName>default ruleset</newRulesetName>

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

        <usergroup name="Administration">

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

In this configuration file all fields are optional. If a field is missing, its value is not overwritten during configuration. If the field is empty, it will be imported empty, otherwise it will be overwritten with the value from this configuration file. The fields for adding or removing are basically repeatable.

2.4 Configuration for the import of data

To import the data to the target system, you can specify in the configuration file plugin_intranda_administration_goobi2goobi_import_infrastructure.xml where the data is located and how it should be processed during the import. This configuration can look like the following example:

<?xml version="1.0"?>
        <rulename>Project A</rulename>
        <rulename>Project B</rulename>
        <step name="Example to delete" type="delete" />
        <step name="Example to change" type="change">
            <newStepName>New step name</newStepName>
            <types metadata="true" automatic="false" readImages="false" writeImages="false" export="false" validateOnExit="true" finalizeOnAccept="false" delayStep="false" updateMetadataIndex="false" generateDocket="false" batchStep="false" stepPlugin="" validationPlugin="" />
            <scriptStep scriptStep="true" scriptName1="script 1" scriptPath1="/bin/bash ..." scriptName2="" scriptPath2="" scriptName3="" scriptPath3="" scriptName4="" scriptPath4="" scriptName5="" scriptPath5="" />
            <httpStep httpStep="true" httpMethod="POST" httpUrl="" httpJsonBody="{ .... } " httpCloseStep="false" />
        <step name="Example to change" type="insertAfter" >
            <newStepName>Export task</newStepName>
            <types automatic="true" export="true" stepPlugin="special_export_plugin" />
        <docket name="Default docket">
        <project name="Project A">
            <newProjectName>Project B</newProjectName>
        <property name="CollectionName">
        <ruleset name="Default">
            <newRulesetName>default ruleset</newRulesetName>
        <metadata name="CatalogIDDigital" type="change">
        <metadata name="PhysicalLocation" type="delete">
        <metadata name="Testmetatda" type="add">
            <valueReplacementRegex>example text</valueReplacementRegex>

In the upper part of the file, some general settings are made that apply to all imports. These general settings are followed by the individual configured rules.

General settings: globalConfig




This specification is required if the database information to be imported is not located as xml files in the respective process folder. The specification contains the path to the database information within an s3 bucket and is not required when importing into a local file system.



Target directory into which the data is to be imported.



Name of the s3-bucket in which the data to be imported is located. This value is not required for imports into a local file system.



This parameter defines whether the process identifiers from the old system should be reused or whether new IDs should be created.



This parameter specifies the path to the folder containing the data to be imported. The value only needs to be configured if it differs from the value within importPath.

The individual rules for the import operations will be defined within the <config> element. The name of the rule is defined in <rulename>. If no rule is explicitly selected during the import, it will be determined by the project name of the processes. The field is repeatable, so that several identical rules can be created, for example if the same workflow is used in different projects.

Workflow steps within the workflows: step

By means of <step> individual steps of the process can be manipulated. All fields are optional. If they are not specified, the original value is used. Otherwise the field is overwritten with the configured field content. If the field is of type String, it can also be specified empty to empty it.



Example task

Contains the name of the step to be changed.



This value contains the type of manipulation. Possible values are delete, change, insertBefore, insertAfter.


New step name

New name of the step.



New priority of the step.



Order of the step.



Controls whether to link to the user's home directory.



Sets the step status. Allowed values are 0 (locked), 1 (open), 2 (inwork), 3 (done), 4 (error) and 5 (deactivated).



Contains in attributes the different settings of a step.


scriptStep="true" scriptName1="script 1" scriptPath1="/bin/true"

Defines scripts for the workflow steps


httpStep="true" httpMethod="POST" httpUrl=""

Defines the configuration of the HTTP call for the step.



Name of the assigned user group. This value can be repeated to define multiple user groups.

Docket: docket

In this element, the assigned docket can be replaced. The xsl file to be used must exist on the server. If a docket has already been defined with the new specifications, it will be used, otherwise a new docket will be defined and stored in the database.



Default docket

Name of the previously used docket. The change is only made if the process has previously used a docket with this name.



New name of the ticket.



New file name for the docket.

Project: project

This rule can be used to change the assigned project. The project must already exist. Changes to the projects themselves can be made using Import infrastructure.

| Element | Example | Meaning | | :--- | :--- | :— | | @name | | Project A | Old Project | | | newProjectName | Project B | New Project |

Properties: property

This rule is used to manipulate process properties.

| Element | Example | Meaning | | :--- | :--- | :— | | @name | CollectionName | Name of the property to be adjusted. | | oldPropertyValue | Digitised | Value of the property to be adjusted. If a value is specified, the property must contain this value. | | newPropertyName | Collection | New name of the property. Optional. | | newPropertyValue | default collection | New value of the property. Optional. |

Ruleset: ruleset

This rule can be used to change the assigned rule set. If the ruleset does not yet exist, it is created and saved in the database. The file must exist on the server.

| Element | Example | Meaning | | :--- | :--- | :— | | @name | Default | Name of the ruleset used so far. | | newRulesetName | default ruleset | New name for the ruleset. | | newFileName | ruleset.xml | New file name for the ruleset. This must exist on the target system. |

Metadata: metadata

With this rule the metadata can be changed. Values of existing metadata can be changed, new metadata added or existing metadata deleted.




Internal name of the metadata.



Type of change. Allowed values are add, change and delete.



Describes the position at which the change is to be made. Allowed values are all, anchor, top and physical.



This regular expression checks whether the previous field content matches a defined value. This specification can be a fixed value or a regular expression.



If the value change was used as @type, this parameter contains a regular expression for manipulating the previous metadata. If @type is set to add, the field content is used as the value of the metadata.

Further configurations

Further general settings can be defined within a rule.




Determines whether the process log of the source system should be transferred (false) or ignored (true).



Specifies whether the users of imported tasks in a workflow within Goobi should be created as deleted users (false) or whether the information about execution by specific persons should be ignored and thus made anonymous. (true).

Last updated