On Fri, Mar 6, 2009 at 2:21 AM, J B <[email protected]> wrote:
>
> That, along with reading other threads here and playing with your todo list
> example (which to me is a much better quickstart) in a debugger...
Hello,
oh really, then I will link to it as well from the quickstart page,
I'm sure you're not the only one who prefers the todo list.
(isn't the debugger a bit of an overkill ? simple "puts" or "p" calls
should do the trick and save you precious time... OK, I shut up)
> Now, let me see if I can describe the basics at a high level, and you tell
> me where I'm wrong.
>
> In ruote, you create a process definition. That definition can be a number
> of types of flows, but the most basic is a sequence.
A process definition is a tree of expressions. The expression at the
root is the "process-definition", the child to that root is usually a
'sequence', but it's OK to have processes like (using XML, as the <>
make it stand out in the text of the email) :
<process-definition name="x" revision="y">
<participant ref="toto" />
</process-definition>
or
<process-definition name="x" revision="y">
<if test="${f:flag} == green">
<!-- then --><participant ref="a" />
<!-- else --><participant ref="b" />
</if>
</process-definition>
> A sequence steps through a list of participants, handing each a "workitem",
> which is actually of the class InflowWorkItem.
A sequence can step through a list of sequences, concurrences,
participants, ... Each of them gets handed a workitem (of the class
InflowWorkItem). A process definition defines a tree of expressions.
The process instance instantiates branches of the tree as needed (it
won't create branches that are discarded (if/then/else)).
> To start a process definition running, you would create a launch item. This
> launch item will allow you set keys into it, like a hash, which will end up
> in the workitem hash when that hash is handed to the participants.
Yes, but you can also simply launch a process by passing the definition :
engine.launch(pdef0)
or
engine.launch(%{<process-definition name="x" revision="y">
<participant ref="toto" />
</process-definition>})
or the URL to the process definition
engine.launch("http://documents.example.org/pdefs/pdef0_20080405_capex.xml";)
In those 3 examples, the initial 'hash' is empty.
Launchitems are useful for pre-filling workitems.
> A "workitem", both in Launch form and Inflow form, should be treated as a
> hash. It's up to you what you place in this hash, and how you use it to make
> decisions if you wish the flow to continue (assuming you're using some form
> of looping sequence) or not.
True. With an "if" expression, you can let the decisions 'happen' in
the process instance, but as you explained decisions taken inside of
participants (human or automated) are OK (they even make business
processes easier to read).
> When you speak of proceeding a workitem, you're simply stating that the
> current participant doesn't do anything to prevent that workitem from moving
> to the next participant. If your participants don't really do anything at
> all, the workitem will proceed through a sequence unimpeded.
Sorry for the vagueness of this "proceed" concept. Human participants
usually have to explicitely send back the workitem to the engine for
it to proceed (resume) in its process instance.
Note that there is a timeout attribute to participants to resume
automatically if the participant forgot the workitem.
<participant ref="toto" timeout="2d5h" /> <!-- toto has two days and
five hours to 'act' with the workitem -->
When the timeout is triggered, the flow resumes with the workitem has
it was when it reached the timeout block.
There is a timeout expression
(http://openwferu.rubyforge.org/expressions.html#exp_timeout) for
setting a timeout for whole segments of processes.
The idea behind 'proceed' is that the engine fired a workitem at the
[real] participant and is waiting for the answer. Proceed is about
replying to the engine [with an updated version of the workitem
[payload]].
> So at the most basic level, we're talking about an engine that hands a hash
> to different objects (participants) in a flow based on how the process
> definition was set up.
Yes.
> Is the above correct (or close to being)? If not, where is my understanding
> incorrect? If so, I'm starting to grasp things (I think).
You'll be ready to write documentation soon ;-) Out of curiosity,
which workflow engine are you currently using ?
> I believe that many more would grasp ruote earlier if you created a very
> basic quickstart, which outlines things in the most simple manner possible
> like I've tried to do above. Maybe it exists and I missed it. I've been
> looking at this too long ;-).
Thanks for the suggestion. Will mull over it.
> So this leads me to another question. It would seem that once the workitem
> has been handed to the participant, the participant needs to decide if it
> can continue. This works well in the task example where the participant can
> simply prompt the user within the block and wait on input...but in a web
> environment where the interaction is disconnected there has to be another
> mechanism. I will download the ruote-web2 project and look at how it
> accomplishes this, but any pointers are welcome.
Ruote-web2 and ruote-rest do that via an "inbox" mechanism.
The todo example is super-vanilla, ruote is thought for an
asynchronous world (with sync being a subset of async). Maybe the
danger of the todo-list quickstart lies in making people believe that
ruote is just about synchronous question/answer cycles...
Best regards, thanks for the feedback,
--
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
-~----------~----~----~----~------~----~------~--~---
