cancel
Showing results for 
Search instead for 
Did you mean: 

repeat usertask A until usertask B has been submitted

billdoor
Champ in-the-making
Champ in-the-making
Hello,
The Scenario is as follows:

I have a Usertask "invite", where the user can say: Invite People to a party by adding them to a guestlist, something along those lines.
The Usertask can be submitted an infinite number of times for the same party, as the user can invite as much people as he wants.
this is reached over the rest resource: parties/1/invite


I then have a parallel usertask "print invitations". after its completion the user may not complete "invite" any more, the workflow has to immideatly continue to "order food".
this task is reached over parties/1/send

my idea was:
              ____| print |_____
              |                        |
O —-<x>| invite | —<+>-<x>–closed=true—–|order food|—…
                        |_______________|
                       closed=false

the servlet behind /invite just submits data do "invite",submits "closed=false" to "print", joins the flows and loops.

the servlet behind /print finishes "invite" without passing data and submits "closed=true" to "print", joining the flows, closed beeing true breaks the loop.

The only problem is:
It IS possible for the user to hit the timewindow between the two submits, requesting /invite and /print to fast and
1) enabling the User to invite someone after print has been submitted
2) looping when the user wanted to print and continue ordering food



For short: the core requirements are:
1) The user has to be able to invite as many people as he likes
2) it has to be 100% impossible to add a guest after "print" was sumbited (except fiddling with the database, i mean things that could happen due to raceconditions = bad timing/luck)

1.1) optimal: the user can invite a person after the other without bothering for waiting for an answer
i.e: If the "invite" task somehow takes 1 minute, the user should be able to keep inviting. This cannot be done with my idea, because the "invite" task would not be avaiable to submit to as the flow would not have finished the "loop"

I want to know if the engine or the bpm spec offers an "out of the box" solution for this case (it does not hit me as very rare, constructed but pretty common).
Otherwise i would have to use the wrapping javaservlets to handle concurrency, ensuring that only one thread can access a specific "partyprocess"-instance, hack-fixing whilst all the time worrying what happens if the engine rolls back from a crash and is somehow out of sync with my mechanisms etc.

If this is not possible using only activiti methods, i appreciate any ideas to make this as safe as it can be.

@the Developers/Activiticracks: If you 100% KNOW there is no way of doing this with activiti on its own, please say so too.

Thanks for any help or idea in advance,

Billdoor

Ps.: Its not about Parties, the requirements are really important but i'm kind of sworn to secrecy here^^
2 REPLIES 2

billdoor
Champ in-the-making
Champ in-the-making
sorry for this, btu i could not find the edit button.

I m currently not on my desk, so drawing a propper diagram is hard. the flow splits with "<+>" and joins with "<+>", after the join there is an exclusive gateway splitting the flow into closed=true and closed=false

jbarrez
Star Contributor
Star Contributor
I'm not sure if I grasp fully the requirements,
but the standard approach to this is to populate a regular arrayList with the guests (a user task that loops until the user hits 'finish' and pass that to a multi-instance task (the invite).