Automatic Workflow Processing Technology
This page describes a suite of classes, command-line-tools, configurations, and tests that programatically move Dryad submissions through the workflow steps and actions.
Overview
Normally, workflow operations are executed by curators clicking buttons in the UI (Approve item, send to blackout, etc). There is a need to automate some of these steps. For example, items in publication blackout can be released into the archive automatically once their associated article is published.
Workflow - Technical Background
The Dryad workflow is a set of steps and actions that compose the curation and review spaces. When a submitter submits a data package to Dryad, it leaves their Workspace and enters the Workflow. The workflow determines how the item moves from submission to archival, if the item goes into review or directly into curation, whether the curator is prompted to send it to blackout, etc. See Submission System Workflow for details on the workflow.
The workflow is defined by the steps/actions in workflow.xml and workflow-actions.xml. The actions defined here are classes that are instantiated and run by the WorkflowManager.java. WorkflowFactory.java, reads the XML files to build a workflow.
Automating Workflow
In order to automate the workflow, this feature introduces configurations and classes to drive the WorkflowManager.
Configuration Changes
This feature moves items through the workflow, as a human curator would. Therefore, the actions should be attributable to a user account, and the user account must have permissions to perform the actions.
This requirement is addressed by creating a System Curator Account and naming that account (by email address) in the workflow configuration (e.g. /opt/dryad/config/modules/workflow.cfg
).
Since the Dryad config files are assembled by the build process, deployments will expect this email address in your Maven Profile (settings.xml
):
<profile> <id>env-dev</id> <properties> ... <!-- System curator account --> <default.system.curator.account>system.curator@datadryad.org</default.system.curator.account> </properties> </profile>
Command-Line interfaces
This feature exposes its functionality to command-line interfaces:
ApproveBlackoutItems
Run without any arguments, this class will find all items currently in Publication Blackout (pendingPublicationStep
or pendingPublicationReauthorizationPaymentStep
) with a dc.date.blackoutUntil
date in the past, and approve them into the archive.
$ /opt/dryad/bin/dsrun org.dspace.workflow.ApproveBlackoutItems
AutoApproveBlackoutProcessor
Run with a single argument (the workflowitem
id) see , this class will attempt to approve the item into the archive from blackout. It will fail if the item is not in blackout or if it is missing the dc.date.blackoutUntil
field, or if said date is in the future.
$ /opt/dryad/bin/dsrun org.dspace.workflow.AutoApproveBlackoutProcessor -i <WFID>
AutoCurateToBlackoutProcessor
Run with a single argument (the workflowitem
id) see , this class will attempt to approve the item from curation dryadAcceptEditReject
into publication blackout. It will fail if the item is not in curation. This class was created primarily for testing purposes - so that an item could be sent to blackout and then approved from it.
$ /opt/dryad/bin/dsrun AutoCurateToBlackoutProcessor -i <WFID>
Programmatic Interface (Classes)
For concrete examples using these classes, see AutoApproveBlackoutProcessorTest.java
The concrete classes that perform workflow steps are all based on AutoWorkflowProcessor
, an abstract class. To use them programatically, you need only a workflow item:
WorkflowItem wfi = WorkflowItem.findByItemId(); AutoCurateToBlackoutProcessor curateToBlackoutProcessor = new AutoCurateToBlackoutProcessor(context); Boolean curatedToBlackout = curateToBlackoutProcessor.processWorkflowItem(wfi);
Subclassing
To create additional processors that move between steps, you should
- Create a subclass of
AutoWorkflowProcessor
, overriding the following abstract methods- canProcessClaimedTask() - return
true
if your subclass can process the task. For example, AutoApproveBlackoutProcessor checks theblackoutUntilDate
in this method and returns false if it is in the future or does not exist - isMyStep() - return
true
if your processor is designed to handle items in the current workflowStep - getActionId() - return the name of the action your processor is designed to execute
- getRequest() - return an
HttpServletRequest
with parameters simulating user actions (e.g. button values in POSTed form).
- canProcessClaimedTask() - return
- Create a subclass of
DummyHttpServlet
, overriding getParameters()- getParameters() should return a
Map<String,String>
of parameters that would be set when the user clicks a button in the curation interface. - For example. see AfterPublicationAction.java and DummyApproveFromBlackoutRequest.java.
AfterPublicationAction
(and its parent class) looks for specific parameter values in the request to determine if the user clicked Approve with Blackout or not. So theDummyApproveFromBlackoutRequest
provides values that mimic a user clicking Approve with Blackout.
- getParameters() should return a
Again, consult the existing examples as prototypes of how to build your subclasses.
Testing
This feature includes a single test class that tests both concrete implementations of AutoWorkflowProcessor
: AutoApproveBlackoutProcessorTest. It includes test cases that create items in the workflow using the DryadDataPackage class, and attempts various automatic workflow processes that are expected to succeed or fail.
The test framework does not drive the UI to submit a data package, it creates Dryad objects with minimal metadata and ushers them through the workflow. For example, while the workflow includes steps to process payment, the test always configures the shopping cart with a journal subscription, so the payment-processing parts of the workflow are not encountered.
Environment Changes
The Travis CI build scripts and Vagrant provisioning scripts have been updated to include the necessary configurations when executing the tests.
Since the test environment now loads the workflow, the skeleton test environment has been updated to include symlinks to the workflow xml files and emails directory. Additionally, since the workflow instantiates the payment system actions, the payment-system.cfg is included.