Hi Stian, Alan,

reply is in line:

> (No need to cc support@mygrid, we're all no dev@taverna :)

Sorry :)

> Perhaps valuable would be some kind of --fail-on-any-error option to
> executeworkflow?  This could then be enabled in the server.  It could
> bail out as soon as an error document appears at an output port.

Yes, I am interested in a option like the --fail-on-any-error that when an 
activity tool fails the executeworkflow.sh fails too
and the exit code of the activity is propagated to the exitcode of the 
executeworkflow.

How can I set this option in taverna server 2.5? Using the admin panel?

Best regards,

Simone.


-----

(No need to cc support@mygrid, we're all no dev@taverna :)

The exit code from Taverna server reflects the exit code from
executeworkflow.sh - which would be 0 unless the workflow engine
itself failed. (e.g. the t2flow used a plugin that was not installed
on the server, or a file was not found)

The exit code of a individual tool within the workflow does not cause
the workflow to fail, but rather it will propagate "Error Documents"
on its outputs. Anything 'below' in the workflow expecting this value
will then in turn produce derived Error Documents. This means that if
the errror was within a list iteration, only that element of the list
(and subsequent iterations) are replaced with errors.


Similarly, the stdout and stderr of the individual tool (of which many
could be running concurrently) is captured by the workflow engine and
thus not shown in the stdout or stderr REST resources of the Server's
executeworkflow execution.


I just check the Tool Activity, and here it waits for the exit code:

https://github.com/apache/incubator-taverna-common-activities/blob/master/taverna-external-tool-activity/src/main/java/org/apache/taverna/activities/externaltool/local/LocalToolInvocation.java#L384

You see it will provide the STDERR output as part of the exception
(which then goes into the error document).

It's configurable to allow certain exit codes, but this is not exposed
in the UI.

(Not so sure about that UnsupportedEncodingException handling there.. )


Perhaps valuable would be some kind of --fail-on-any-error option to
executeworkflow?  This could then be enabled in the server.  It could
bail out as soon as an error document appears at an output port.


-- 
Simone Bnà, PhD
C++ Software Developer, CINECA
Via Magnanelli 6/3, 40033 Casalecchio di Reno, Italy
office:   +39-0516171938
email: s....@scsitaly.com/s...@cineca.it

Reply via email to