Conditional branching is the term used to describe the set of operations such as 'if <condition> do <something> else do <something else>' and the various case and switch statements in conventional imperative languages such as C, PERL and Java. Taverna's language representation differs in some crucial ways from these languages so the representation of conditionals is different, the functionality, however, is equivalent.
Conditionals are driven by the control links within the workflow. As a process can only run when all upstream links, data and control, are satisfied it is possible to construct workflows where only a subset of the available downstream processors can run and where the others are left in the scheduled state. Effectively those chosen to run are in the 'true' branch of the conditional and those left scheduled in the 'false' branch.
In a workflow without any conditional structures it is recommended to avoid having the case where more than one output feeds into a single input. The behaviour in this case is to accept the first available input, removing any other data links in the process. If the workflow system did not remove the alternative links the processor would never run, these links would be detected and the processor would wait until they had all been satisfied - obviously if the processor upstream has been left in a scheduled state the link will never be used and the workflow will stall.
As an example consider the following workflow (held in the examples directory as 'ConditionalBranchChoice.xml'):
The single input to this workflow is a string containing the value 'true' or the value 'false'. The two processors 'foo' and 'bar' are string constants which emit the stereotypical example string values, and the last processor is a list echo operation - this is used because we need some kind of operation which can accept the outputs of 'foo' and 'bar' and relay them to a workflow output. If the input is the string 'true' the following occurs:
1.The value 'true' is fed to the first two processors, 'fail_if_false' and 'fail_if_true'
2.The processor 'fail_if_false' completes and does nothing.
3.The processor 'fail_if_true' fails and does nothing.
4.As 'bar' is linked to 'fail_if_true' by a control link (shown in gray in the diagram) it never starts - although it is not actually cancelled as the diagram would suggest the effect is equivalent as it is never invoked.
5.'foo', however, now has all control and data links satisfied and runs.
6.The single input inputlist in the 'Echo_list' processor now has a value, it disconnects the data link from 'bar' and, as it now has all data and control links satisfied, runs, copying the input value to the outputlist.
7.The workflow returns the value 'foo'.
Were the input 'false' the rightmost case in the diagrams above would occur. Note that there is no inherent restriction on the number of branches - if the input were instead a beanshell script with four outputs it could be used to control four branches or any combination thereof. In this sense the conditional structures available in Taverna are somewhat more expressive than those in conventional imperative language
