Re: [Openflow-dev] Splitting and rejecting flow problem

[Daniele <d.t...@ic...>]

Hello mati,

sorry for delaying an answer so much. 

Killing workitems is not such a nice action to be making as part of a 
standard flow. I mean, you can do it exceptionally but you should  
avoid killing workitems as part of your normal "in the flow" job. This means 
we should try sorting out a process flow that behaves like you want without 
killing any workitem.

If I understand correctly, the flow you have in mind is something like: 
"something made in A is to be reviewed in B and C, each of them sending back 
to A in the case the check is not passed. Only if both B and C are passed 
should the flow be allowed to continue to other activities."

I guess serializing B and C would solve the problem. This is because you want 
B activity to be influencing C activity and viceversa. The process would be:
(all inputs are "xor" input in the activities below)
A->B
B->A xor C
C->A xor routing
routing->D and E

Since they both send back to A they'll both have to be reviewing the work if 
any of B or C rejects it, and this is what you want, right?

I am missing something?
	Daniele


On Thursday 25 September 2003 09:22, you wrote:
> Hi,
>
> thank You, Daniele, for quick response for my previuos question. Those 2
> lines of code seemed so simple but i self couldnt figure it out :)
>
> So, i have a next question (don't know, maybe there is already an answer to
> this, but i didnt find it in mailing archives):
>
> Suppose we have a big and complicated workflow - many parallel flows,
> splits and joins. And most of them must be able to "reject" the previous
> activity.
>
> [A]+<-->[B]-->[D]-->..
>
>     <-->[C]-->[E]-->..
>
> inputs & outputs:
> A: xor input, and output
> B,C: and input, xor output
> D,E: and, and (does not really matter)
>
> A splits its output, and work is forwarded to both B and C. B and C both
> have a conditional transition back to A when they "reject" the work.
>
> Let's say what B approves work, but C does not. So, the work is rejected
> and A has again active workitem. Here comes the tricky part: if A completes
> its work, the workflow is split again! First it seemed to me not very
> logical, but this is actually correct and ok - because of B has the old
> document, it HAS to review the new version too. Thats ok. BUT: "D" will get
> also two workitems! Both old and new! And everyone after D also have the
> same work twice: old(rejected) and new workitem.
>
> I tried different process schemes but still there's question: how's the
> best way to get rid of that (or those) "dead" old workitem(s). Because
> those workitems must be "and"-ed together somehow (or deleted? what about
> history??), otherwise following activities can complete work without "new"
> workitem, and after completion instance, there are left some nasty
> "hanging" workitems... Argh.
>
> Maybe its a pseudo-problem and the answer is simple, but i just dont see it
> :( Has anyone come to this problem? Any simple & general solution?
>
> Best Regards,
> Mati

-- 
Daniele Tarini - Research & Development - Icube S.r.l.
Address:        Via Ridolfi 15 - 56124 Pisa (PI), Italy
E-mail: d.t...@ic...     Web:    http://www.icube.it
Phone:  (+39) 050 97 02 07      Fax:    (+39) 050 31 36 588