Hi John, Thank you for your response. Sorry for not providing enough detail in my first email, in the interest of brevity for the list I over-simplified.
I'll tell you a bit more about our setup so perhaps it will make more sense. We have implemented an access-control scheme, so the human_action actually takes a parameter stating which user the form should be presented to (in this case, the same user that did the proceed on wait_for_edit). The human_action participant actually sends an XMPP PubSub message to our front-end app (not a webapp), which then shows the form to the user. When the user fills in the form, the front-end app PUTs the workitem back through RuoteKit. The idea behind the rewind is that several users can be filling out the form at the same time. When a user needs to fill in the form, the front-end app does a PUT to the wait_for_edit expression (its URI is saved in a REST-fronted database each time wait_for_edit is called so that the front-end app can find it). This sends the form to that particular user's front-end, and the other branch of the concurrence returns to wait_for_edit to wait for other users to fill in the form. When each user saves their own form, the front-end app should PUT to the wait_for_save participant to save their work to the DB and the rewind goes back to waiting again. The rewind actually has an :if to verify if the user is actually finished to break out of the loop. The problem is that the front-end app needs to know the FEI of the wait_for_save so that it can do the PUT. After thinking a bit more I am thinking that wait_for_save can search for the human_action workitem (probably using the WFID and the username) and then add its FEI to the workitem and perhaps send the URI to the front-end via XMPP. It would then return without doing a reply_to_engine. When the front-end PUTs the workitem with proceeded:true, an on_reply would take care of saving the work. The problem I see here is a possible race condition, could the wait_for_save participant be executed before the human_action workitem is actually created and persisted? Any other ideas? Thanks again! *Mario Camou* | *Co-Founder* [email protected] http://abstra.cc Tanto este mensaje como todos los posibles documentos adjuntos al mismo, son confidenciales y están dirigidos exclusivamente a los destinatarios de los mismos. Por favor, si Usted no es uno de dichos destinatarios, notifíquenos este hecho y elimine el mensaje de su sistema. Queda prohibida la copia, difusión o revelación de su contenido a terceros sin el previo consentimiento por escrito de “ABSTRA CC FACTORIA SOFTWARE, S.A.”. En caso contrario, vulnerará la legislación vigente. Sus datos figuran en un fichero propiedad de "ABSTRA CC FACTORIA SOFTWARE, S.A.". Si desea acceder a sus datos, rectificarlos, cancelarlos u oponerse a su tratamiento, diríjase por escrito a "ABSTRA CC FACTORIA SOFTWARE, S.A.", C/ Boix y Morer, 6, 7 planta de Madrid, CP-28003. Both this message and all possible documents attached to it, are confidential and are intended exclusively to recipients of them. Please, if you are not one of those recipients, notify us of this fact and delete the message from your system. Copying, dissemination or disclosure of their contents to third parties without the prior written consent of "ABSTRA CC FACTORIA SOFTWARE, S.A." is prohibited. Otherwise, you violate the legislation in force. Your data are contained in a file property of "ABSTRA CC FACTORIA SOFTWARE, S.A.". If you want to access your data, rectify them, cancel them or oppose its processing, submit in writing to "ABSTRA CC FACTORIA SOFTWARE, S.A.", C/ Boix y Morer, 6, 7 floor Madrid, CP-28003. On Wed, Nov 7, 2012 at 3:59 AM, John Mettraux <[email protected]> wrote: > > On Tue, Nov 06, 2012 at 02:13:11PM +0100, Mario Camou wrote: > > Hi all, > > Hello Mario, > > Glad to read from you. I will try to answer your question, please bear with > me if I give multiple answers (pick the one you like). > > > > I have the following (simplified) workflow which is called as a > subprocess > > in several places in our application: > > > > Ruote.process_definition :name => 'bm_form_multi', :revision => '0.1' do > > cursor do > > sequence do > > wait_for_edit > > concurrence do > > concurrence :forget => true do > > human_action > > > > cursor do > > wait_for_save > > rewind > > end > > end > > > > rewind > > end > > end > > end > > end # process_definition > > If I compress/simplify this workflow, it becomes > > ---8<--- > Ruote.process_definition :name => 'bm_form_multi', :revision => '0.1' do > cursor do > wait_for_edit > concurrence do > concurrence :forget => true do > human_action > cursor do > wait_for_save > rewind > end > end > rewind # <------ ??? > end > end > end # process_definition > --->8--- > > (the sequence inside of the cursor shouldn't be necessary, maybe it's just > a > remainder of the bigger real workflow definition). > > Isn't that a loop? As soon as wait_for_edit is over, the cursor gets > rewound... > > > > The human_action participant waits for a person to fill in a form. The > idea > > is that several users can fill in the same form in parallel and save > their > > information at any time (without closing the form). When the user needs > to > > fill in the form, the front-end application sends a PUT with proceed to > the > > wait_for_edit participant, which then creates a new branch of the > > concurrence for that user to edit. > > Wouldn't it be possible to simplify this by having a single step > > ---8<--- > Ruote.define do > # ... > multi_form > # ... > end > --->8--- > > Where multiform makes available a form, accessible by multiple users, and > each user may save and/or proceed? Ironically, because ruote-kit has no > access control, that's already how it behaves, anybody can edit, the first > one to hit save wins, same thing with "save and proceed". > > I think it'd remove the presentation concerns from the process definition > (and isolate them in the participant implementation). > > > > What I would like to happen is, when the user saves their work, the > > front-end should send a PUT with proceed to the wait_for_save > participant. > > My problem is, the wait_for_save participant needs to communicate its FEI > > to the human_action participant so the front-end knows the URI to send > the > > PUT to. > > Taking ruote-kit as an example again, when you edit a workitem, you're > presented with a form whose action is the URI of the workitem (the method > is > PUT). That URI contains the fei (in condensed form). > > You can turn a fei into a string with > > Ruote.sid(fei) > # => "0_0!5dbf4ce1553453baa17c2213d239e5fa!20101224-bababa" > > and turn it back into a fei with > > Ruote.extract_fei("0_0!5dbf4ce1553453baa17c2213d239e5fa!20101224-bababa") > # => an instance of FlowExpressionId > > > I hope this helps, please feel free to refine/develop your question(s) in > this thread. > > Best regards, > > -- > John Mettraux - http://lambda.io/jmettraux > > -- > you received this message because you are subscribed to the "ruote users" > group. > to post : send email to [email protected] > to unsubscribe : send email to > [email protected] > more options : http://groups.google.com/group/openwferu-users?hl=en > -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
