Page History

...

...

 [dspace]/config/xmlui.xconf

The submission aspect has been split up into muliple aspects: one submission aspect for the submission process, one workflow aspect containing the code for the original workflow and one xmlworkflow aspect containing the code for the new XML configurable workflow framework. In order to enable one of the two aspects, either the workflow or xmlworkflow aspect should be enabled in the [dspace]/config/xmlui.xconf configuration file. This means that the xmlui.xconf configuration for the original workflow is the following:

...

<aspect name="Submission and Workflow" path="resource://aspects/Submission/" />
<aspect name="XMLWorkflow" path="resource://aspects/XMLWorkflow/" />

[dspace]/config/

...

spring/api/core-services.xml

You also have to configure DSpace to load the right services. This is done by commenting the basic workflow services and uncommenting the xmlworkflow services Besides that, a workflow configuration file has been created that specifies the workflow that will be used in the back-end of the DSpace code. It is important that the option selected in this configuration file matches the aspect that was enabled. The workflow configuration file is available in [dspace]/config/modules/workflow.cfg. This configuration file has been added because it is important that a CLI import process uses the correct workflow and this should not depend on the UI configuration. The workflow.cfg configration file contains the following property:

# Original Workflow
#workflow.framework: originalworkflow
#XML configurable workflow
workflow.framework: xmlworkflow

dspace/config/spring/api/core-services.xml

You also have to configure DSpace to load the right services. This is done by commenting the basic workflow services and uncommenting the xmlworkflow services in [dspace]/config/spring/api/core-services.xml. After enabling the configurable workflow the mentioned file should contain the following:

spring/api/core-services.xml. After enabling the configurable workflow the mentioned file should contain the following:

    <!--Basic workflow services, comment or remove when switching to the configurable workflow -->
    <!--
    <bean class="org.dspace.workflowbasic.TaskListItemServiceImpl"/>
    <bean 

    <!--Basic workflow services, comment or remove when switching to the configurable workflow -->
    <!--
    <bean class="org.dspace.workflowbasic.TaskListItemServiceImplBasicWorkflowItemServiceImpl"/>
    <bean class="org.dspace.workflowbasic.BasicWorkflowItemServiceImplBasicWorkflowServiceImpl"/>
    <bean class="org.dspace.workflowbasic.BasicWorkflowServiceImpl"/>
    -->

-->

    <!--Configurable workflow services, uncomment the xml workflow beans below to enable the configurable workflow-->
    <bean class="org.dspace.xmlworkflow.storedcomponents.ClaimedTaskServiceImpl"/>
    <bean class="org.dspace.xmlworkflow.storedcomponents.CollectionRoleServiceImpl"/>
    <bean class="org.dspace.xmlworkflow.storedcomponents.InProgressUserServiceImpl"/>
    <bean class="org.dspace.xmlworkflow.storedcomponents.PoolTaskServiceImpl"/>
    <bean class="org.dspace.xmlworkflow.storedcomponents.WorkflowItemRoleServiceImpl"/>
    <bean class="org.dspace.xmlworkflow.storedcomponents.XmlWorkflowItemServiceImpl"/>
    <bean class="org.dspace.xmlworkflow.XmlWorkflowServiceImpl"/>
    <bean class="org.dspace.xmlworkflow.WorkflowRequirementsServiceImpl"/>
    <bean class="org.dspace.xmlworkflow.XmlWorkflowFactoryImpl"/>

...

[dspace]/config/spring/api/core-factory-services.xml

<!--Basic workflow services, comment or remove when switching to the configurable workflow -->
<!--<bean id="workflowServiceFactory" class="org.dspace.workflowbasic.factory.BasicWorkflowServiceFactoryImpl"/>-->
<!--Configurable workflow services, uncomment to enable-->
<bean id="workflowServiceFactory" class="org.dspace.xmlworkflow.factory.XmlWorkflowServiceFactoryImpl"/>

<!--<mapping class="org.dspace.workflowbasic.BasicWorkflowItem"/>-->
<!--<mapping class="org.dspace.workflowbasic.TaskListItem"/>-->
<mapping class="org.dspace.xmlworkflow.storedcomponents.ClaimedTask"/>
<mapping class="org.dspace.xmlworkflow.storedcomponents.CollectionRole"/>
<mapping class="org.dspace.xmlworkflow.storedcomponents.InProgressUser"/>
<mapping class="org.dspace.xmlworkflow.storedcomponents.PoolTask"/>
<mapping class="org.dspace.xmlworkflow.storedcomponents.WorkflowItemRole"/>
<mapping class="org.dspace.xmlworkflow.storedcomponents.XmlWorkflowItem"/>

...

Workflowitem conversion/migration scripts

Depending on the workflow that is used by a DSpace installation, different scripts can be used when migrating to the new workflow.

Automatic migration

Automatic migration can be used when the out of the box original workflow framework is used by your DSpace installation. This means that your DSpace installation uses the workflow steps and roles that are available out of the box. The automated migration will migrate the policies, roles, tasks and workflowitems from the original workflow to the new workflow framework.

This process will occur automatically by simply restarting Tomcat (or your servlet container) after enabling "xmlworkflow" in the workflow.cfg.

You can also choose to manually kick off this migration by simply running:

[dspace]/bin/dspace database migrate

For more information on the "database migrate" command, please see Database Utilities.

Java based migration

In case your DSpace installation uses a customized version of the workflow, the migration script might not work properly and a different approach is recommended. Therefore, an additional Java based script has been created that restarts the workflow for all the workflowitems that exist in the original workflow framework. The script will take all the existing workflowitems and place them in the first step of the XML configurable workflow framework thereby taking into account the XML configuration that exists at that time for the collection to which the item has been submitted. This script can also be used to restart the workflow for workflowitems in the original workflow but not to restart the workflow for items in the XML configurable workflow.

To execute the script, run the following CLI command:

[dspace]/bin/dspace dsrun org.dspace.xmlworkflow.migration.RestartWorkflow -e admin@myrespository.org

The following arguments can be specified when running the script:

• -e: specifies the username of an administrator user
• -n: if sending submissions through the workflow, send notification emails
• -p: the provenance description to be added to the item
• -h: help

Configuration

DSpace.cfg configuration

The workflow configuration file is available in  [dspace]/config/modules/workflow.cfg . This configuration file has been added because it is important that a CLI import process uses the correct workflow and this should not depend on the UI configuration. The workflow.cfg configration file contains the following property:

# Original Workflow
#workflow.framework: originalworkflow
#XML configurable workflow
workflow.framework: xmlworkflow

...

Workflowitem conversion/migration scripts

Depending on the workflow that is used by a DSpace installation, different scripts can be used when migrating to the new workflow.

Automatic migration

Automatic migration can be used when the out of the box original workflow framework is used by your DSpace installation. This means that your DSpace installation uses the workflow steps and roles that are available out of the box. The automated migration will migrate the policies, roles, tasks and workflowitems from the original workflow to the new workflow framework.

Manually kick off this migration by simply running:

[dspace]/bin/dspace database migrate ignored

The "ignored" parameter will tell DSpace to run any previously-ignored migrations on your database.  After enabling Configurable Workflow in your Spring configs (see above), the new automatic migrations will be made available to the "database migrate" command. As these new migrations were not previously run by "database migrate", they will be "ignored" until you trigger them by manually running the above command.

For more information on the "database migrate" command, please see Database Utilities.

Java based migration

In case your DSpace installation uses a customized version of the workflow, the migration script might not work properly and a different approach is recommended. Therefore, an additional Java based script has been created that restarts the workflow for all the workflowitems that exist in the original workflow framework. The script will take all the existing workflowitems and place them in the first step of the XML configurable workflow framework thereby taking into account the XML configuration that exists at that time for the collection to which the item has been submitted. This script can also be used to restart the workflow for workflowitems in the original workflow but not to restart the workflow for items in the XML configurable workflow.

To execute the script, run the following CLI command:

[dspace]/bin/dspace dsrun org.dspace.xmlworkflow.migration.RestartWorkflow -e admin@myrespository.org

The following arguments can be specified when running the script:

• -e: specifies the username of an administrator user
• -n: if sending submissions through the workflow, send notification emails
• -p: the provenance description to be added to the item
• -h: help

Configuration

Main workflow configuration

...

• id: a unique identifier (in one workflow process) for the role
• description: optional attribute to describe the role
• scope: optional attrbiute attribute that is used to find our group and must have one of the following values:
  • collection: The collection value specifies that the group will be configured at the level of the collection. This type of groups is the same as the type that existed in the original workflow system.  In case no value is specified for the scope attribute, the workflow framework assumes the role is a collection role.
  • repository: The repository scope uses groups that are defined at repository level in DSpace. The name attribute should exactly match the name of a group in DSpace.
  • item: The item scope assumes that a different action in the workflow will assign a number of EPersons or Groups to a specific workflow-item in order to perform a step. These assignees can be different for each workflow item.
• name: The name specified in the name attribute of a role will be used to lookup the an eperson group in DSpace. The lookup will depend on the scope specified in the "scope" attribute:
  • collection: The workflow framework will look for a group containing the name specified in the name attribute and the ID of the collection for which this role is used.
  • repository: The workflow framework will look for a group with the same name as the name specified in the name attribute
  • item: in case the item scope is selected, the name of the role attribute is not required
• internal: optional attribute which isn't really used at the moment, false by default

<roles>
    <role id="{unique.role.id}" description="{role.description}" scope="{role.scope}" name="{role.name}" internal="true/false"/>
</roles>

...

The configuration file for the workflow user interface actions is located in the [dspace]/config/spring/xmlui/ and is named "workflow-actions-xmlui.xml". BEach   Each bean defined here has an id which is the action identifier and the class is a classpath which links to the xmlui class responsible for generating the User Interface side of the workflow action. Each of the class defined here must extend the org.dspace.app.xmlui.aspect.submission.workflow.AbstractXMLUIAction class, this class contains some basic settings for an action and has a method called addWorkflowItemInformation() which will render the given item with a show full link so you don't have to write the same code in each of your actions if you want to display the item. The id attribute used for the beans in the configuration must correspond to the id used in the workflow configuration. In case an action requires a User Interface class, the workflow framework will look for a UI class in this configuration file.

...

• ScoreReviewStep: The group of responsible users for the score reviewing will be able to claim the task from the taskpool. Dependingn on the configuration, a different number of users can be required to execute the task. This means that the task will be available in the task pool until the required number of users has at least claimed the task. Once everyone of them has finished the task, the next (automatic) processing step is activated.
• EvaluationStep: During the evaluationstep, no user interface is required. The workflow system will automatically execute the step that evaluates the different scores. In case the average score is more than a configurable percentage, the item is approved, otherwise it is rejected.  (The minimum average score is set by adjusting the minimumAcceptanceScore property passed to evaluationactionAPI in config/spring/api/workflow-actions.xml.)

Workflow overview features

...