The Fail_if_true and Fail_if_false processors, available under Available processors > Local services -> Local Java widgets -> conditional, have the functionality that they fail if the input is “true” or “false”, respectively. This can be combined with a “Coordinate from” on another processor that would then only run if the Fail_if… processor succeeds, i.e. does not fail (effectively branching the workflow).
In addition, a nested workflow can use the Fail_if… processors set as Critical and thereby conditionally fail the whole nested workflow. This combined with a retry policy for the nested workflow in the wrapping workflow can be used for typical ‘Wait until service says X’ loops, such as job submission systems.
The way these processors are implemented is simply to fail on purpose if the input condition matches. However, this means that a stack trace will be printed from the enactment engine every time a processor like this fails. Note that this does not neccessarily mean that the workflow failed. In fact, that part of the workflow is probably designed to fail.
We have still marked this as a bug, TAV-479, since we should not be outputting stack traces unless there is an actual error.
In Taverna 2.x, there are no service equivalents to Fail_if… processors from Taverna 1.x. Taverna 2.x has a looping functionality that can help with job submission type services, where the workflow execution waits until a submitted job has finished so there is no need to resort to failing processors. Branching as a kind of control logic may be implemented post 2.1, but at the moment there are no fixed plans as to when this will happen.
