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

[<fa...@ho...>]

Hi Daniele,

yes, i first tought also this solution. But there's one "but": B & C 
_BOTH_ must be able to start their work just after A finishes. Let's 
say, what the work document A has been done by an electrician and it is 
reviewed parallel: by B - project manager and C - mechanic. If one (B or 
C) can't start because of another, then there will be some amount of 
wasted time and delay on project process. (As you know, projects are 
usually _always_ late of schedule, but then they are even _more_ late ;)

But i found one simple solution for this, after digging more in OpenFlow 
sources and learning some Python. Answer is simple: when the reviewer 
will press "reject", then a script will check workitems_from in current 
workitem, find its parent, and send the other workitem "trees" (if 
parent workitem splitted) - to fallout. Was a quite simple recursive 
function :)

I hope it does not hurt any process instances, if some workitems are 
left in fallout state when a instance is finished? So i can see also the 
history etc. Better than deletion, and later - if it is needed, 
workitems can be put back to workflow too. Good :)

BR Mati

Daniele wrote:

>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
>
>
>  
>