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
