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.
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.
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.
To enable the user to export data, the user must have the following roles:
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.
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.
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.
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.
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.
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
dbExportPrefix
import/
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.
importPath
/opt/digiverso/goobi/metadata/
Target directory into which the data is to be imported.
bucket
example-workflow-data
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.
createNewProcessIds
false
This parameter defines whether the process identifiers from the old system should be reused or whether new IDs should be created.
temporaryImportFolder
/opt/digiverso/transfer/
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.
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.
@name
Example task
Contains the name of the step to be changed.
@type
delete
This value contains the type of manipulation. Possible values are delete, change, insertBefore, insertAfter.
NewStepName
New step name
New name of the step.
priority
5
New priority of the step.
order
10
Order of the step.
useHomeDirectory
0
Controls whether to link to the user's home directory.
stepStatus
0
Sets the step status. Allowed values are 0 (locked), 1 (open), 2 (inwork), 3 (done), 4 (error) and 5 (deactivated).
types
automatic="true"
Contains in attributes the different settings of a step.
scriptStep
scriptStep="true" scriptName1="script 1" scriptPath1="/bin/true"
Defines scripts for the workflow steps
httpStep
httpStep="true" httpMethod="POST" httpUrl="http://itm.example.com/itm/service"
Defines the configuration of the HTTP call for the step.
usergroup
Administration
Name of the assigned user group. This value can be repeated to define multiple user groups.
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.
@name
Default docket
Name of the previously used docket. The change is only made if the process has previously used a docket with this name.
newDocketName
docket
New name of the ticket.
newFileName
docket.xsl
New file name for the docket.
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 |
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. |
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. |
With this rule the metadata can be changed. Values of existing metadata can be changed, new metadata added or existing metadata deleted.
@name
CatalogIDDigital
Internal name of the metadata.
@type
change
Type of change. Allowed values are add, change and delete.
position
top
Describes the position at which the change is to be made. Allowed values are all, anchor, top and physical.
valueConditionRegex
/PPN\d+\w?(?:_\d+)?/
This regular expression checks whether the previous field content matches a defined value. This specification can be a fixed value or a regular expression.
valueReplacementRegex
s/^PPN(.+)$/$1/g
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 general settings can be defined within a rule.
skipProcesslog
true
Determines whether the process log of the source system should be transferred (false) or ignored (true).
skipUserImport
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).
