Some additional remarks.
>
> > 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.
>
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?
>
> > > 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?
So this doesn't work as shown, only if I move :on_error into
"sequence" definition:
---
sequence do
external_work :on_error => 'handle_redo_error'
end
---
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?
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
