AnsweredAssumed Answered

repeat usertask A until usertask B has been submitted

Question asked by billdoor on Aug 27, 2014
Latest reply on Aug 30, 2014 by jbarrez
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|—…

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,


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