On Wed, Mar 07, 2012 at 06:12:04PM -0800, Ankit Srivastava wrote: > > I had a few questions - > > 1. Ruote uses these storage mechanisms for persistence of metadata related > to the workflows or I can say process definition? And even may be metadata > related to execution of each workflow instance, right? Does it also store > the workitems or the data being manipulated by the workflows?
The storage contains the workflow run data. It also contains the workitems when stored in the special StorageParticipant (see answer 3). It doesn't contain workflow/process definitions. I'm not sure what you mean by "metadata". If the data you manipulate is small you can place it in the workitems. If your data is big, your best bet is to place references to it in the workitems and only fetch it (or parts of it) if necessary. > 2. What kind of tests are conducted as part of functional and concurrency > tests? I am sorry to ask such questions, but I am just starting with ruby > and ruote. You could read the actual tests. In bried, the test ensure that the storage behaves as specified. The concurrence tests make sure that a storage implementation can be (or not be) used by multiple concurrent workers (those functional tests are prefixed with "ct_"). Note that the tests about the "concurrence" and the "concurrent_iterator" tests are meant to pass when there is one worker as well as when there are multiple workers. If you are new to Ruby implementing a ruote storage will not be a trivial task. It's probably better if you go with an already existing storage implementation. > 3. Is there a way in which I can receive manual inputs from external client > (humans) through web application. I tried understanding the barley.rb code > but could not understand much. You need to learn more about Ruby and its various libraries. > To elaborate my question lets take a > workflow in which a manager Alice has to approve a bill of an employee Bob. > So for one particluar run of this workflow, Bob creates a request with some > parameters and the request goes to Alice (or some webpage which Alice can > access) and Alice approves the request. Whereas in some other execution of > this workflow, Alice rejects it. You can take a look at ruote-kit (https://github.com/kennethkalmer/ruote-kit) it features a minimal interface where web users can pick workitems, modify them and then save them or pass them back to the engine to let the flow resume. Basically a worklist implementation. Kind 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
