Hi Tirath, You could also use the TDA/NimrodK director that does token tagging and matching. But, as you know, it is a separate download.
Regards, Colin 2009/10/16 Edward A. Lee <eal at eecs.berkeley.edu>: > > The problem here is that you have an implicit notion of time, > and that notion is absent in PN. > > I suggest using the SR director. > > Edward > > > Tirath Ramdas wrote: >> >> Hi all, >> >> I have a situation which I have been able to address in a "kludgy" way, >> but I wonder if there may be a better way, so I am presenting the problem >> and my proposed solution here for your critique and counter-suggestions. I >> am sure it's a situation that many others have encountered. This is with the >> PN director: I'm not sure how, if at all, the DDF director might help. >> Anyway, here goes... >> >> THE PROBLEM: >> >> Let's say I have a single source of data that has to go through 3 actors: >> A, B, and C. They are laid out in a fork/join configuration. The DataSource >> goes to A and B, and the outputs from those two actors go to C. In dot >> notation, this is what my business logic graph looks like: >> >> DataSource -> TaskA; >> DataSource -> TaskB; >> TaskA -> TaskC; >> TaskB -> TaskC; >> >> This is a trivial workflow. But now, I want to make my TaskA actor more >> sophisticated and detect failures in the computation (I mean business logic >> failures - not the kind of thing that can be fixed by re-execution). I will >> include in TaskA a boolean switch to detect successful jobs and push tokens >> to the output port only when they are good. But the important thing is that >> one bad piece of data should not stop the workflow: the rest of the data >> gets processed as usual. >> >> The problem is, TaskB never knows when one of TaskA's jobs fails, and it >> dutifully pushes all of it's tokens through. As a result, TaskC gets mixed >> up tokens. >> >> A contrived but indicative example: let's say my DataSource is a Ramp >> producing 1 to 9, TaskB is simply an expression that pushes all tokens >> through, and TaskA has an "error condition" where a token value "5" is >> considered an error and routed to the error port instead of the normal >> output port. Task C just merges both it's inputs into a 2-element array. A >> sample Kepler workflow is here:http://pastebin.com/m2faecfb3 >> >> What happens is this: >> >> {0, 0} >> {1, 1} >> {2, 2} >> {3, 3} >> {4, 4} >> {6, 5} <- problem starts here >> {7, 6} <- >> {8, 7} <- >> {9, 8} <- >> >> What I want to see is this: >> >> {0, 0} >> {1, 1} >> {2, 2} >> {3, 3} >> {4, 4} >> {6, 6} <- desired result >> {7, 7} <- >> {8, 8} <- >> {9, 9} <- >> >> MY KLUDGE: >> >> I hacked around this simply by passing all of TaskB's results through >> "passthrough" ports in TaskA, so that TaskA's condition checking can be >> effectively applied to TaskB's results as well. This is ugly and seriously >> detracts from the business process flow that I want to express. >> >> I don't want to make TaskC responsible for doing TaskB's error checking: >> what if my TaskC is a very generic actor? In practice TaskB's error-checking >> is highly application-specific (grep-ing the output of a computational >> chemistry legacy app). >> >> However, I did consider a more generic approach to exception handling that >> would in fact place the burden on TaskC: I considered the possibility of >> mandating that every actor must output a record which contains the output >> data and also a "predication" [1] field. The predication field indicates >> when the data is valid. Any actor receiving tokens only proceeds with the >> computation if the predication fields on all it's inputs are set to valid; >> if even one is invalid, the whole lot gets routed to an error bin, but the >> next lot gets processed as though nothing went wrong. Also I vaguely recall >> reading that some other workflow engine does something like this. Anyway, I >> did not proceed with this yet because it sounds like a non-trivial amount of >> work to modify all the actors I use to adhere to this behavior. >> >> Any other ideas? >> >> regards, >> -tirath >> >> [1] Borrowing the word "predication" from Intel's Itanium branch >> misprediction handling, not sure who they borrowed the term from. >> >> _______________________________________________ >> Kepler-users mailing list >> Kepler-users at kepler-project.org >> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users > > _______________________________________________ > Kepler-users mailing list > Kepler-users at kepler-project.org > http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users > > -- Colin
