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
Plugin_goobi2goobi_export
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:
Plugin_goobi2goobi_import
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:
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:
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
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.
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.
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.
Further configurations
Further general settings can be defined within a rule.