/**
* A <code>Processor</code> is a {@link Workflow} component that controls the
* invocation of activities.
* <p>
* When a <code>Workflow</code> is run, a particular {@link Activity} will be
* specified as bound to the <code>Processor</code> by the {@link Profile}.
* <p>
* A <code>Processor</code> contains an {@link IterationStrategyStack} to
* describe iterations, and may have {@link InputProcessorPort input} and
* {@link OutputProcessorPort output} ports. The <code>Processor</code> can be
* configured with a {@link Configuration} within a {@link Profile} to specify
* execution details such as retries or parallel jobs.
* <p>
* The {@link #getType()} of a Processor is normally fixed to the value given by
* {@value #PROCESSOR_TYPE}. The configuration of a processor should
* correspondingly be of the type given by the constant {@value #CONFIG_TYPE}.
* <p>
* The default (implied) configuration of a Processor is as of Taverna 3.0 alpha
* 2:
*
* <pre>
* {
* "retry": {
* "maxRetries": 0,
* "initialDelay": 1000,
* "maxDelay": 5000,
* "backoffFactor": 1.0
* },
* "parallelize": {
* "maxJobs": 1
* }
* </pre>
*
* These defaults mean that the processor would not retry the operation, and
* would only perform one concurrent invocation within a given workflow run.
* <p>
* You can provide a partial configuration, e.g. to activate 5 retries using the
* default initialDelay, add a {@link Configuration} of this {@link Processor}
* to the {@link Profile} with the keys:
*
* <pre>
* {
* "retry": {
* "maxRetries": 5
* }
* }
* </pre>
* <p>
* Additionally, do..while-style looping can be configured using the key "loop":
*
* <pre>
* {
* "loop": {
* "comparePort": "outputB",
* "comparison": "EqualTo",
* "compareValue": "15",
* "delay": 0.5,
* "runFirst": true,
* "isFeedBack": false,
* "conditionActivity": "looping-loop"
* }
* }
* </pre>
* <p>
* Note that this is different from looping over incoming values, which happens
* according to the {@link #getIterationStrategyStack()}..
* </p>
* The above loop configuration would repeat calling of the activity bound to
* this processor until its output "outputB" is equal to the string value "15" -
* with a delay of 0.5 seconds between each try.
* <p>
* if <code>"isFeedBack": true</code>, then outputs from the processor will on
* repeated invocations replace the original input values where the port names
* match. Note that the processor ports should be connected in the containing
* workflow.
* <p>
* <code>"runFirst": true</code> means that the activity is called at least
* once, which is generally needed to get a port value to compare.
* <p>
* The <code>"conditionActivity"</code> indicates the name of an
* {@link Activity} within the {@link Profile}, here called "looping-loop". This
* activity is invoked with the current processor output values as input ports,
* and if its output port "loop" contains the string value "true", then the
* processor is invoked again. If the condition output port matches a processor
* input port, then the returned values are used instead of the original
* processor inputs. The conditionActivity is then repeated on the new output
* values, repeated until "loop" no longer is "true".
* <p>
* As of Taverna 3 alpha 2, the "conditionActivity" is called directly without
* consideration of the other parameters. This typically contains a beanshell
* script generated from the above parameters and performs the actual
* comparisons.
* <p>
* FIXME: This conditionActivity currently has to be regenerated when the other
* parameters have changed. This now happens within the Taverna 3 workbench user
* interface when configuring looping. The ideal SCUFL2 behaviour would be to EITHER
* provide a custom conditionActivity OR the parameters.
*
* @author Alan R Williams
* @author Stian Soiland-Reyes
*/
Sub-task
Resolved
Major
scufl2 #3989
Jenkins Automated build
added a comment - SUCCESS: Integrated in scufl2 #3989
SCUFL2-131 javadoc on default processor config (stian: c4e95d0ba2b3681d06e2707bb1bac1e769e05639 )
scufl2-api/src/main/java/uk/org/taverna/scufl2/api/core/Processor.java
Added:
/** * A <code>Processor</code> is a {@link Workflow} component that controls the * invocation of activities. * <p> * When a <code>Workflow</code> is run, a particular {@link Activity} will be * specified as bound to the <code>Processor</code> by the {@link Profile}. * <p> * A <code>Processor</code> contains an {@link IterationStrategyStack} to * describe iterations, and may have {@link InputProcessorPort input} and * {@link OutputProcessorPort output} ports. The <code>Processor</code> can be * configured with a {@link Configuration} within a {@link Profile} to specify * execution details such as retries or parallel jobs. * <p> * The {@link #getType()} of a Processor is normally fixed to the value given by * {@value #PROCESSOR_TYPE}. The configuration of a processor should * correspondingly be of the type given by the constant {@value #CONFIG_TYPE}. * <p> * The default (implied) configuration of a Processor is as of Taverna 3.0 alpha * 2: * * <pre> * { * "retry": { * "maxRetries": 0, * "initialDelay": 1000, * "maxDelay": 5000, * "backoffFactor": 1.0 * }, * "parallelize": { * "maxJobs": 1 * } * </pre> * * These defaults mean that the processor would not retry the operation, and * would only perform one concurrent invocation within a given workflow run. * <p> * You can provide a partial configuration, e.g. to activate 5 retries using the * default initialDelay, add a {@link Configuration} of this {@link Processor} * to the {@link Profile} with the keys: * * <pre> * { * "retry": { * "maxRetries": 5 * } * } * </pre> * <p> * Additionally, do..while-style looping can be configured using the key "loop": * * <pre> * { * "loop": { * "comparePort": "outputB", * "comparison": "EqualTo", * "compareValue": "15", * "delay": 0.5, * "runFirst": true, * "isFeedBack": false, * "conditionActivity": "looping-loop" * } * } * </pre> * <p> * Note that this is different from looping over incoming values, which happens * according to the {@link #getIterationStrategyStack()}.. * </p> * The above loop configuration would repeat calling of the activity bound to * this processor until its output "outputB" is equal to the string value "15" - * with a delay of 0.5 seconds between each try. * <p> * if <code>"isFeedBack": true</code>, then outputs from the processor will on * repeated invocations replace the original input values where the port names * match. Note that the processor ports should be connected in the containing * workflow. * <p> * <code>"runFirst": true</code> means that the activity is called at least * once, which is generally needed to get a port value to compare. * <p> * The <code>"conditionActivity"</code> indicates the name of an * {@link Activity} within the {@link Profile}, here called "looping-loop". This * activity is invoked with the current processor output values as input ports, * and if its output port "loop" contains the string value "true", then the * processor is invoked again. If the condition output port matches a processor * input port, then the returned values are used instead of the original * processor inputs. The conditionActivity is then repeated on the new output * values, repeated until "loop" no longer is "true". * <p> * As of Taverna 3 alpha 2, the "conditionActivity" is called directly without * consideration of the other parameters. This typically contains a beanshell * script generated from the above parameters and performs the actual * comparisons. * <p> * FIXME: This conditionActivity currently has to be regenerated when the other * parameters have changed. This now happens within the Taverna 3 workbench user * interface when configuring looping. The ideal SCUFL2 behaviour would be to EITHER * provide a custom conditionActivity OR the parameters. * * @author Alan R Williams * @author Stian Soiland-Reyes */