Return-Path: X-Original-To: apmail-oodt-dev-archive@www.apache.org Delivered-To: apmail-oodt-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 18E9E9917 for ; Fri, 2 Mar 2012 04:07:05 +0000 (UTC) Received: (qmail 12211 invoked by uid 500); 2 Mar 2012 04:07:04 -0000 Delivered-To: apmail-oodt-dev-archive@oodt.apache.org Received: (qmail 11165 invoked by uid 500); 2 Mar 2012 04:07:01 -0000 Mailing-List: contact dev-help@oodt.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@oodt.apache.org Delivered-To: mailing list dev@oodt.apache.org Received: (qmail 9979 invoked by uid 99); 2 Mar 2012 04:06:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Mar 2012 04:06:59 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [128.149.139.105] (HELO mail.jpl.nasa.gov) (128.149.139.105) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Mar 2012 04:06:46 +0000 Received: from mail.jpl.nasa.gov (altvirehtstap02.jpl.nasa.gov [128.149.137.73]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id q22460Z5017146 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Thu, 1 Mar 2012 20:06:03 -0800 Received: from ALTPHYEMBEVSP20.RES.AD.JPL ([128.149.137.83]) by ALTVIREHTSTAP02.RES.AD.JPL ([128.149.137.73]) with mapi; Thu, 1 Mar 2012 19:59:47 -0800 From: "Mattmann, Chris A (388J)" To: Keith Cummings CC: "dev@oodt.apache.org" Date: Thu, 1 Mar 2012 19:59:43 -0800 Subject: Re: Three Workflow questions Thread-Topic: Three Workflow questions Thread-Index: Acz4KOgaHEyeorQdTM+gE3hr1CotIg== Message-ID: <25BCDBCA-4F35-4549-A623-C159E4181443@jpl.nasa.gov> References: <4F450E35.2040906@nrao.edu> <80088491380cf7a4f440a028d9958d6e.squirrel@webmail.aoc.nrao.edu> <4F4FB7C7.6050509@nrao.edu> In-Reply-To: <4F4FB7C7.6050509@nrao.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: chris.a.mattmann@jpl.nasa.gov X-AUTH: Authorized X-Virus-Checked: Checked by ClamAV on apache.org 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= =20 > answer. If you prefer I send such questions to the OODT email list just= =20 > let me know. >=20 > 1. The example code with the Workflow Manager shows examples of=20 > pre-conditions to tasks. How do you configure post-conditions to tasks? In the new wengine-style XML workflow documents, available in=20 trunk with the PackagedWorkflowRepository that came with OODT-70 [1],=20 you specify them with something like this: =09 =09 =09 Note that the conditions tag block can have an attribute 'type',=20 that you can set to post or to pre. At the moment, it simply reads=20 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. >=20 > 2. Is it possible to branch a workflow? If so, can you point me to an=20 > 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=20 branch workflow. So, if you had a simple workflow: =20 ----> t2---->t4 t1-/ =20 \ ---->t3 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=3Dworkflow, e=3Devent, t=3Dtask That make sense? If you need to fan in, you can support=20 this with a precondition on the incoming fan task, holding until the other tasks in the workflow have finished, and then going. >=20 > 3. How do you interrupt a workflow from within? Externally, you can=20 > just issue a stop command on the command-line for this workflow. If a=20 > task (in the Java code) found that an error condition occurred, how=20 > could that be communicated back to the workflow manager? (I found that=20 > throwing an Exception does the trick, but I was wondering if there was a= =20 > less obtrusive way to signal the workflow to stop.) You can, inside of a WorkflowTaskInstance, do something like: XmlRpcWorfklowManager wm =3D new XmlRpcWorkflowManager(new URL(met.getMetad= ata("WorkflowUrl")); wm.stopWorkflowInstance(met.getMetadata("WorkflowInstId")); That will basically have the same effect as the external stop. Exceptions w= ork fine too, even if they don't look elegant :) Would be nice to have a WorkflowStopped= Exception, which extends some generic WorkflowTaskInstanceException, but for now, a good ol' Excepti= on will do it itoo. HTH! Cheers, Chris [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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++