Use case

ONDEX

Reference	Userreq.OnDex
High-level reqs	ApiSep VersionLogging CheckPoints ErrorReporting ParamaterDescriptions DefaultParameterValues ServiceAnnotation ComplexEvents
Proposed by	ONDEX

	Taverna 1.3	Taverna 2.0
Priority

Overview

ONDEX is a system for integrating and visualising biological data

Overall Goals

To enable the integration of Taverna workflows into the ONDEX system

Required services

Client-server architecture At the moment it seems to be necessary when starting a workflow that the Taverna GUI has to stay open on the client machine the whole time. It would be nice to have a workflow execution which is GUI independent, so you can start the GUI for the initiation of a workflow, then close the GUI and restart it later on with the workflow being executed on the server in the meantime

Error handling (defined by user) + error reporting We would like to see an extended error handling. Processors should (optionally) be enabled to report errors/exceptions which they encounter whilst being executed to the workflow engine. Such errors should probably be classified into error classes, so that processes can classify the severity of errors, and so that the workflow engine/taverna can respond to such errors in an appropriate way depending on the severity of the errors. Taverna/freefluo should respond to the occurrence of such errors in predefined ways: - pause workflow and wait for user interaction - users can predefine error classes which should be ignored without stopping the workflow - users can predefine which errors should stop the workflow execution completely

The web services should (optionally) be able to report the parameters that can/need to be set to configure the processor. Processors should also be enabled to suggest sensible default values and to report whether or not a field is optional or required. Taverna should then exploit this information, to generate fields that users can use to configure the processors via the taverna GUI.

Additional methods So far, a workflow can only be paused after a processor has finished completely. We suggest extending the processor interface with the following (optional) methods: - cancel (important) - pause (not so important) - resume (not so important) - rollback (not so important)

Logging In order to make it easier to reproduce a workflow later on, or to track down reasons why two seemingly identical workflow runs produced different results, Taverna should log the versions of the processes that were used for each work flow run. It should be possible to define additional data to be logged for each processor, e.g. statistics on the results, which can be derived by the workflow engine from the processor via a suitable interface.

Workflow outline

no data

Appendix