oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Three Workflow questions
Date Fri, 02 Mar 2012 03:59:43 GMT
Hi Keith,

Thanks for your questions! Happy to answer them below:

On Mar 1, 2012, at 9:54 AM, Keith Cummings wrote:

> Hi Chris,
> I have a few questions that I hope won't take you but a minute or two to 
> answer.  If you prefer I send such questions to the OODT email list just 
> let me know.
> 1. The example code with the Workflow Manager shows examples of 
> pre-conditions to tasks.  How do you configure post-conditions to tasks?

In the new wengine-style XML workflow documents, available in 
trunk with the PackagedWorkflowRepository that came with OODT-70 [1], 
you specify them with something like this:

		<conditions execution="parallel" type="pre">
			<condition id-ref="urn:npp:MOA_IASI_L1C_Daily"/>			
			<condition id-ref="urn:npp:MOA_MHS_L1B_Daily"/>			
			<condition id-ref="urn:npp:MOA_AMSUA_L1B_Daily"/>			

Note that the conditions tag block can have an attribute 'type', 
that you can set to post or to pre. At the moment, it simply reads 
this, but as soon as the wengine is fully integrated, it will support
pre or post execution of these conditions. That should ship with 0.4.

> 2. Is it possible to branch a workflow?  If so, can you point me to an 
> example?

Sure, it's possible even in the 0.1-incubating, 0.2 and 0.3 versions.
The way that you branch a workflow is to:

1. add a simple WorkflowTaskInstance implementation, whose goal
is to send an Event *back* to the same workflow manager, to kick off
another workflow. You can find a simple example of such a redirector
here [2].

2. wire up an event for the next stage of the branch to kick off the 
branch workflow. So, if you had a simple workflow:
      ----> t2---->t4

You could support this with the following:

w1: t1, branch redirector (seeded with e2,e3)
w2: t2, t4
w3: t3

e1: w1
e2: w2
e3: w3

Where w=workflow, e=event, t=task

That make sense? If you need to fan in, you can support 
this with a precondition on the incoming fan task, holding until
the other tasks in the workflow have finished, and then going.

> 3. How do you interrupt a workflow from within?  Externally, you can 
> just issue a stop command on the command-line for this workflow.  If a 
> task (in the Java code) found that an error condition occurred, how 
> could that be communicated back to the workflow manager?  (I found that 
> throwing an Exception does the trick, but I was wondering if there was a 
> less obtrusive way to signal the workflow to stop.)

You can, inside of a WorkflowTaskInstance, do something like:

XmlRpcWorfklowManager wm = new XmlRpcWorkflowManager(new URL(met.getMetadata("WorkflowUrl"));

That will basically have the same effect as the external stop. Exceptions work fine too,
even if they don't look elegant :)  Would be nice to have a WorkflowStoppedException, which
some generic WorkflowTaskInstanceException, but for now, a good ol' Exception will do it itoo.



[1] https://issues.apache.org/jira/browse/OODT-70
[2] http://s.apache.org/NeK

Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

View raw message