Old: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

1. Create a subclass of AutoWorkflowProcessor, overriding the following abstract methods
   • canProcessClaimedTask() - return true if your subclass can process the task. For example, AutoApproveBlackoutProcessor checks the blackoutUntilDate 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).
2. 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 the DummyApproveFromBlackoutRequest provides values that mimic a user clicking Approve with Blackout.

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.

See Also

• Submission System Technology