Hello, John! Thank you for detailed response and samples, very useful!
Some preface to my comments below: 99,9999999999 )) percents of our custom participants will work with an external CMS to store\retreive \process information. It's also used as a task system and file storage. The design of is provided "as is", so we can't modify it. My above question about "locked resource" is our usual headache and we need to take care of it. We can receive such reply from that system even during creation of task for user. This is a main reason why I asked all those questions and it's very important for us. Don't want to discuss why we can't use other system: it's not only technical, but also political issue, so we just try to do our best using it and make life of our customers simpler. Workflow is also part of that system, but I hope it could be replaced with ruote. Currently we've integrated almost everything we need for write and run some "typical" approval process using ruote in conjunction with that system. We already ran some simplified tests and ruote works exellent! At the moment we need to finalize our tests and run them massively to elaborate the final decision. > In those cases I would have gone for an extension of the > StorageParticipant class. It could look like this : > > ---8<--- > class SemiExternalParticipant < Ruote::StorageParticipant > def consume (workitem) > notify_external_participant(workitem.fei) > super > end > end > --->8--- > > Then for the "reply", a PUT on /workitems/20100419-babaraca!!0_0 could > do the trick. And the workitem is waiting for you in the storage > participant, no need to call engine.process(wfid). > > But you're the final judge. I don't see anything wrong with your approach. > Hmmm, I didn't think about extending StorageParticipant. That a good remark, thank you! What do you mean saying "no need to call engine.process(wfid)", is at a "heavy" for the engine? > > But I understand the pain. > > I will think about your on_reply idea. It makes lots of sense, but I'd > like to sleep on it for a while. > > http://github.com/jmettraux/ruote/blob/ruote2.1/TODO.txt#L345-346 > > There is one thing. Since we now favour participants instantiated for > each dispatch over participants instantiated at register time, it > may/will not be the the 'same' participant doing the on_reply as the > one that did the dispatch. I'm not sure what is the problem here. Participant is stateless, needed "state" information may be saved in the workitem. User just provide a classname with some options, and it will have desired behavior in any worker aquainted with this class. I planned to implement some basic participant and subcluss it for "type" of tasks. It will parse and transfrom results as needed. Usually we have 10-20 different type of tasks per workflow instance, used for all the processes. > > If I get back to your question #2, you could do the "on_reply" in > there. But granted, this feels not right. > > > 4. This question/suggestion also related to external participants. > > It's possible. > > Here is a Rails example : (http://gist.github.com/370998) > > --->8--- > > There is a dedicated cron process that runs every day at 6 in the > morning and sends reminder to users if necessary. > > I think it could be adapted to your case. I use a block participant > (mea culpa), you could use a custom participant and place all the > reminder logic in it (instead of my Toto::Operations helper module). > You could place reminder frequency data in the workitem itself (since > the user hasn't yet touched). > > The global "gets cancelled after 1 week" thing can be left to the > participant timeout attribute. The cron simply won't send reminders > for workitems that are not present (it doesn't keep track of them). > > On the other hand, the hardcore "ruote way" could look like : > > ---8<--- > concurrence :count => 1 do > > the_real_participant :timeout => '1w' > > repeat do > sleep '${time_before_next_reminder}' > send_reminder_to_real_participant > end > end > --->8--- > > As soon as "the_real_participant" exits the reminding loop gets > cancelled (thanks to :count => 1 which tells the concurrence to expect > only one branch to reply (and then cancel)). > > As you would say "it's watered down". It could be wrapped in a subprocess. I agree, this is a good variant for rare reminders. I'm already thinking of it, but not in terms of ruote, you gave me an almost ready- to-use example, thanks! > > > b. Participant works with external resource. If resource is > > locked, participant should try every 10 minutes for 2 hours and raise > > error if the resource still locked. > > Above scenarios could be defined in the process definition, > > but process becomes watered down and less readable. I'm almost sure > > that it is should be the responsibility (at least in my particular > > case) of the participant, not the process definition. > > Those retry techniques belong to the participant IMHO. Sorry, I'm not sure what you meant here. Described above technique of reminders? Usually we have 3000-6000 concurrent processes. Most of them waits on parallel approval step contained human activities and before/after processing (3-10 concurrent branches). So we will have 9000-60000 worktems in the storage. The nature of before\after processing doesn't requre it to subclass of the storage participant - it just do something with the information in the CMS, but rarely we can receive "resource is locked" in that processing steps (as I described in preface). To handle it in shown manner we will need to subclass StorageParticipant for every processing step. To retry every 1 minute it will read and process all of the workitems in the storage every minute, am I correct? > > Thanks for the excellent discussion ! I am learning a lot. > > I'm trying to show you various techniques, I know you'll pick the > right one for your case or come up with some innovation. > John, thank you for your patience! )) I'm not sure who of us really learning a lot ). Oh, there are so many "I'm not sure" from me above... Best regards, Oleg -- 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
