Hi! (Just answering a question from Peter, but thought it would be interesting for the test of you as well as I'm not sure if we have this in documentation yet)
See http://www.myexperiment.org/workflows/820 for an example of looping - click the processor checkStatus to see Details -> Advanced: Loop The service will be invoked repeatedly until its output *status* is not equal to the string: RUNNING adding a delay of 0.5 seconds between loops. [Configure] So in this workflow, checkStatus is called several times until the status is something other than 'RUNNING'. To avoid killing EBIs web service, there will be a 0.5 seconds delay before checking the status again. It is possible to set such looping also on nested workflows, but as this example shows you would no longer need to use Nested workflow-Fail_if_false-Critical-Retry trick (which don't work in 2.1, as nested workflows no longer fail themselves; errors are delivered to output ports instead). There's also an interesting checkbox in there for 'Feed back matching ports' - if you tick this, then any output ports from the service (most probably: a nested workflow) which port name is the same as an input port in the same service, then for the second iteration and so on, the service would receive the previous outputs as inputs, allowing it to iteratively modify its own. You will have to provide the initial value from the mother workflow, though. Remember that looping is always done after the first execution, so more like a do…while construct in Pascal. If you inside Looping click 'Customize' you can also write a more complex beanshell script that can check the looping condition (if it should rerun the service or not) - in fact you can also modify port values here, any additional output ports from this beanshell script that matches the input port of the service will be passed along when looping (the second time and so on) - any beanshell input ports matching the service output ports will be inputs to the script (so you can check several outputs), and finally any leftover input ports that match the service input ports, will be provided with the values as passed in from the workflow. Notice that any output port you inspect from the looping needs to be connected to something in the parent workflow so that it will be extracted from the service. Similarly, if you want to create feedback-ports you would also need to connect these outputs to something below in the workflow (like a workflow output port), so that it will be delivered by the service, and can be picked up by the looping. This is partly a bug due to the way looping is implemented, and we've planned to remove the need to do these connections - see http://www.mygrid.org.uk/dev/issues/browse/T2-641 I'll try to summarise this into a wiki page. -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ taverna-users mailing list [email protected] [email protected] Web site: http://www.taverna.org.uk Mailing lists: http://www.taverna.org.uk/taverna-mailing-lists/
