Hello John, >> What we need is a common understanding. Thank you for being patient, in order to get a common understanding with me and my problem. Maybe i have a little wrong understanding of ruote, because i have also to do with JBPM-Workflow-Definitions. So now, I would like to describe my work more in detail to you: Yes, my system will be a web wizard, used by human users. The only difference is, that many users do the same steps (a step is in my understanding one participant – in jbpm syntax called „node“ – right?). The sequence of the steps is defined in the workflow. Each user starts his own workflow (process-instance) because everyone has to go through the same steps. The effort is, that each person works through the same nodes (participants), but can make different notes to each participant. In the future all notes of all participant from all users will be summarized.
>> Please define "interrupt" Interrupting means for me, to persist the current position (what was the last finished participant of a user) in order to continue the process-instance at an other time. >> Please define "reopen" This is the „read the last persistent state“ from above. In order to go to the next unfinished participant. Maybe you can give me a hint for an architecture of my problem. greetings, Klaus Am 23. April 2012 00:20 schrieb John Mettraux <[email protected]>: > > On Sun, Apr 22, 2012 at 10:00:01PM +0200, Klaus Schmidtmamn wrote: > > > > Some questions are still open: > > > > Yes, you are right, i need more a customer-based workflow-instance than a > > web-session. > > I never wrote you needed more of a customer-based workflow-instance than a > web-session [-based one]... > > > So i tried this: > > > > wfid = dashboard.launch(pdef, 'customer_id' => customer_id) .. with an > > individual given ID. But the same: If i start 2 Session (each in a > > different terminal), the output of the one occurs in the other and the > > input of the other terminal occurs asynchronously in the other terminal > > window. > > You took my answer to your question number 2 as an answer to your > unnumbered > initial question... It's very difficult to have a conversation with such a > confusing technique of yours. > > Please define what do you mean by "starting a Session". Don't hesitate to > use > a gist: https://gist.github.com/ > > > Maybe i need a separate process-definition-name? > > No. What we need is a common understanding. > > > I think, i understood the theory: one piece of work will be done by multi > > users. > > Let me rephrase. If you have multiple ruote workers, they will compete for > pieces of work, one piece of work will be executed by a single ruote > worker. > > If now by "piece of work" you mean "workitem" and by "user" you mean a > human > using a web browser, then a workitem will be done by a human if he's > presented with the workitem in some way (in ruote-kit this is done via the > "workitems" tab). > > > But in my case, each user (web-client) has to go through the same > > workflow (from the beginning until the end). The instances differentiate > > only by the different user-choice of sub-processes, they want to go > > through. Do You know a better way to synchronize the sessions for each > > client? > > This is unclear. Could you please explain your use case as it looks for the > human using the system? > > > An other problem i saw is the Timeout of 60s. Even if i give a much > longer > > timeout to my main sequence like > > > > sequence :timeout => '2000s' do... > > The problem here is that you're using "wait_for" which is a testing/demo > tool. > > In production one lets the workflow instances run their course and never > uses > wait_for. > > wait_for is used in tests and demonstrations, to pause the main thread of > execution while the workflow is running, then, when wait_for returns the > control to the main thread, to verify if the workflow instance or the whole > system is in the desired state. > > As said in my previous answer, you should investigate "worklists", ie > points > where workitems accumulate and users (humans) may do/perform them. I'm > sorry, > but in my previous answer, I forgot to mention that there is a ready made > "worklist" in the form of Ruote::StorageParticipant. > > > https://github.com/jmettraux/ruote/blob/f36a911378d8fbaebfd172a12b0e53477e182dc2/lib/ruote/part/storage_participant.rb > > Your use of wait_for indicates you're misunderstanding ruote. I have the > impression you're trying to make it work synchronously instead of > understanding it and leveraging its asynchronoucity. > > Once again, are you trying to build a "wizard system": > http://en.wikipedia.org/wiki/Wizard_%28software%29 ? > > > there is a timeout after 60s: > > > > > /home/hugo/.rvm/gems/ruby-1.9.2-p318/gems/ruote-2.3.0/lib/ruote/log/wait_logger.rb:144:in > > `block in wait_for': waited for [:informTimeout], timed out after 60s > > (Ruote::LoggerTimeout) > > > > i found it is the default value for timeout, defined here: > > > > /ruby-1.9.2-p318/gems/ruote-2.3.0/lib/ruote/log/wait_logger.rb > > @timeout = context['wait_logger_timeout'] || 60 # in seconds: > > > > But how can i set the timeout to infinitely? > > You can set the timeout to infinity with a negative value: > > > https://github.com/jmettraux/ruote/blob/f36a911378d8fbaebfd172a12b0e53477e182dc2/lib/ruote/dashboard.rb#L553-560 > > > An Other question is, how to interrupt and reopen a started > > process-instance? Is such an interrupt also possible in a shell client? > > Please define "interrupt". > Please define "reopen". > > > With "ruote-fluo" i am nearly happy. Wasn't there a possibility to start > > and stop the instances? Or was this only possible with ruote-kit? > > ruote-fluo != ruote-kit > > Have you noticed that ruote-kit uses ruote-fluo? ruote-fluo is only meant > to > render workflow definitions. The administration console is ruote-kit, > ruote-fluo is only a rendering tool (repeating that). > Someone might want to use ruote-fluo only and provide his own tool for > process administration instead of ruote-kit. > > > Last but not least: > > why do i have to use this Dashboard now, instead of the engine? > > Because I made a mistake when I first named it an "Engine". The enactment > of > workflow instances is performed by workers, the sum of the workers is the > engine, there is no execution happening in Ruote::Engine / > Ruote::Dashboard, > it's only a dashboard, there are a few indicators and a few wheels to turn, > but the real thing is happening in Ruote::Worker on top of storage > implementations. > > I'm now trying to show a good example and use "Dashboard". > > > Hope to get the overview once. > > Let's do our best. > > > Best regards, > > -- > John Mettraux - http://lambda.io/processi > > -- > 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
