On Tue, Apr 20, 2010 at 1:23 AM, Olle <[email protected]> wrote: > > 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 excellent ! At the moment we need to finalize our tests and > run them massively to elaborate the final decision.
Hi Olle, looking forward to the result of your tests. If you don't use ruote, please take the time to tell me what went wrong with it so that I can make it better (if possible). >> 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? It's not that heavy, but heavier than fetching the right workitem. Though, if you know the fei, you could directly write wi = Ruote::FlowExpression.fetch(engine.context, fei).h.applied_workitem It's also a direct hit. (I could wrap that in a method for advanced users...) >> 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. OK. If the participant is in charge of handing the workitem to the "external participant" and fetching back the answer, all from its consume method, then you have an on_reply, already. Easy. If the workitem comes back to the engine via a listener, should I re-instantiate the participant and trigger its on_reply ? These are the things I have to think about. I like your idea, but I'm a bit busy right now, I hope that by the end of the week, the ideas will have gotten clearer and the best implementation will appear. Sorry for my slowness. >> > 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? You are right. The cron technique I described is indeed not appropriate. (now heading to your next email) -- John Mettraux - http://jmettraux.wordpress.com -- 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
