On Mon, Apr 19, 2010 at 02:25:41PM -0700, Olle wrote: > > > > 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. > > This also requires a possibility to return modified workitem to the > engine without reply_to_engine in the "consume" method. AFAIK, there > is no way to do this currently, correct?
Hello Oleg, nothing prevents you from extracting the functionality of reply_to_engine out of local participant. Ruote has the concept of 'listener'. Some participants may be 'emit only', their consume method never replies to the engine. That calls for listeners. For example, you could have an AmqpParticipant coupled to an AmqpListener. I haven't brought back yet the listener concept from ruote 0.9 to ruote 2.1, but, as a first step, I have created a core Listener module, similar to LocalParticipant here : http://github.com/jmettraux/ruote/commit/5c0789af2fb13634e75b90803e50717489119da6 > > > > 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? > > > > I tried also to use :on_error attribute to achieve desired > functionality. I raised some specialised exception from "consume". But > it looks like :on_error doesn't work for participant expression, only > for flow control expressions. Is it by design? Sorry, it's not by design. Thanks for reporting, I fixed it at : http://github.com/jmettraux/ruote/commit/d0f47c365e4a0a85a33fdbeaee4d1cfef27f3b2e > So this doesn't work as shown, only if I move :on_error into > "sequence" definition: > > My idea was to do something like this: > > ---- > pdef = Ruote.process_definition :name => 'test' do > sequence do > ... > # participant implementation raises RedoException<Exception if > # it need to be reapplied after a while. > # it should also set "f:redo_wait_interval", but I have no idea, > # how to pass it to the engine without reply_to_engine > external_work :on_error => 'handle_redo_error' > ... > end > > define 'handle_redo_eror' do > wait "f:redo_wait_interval" > # cant set this field in the participant above > _redo > # or some specialized participant which knows where to get > # back for re-applying, for example if it knows fei, it can easily > # utilize engine.re_apply method. > end > end > ---- > > As you can see, here I have two problems: > > 1. Don't know how to pass desired wait interval to "wait" from > "participant". May be process variables could be utilized for this > goal? > 2. Don'k know how to get information about intercepted exception in > the error handler subprocess\participant. Is it possible? It was not really possible, but I have added that for you (for all the ruote users) : http://github.com/jmettraux/ruote/commit/00588816dc8d0221e1f1f7ca58202908a621e099 I hope to release an official ruote 2.1.10 soon. Thanks again ! -- 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
