Changing the workflow based on process properties
This is the technical documentation for the Goobi plugin for automatically modifying workflows based on task properties.

Introduction

This documentation describes the installation, configuration and use of a plugin for automatically changing workflows at runtime. The plugin can open, close or deactivate (depending on configuration) steps. User groups can be assigned and production templates can also be completely exchanged. The decision as to what exactly should happen in each case is made on the basis of process properties.
Details
Identifier
intranda_step_changeWorkflow
Licence
GPL 2.0 or newer
Compatibility
Goobi workflow 2021.03
Documentation date
22.09.2021

Precondition

The precondition for using the plugin is the use of Goobi workflow in version 3.0.0 or higher, the correct installation and configuration of the plugin as well as the correct integration of the plugin into the desired workflow steps.

Installation and Configuration

To use the plugin, it must be copied to the following location:
1
/opt/digiverso/goobi/plugins/step/plugin_intranda_step_changeWorkflow.jar
Copied!
The configuration of the plugin is expected under the following path:
1
/opt/digiverso/goobi/config/plugin_intranda_step_changeWorkflow.xml
Copied!
The following is a sample configuration with comments:
1
<config_plugin>
2
<!--
3
order of configuration is:
4
1.) project name and step name matches
5
2.) step name matches and project is *
6
3.) project name matches and step name is *
7
4.) project name and step name are *
8
-->
9
10
<config>
11
<!-- which projects to use for (can be more then one, otherwise use *) -->
12
<project>Register</project>
13
<step>Check</step>
14
15
<!-- multiple changes can be done within one configuration rule; simply add another 'change' element with other properties here -->
16
<change>
17
<!-- name of the property or metadata to check: please take care to use the syntax of the Variable replacer here -->
18
<propertyName>{process.TemplateID}</propertyName>
19
<!-- expected value (can be blank too) -->
20
<propertyValue>183</propertyValue>
21
<!-- condition for value comparing, can be 'is' or 'not' or 'missing' or 'available' -->
22
<propertyCondition>is</propertyCondition>
23
<!-- list of steps to open, if property value matches -->
24
<steps type="open">
25
<title>Box preparation</title>
26
</steps>
27
<!-- list of steps to deactivate -->
28
<steps type="deactivate">
29
<title>Image QA</title>
30
</steps>
31
<!-- list of steps to close -->
32
<steps type="close">
33
<title>Automatic LayoutWizzard Cropping</title>
34
<title>LayoutWizzard: Manual confirmation</title>
35
</steps>
36
<!-- list of steps to lock -->
37
<steps type="lock">
38
<title>Automatic export to Islandora</title>
39
</steps>
40
41
<usergroups step="Image QA">
42
<usergroup>Administration</usergroup>
43
<usergroup>AutomaticTasks</usergroup>
44
</usergroups>
45
</change>
46
</config>
47
48
<config>
49
<!-- which projects to use for (can be more then one, otherwise use *) -->
50
<project>*</project>
51
<step>*</step>
52
53
<!-- multiple changes can be done within one configuration rule; simply add another 'change' element with other properties here -->
54
<change>
55
<!-- name of the property or metadata to check: please take care to use the syntax of the Variable replacer here -->
56
<propertyName>{process.upload to digitool}</propertyName>
57
<!-- expected value (can be blank too) -->
58
<propertyValue>No</propertyValue>
59
<!-- condition for value comparing, can be 'is' or 'not' or 'missing' or 'available' -->
60
<propertyCondition>is</propertyCondition>
61
<!-- list of steps to open, if property value matches -->
62
<steps type="open">
63
<title>Create derivates</title>
64
<title>Jpeg 2000 generation and validation</title>
65
</steps>
66
<!-- list of steps to deactivate -->
67
<steps type="deactivate">
68
<title>Rename files</title>
69
</steps>
70
<!-- list of steps to close -->
71
<steps type="close">
72
<title>Upload raw tiffs to uploaddirectory Socrates</title>
73
<title>Automatic pagination</title>
74
</steps>
75
<!-- list of steps to lock -->
76
<steps type="lock">
77
<title>Create METS file</title>
78
<title>Ingest into DigiTool</title>
79
</steps>
80
</change>
81
</config>
82
83
<config>
84
<!-- which projects to use for (can be more then one, otherwise use *) -->
85
<project>Archive_Project</project>
86
<step>Check process template change</step>
87
88
<!-- multiple changes can be done within one configuration rule; simply add another 'change' element with other properties here -->
89
<change>
90
<!-- name of the property or metadata to check: please take care to use the syntax of the Variable replacer here -->
91
<propertyName>{process.TemplateID}</propertyName>
92
<!-- expected value (can be blank too) -->
93
<propertyValue>309919</propertyValue>
94
<!-- condition for value comparing, can be 'is' or 'not' or 'missing' or 'available' -->
95
<propertyCondition>is</propertyCondition>
96
<!-- Name of the new process template -->
97
<workflow>Manuscript workflow</workflow>
98
</change>
99
</config>
100
</config_plugin>
Copied!
Each config block is responsible for a certain project and a certain step, whereby wildcards * and multiple answers of processes or steps are also possible. If a step in the workflow is executed with this plugin, the system searches for a config block that matches the currently opened step. For example, if in the project "PDF Digitization" the step with the title "Change workflow after PDF extraction" is configured and executed with this plugin, the plugin looks for a config block that looks like this:
1
<config>
2
<project>PDF Digitization</project>
3
<step>Change workflow after PDF extraction</step>
4
[...]
5
</config>
Copied!
In each <change> element it is then configured which process property is checked (<propertyName>) and which value is expected (<propertyValue>). Please note that the specification for defining which property is to be used for checking a value must be specified with the syntax for the so-called variable replacer. Accordingly, when defining the field to be checked, the specification must be as in the following examples:
1
<propertyName>{process.ABC}</propertyName>
2
<propertyName>{{meta.ABC}}</propertyName>
3
<propertyName>{meta.topstruct.ABC}</propertyName>
4
<propertyName>{meta.firstchild.ABC}</propertyName>
5
<propertyName>{db_meta.ABC}</propertyName>
Copied!
Further explanations about the use of variables can be found here:
8. Variables
Goobi workflow (English)
https://docs.goobi.io/goobi-workflow-en/manager/8
After defining how the properties are to be evaluated, the action to be performed is determined. The following possibilities exist here:

Changing the status of workflow steps.

Depending on existing properties, the status of defined steps within the workflow can be changed automatically. Workflow steps can be opened type="open", deactivated type="deactivate", closed type="close" or locked type="lock".
1
<steps type="open">
2
<title>Create derivates</title>
3
<title>Jpeg 2000 generation and validation</title>
4
</steps>
5
<steps type="deactivate">
6
<title>Rename files</title>
7
</steps>
8
<steps type="close">
9
<title>Upload raw tiffs to uploaddirectory Socrates</title>
10
<title>Automatic pagination</title>
11
</steps>
12
<steps type="lock">
13
<title>Create METS file</title>
14
<title>Ingest into DigiTool</title>
15
</steps>
Copied!
Parameter
Explanation
type
Determine which status the workflow steps are to receive.
title
Define here the name of the workflow steps that are to be set to the desired status.

Changing the responsibility of user groups for workflow steps

Depending on existing properties, the responsible user groups can be defined for several workflow steps. The configuration is done as shown here:
1
<usergroups step="Image QA">
2
<usergroup>Administration</usergroup>
3
<usergroup>AutomaticTasks</usergroup>
4
</usergroups>
Copied!
Parameter
Explanation
step
Determine for which workflow step you want to enter the user groups.
usergroup
Define here the name of the user group that is to be entered as responsible for the configured step.

Changing the process template on which the process is based

With a configuration like the following example, the process template can be exchanged while the workflow is running. Depending on existing properties, a workflow can thus be replaced by another workflow during execution. Workflow steps that are also present in the new workflow are automatically set to the correct status.
1
<workflow>Manuscript workflow</workflow>
Copied!
Parameter
Explanation
workflow
Define here the name of the process template to be used for the process.

Settings in Goobi

After the plugin has been installed and configured, it can be configured in the user interface in a workflow step. Make sure that the name of the step is the same as in the configuration file. In addition, a check mark should be set for Automatic task.
Configuration of the Workflow step

Usage

Since the plugin should run fully automatically, there is nothing else to consider for the use of the plugin.
Last modified 3mo ago