2009/3/5 J B <[email protected]>:
> On Wed, Mar 4, 2009 at 7:20 AM, John Mettraux <[email protected]> wrote:
>>
>> I've uploaded something at http://gist.github.com/73813
>>
>> It explores some variants (like using a subprocess definition, ...)
>>
>> Questions are welcome.
>
> Thanks very much for this. I've spent the morning trying to put together a
> driver that will push this process through. I'm not quite there yet, but I'm
> learning, and I really appreciated your time.
Hi,
you're welcome. I like this exercise since it allows me to check if
the process definition language (and the engine) are relevant.
>> Ruote process definitions only know about participants (and
>> subprocesses), users and roles emerge later (sorry, no convention over
>> configuration here).
>
> Yes, I'm still getting my head around this concept. So, for example, in the
> capex example you provided, I believe I need to register these participants:
>
> engine.register_participant(:initiator, OpenWFE::FileParticipant.new)
> engine.register_participant(:manager, OpenWFE::FileParticipant.new)
> engine.register_participant(:cfo, OpenWFE::FileParticipant.new)
Well, initiator, as I understood your description of the processes is
a user. The two draft processes fetch his name in the field named
"initiator" (ruote-web2 sets by default the name of the launching user
in "launcher"). So no need to register a participant for "initiator"
(but you should have a participant (or participants) for the users).
Same thing for manager. His name is set in the workitem field named
"manager". Note that in the second process draft, there is a
subprocess named "manager" that wraps the logic of fetching the
participant real name ("ref") in the field "manager" and of sending a
notification email.
CFO might deserve its own participant since (just a guess) there's
only one in your organization.
A participant is usually 'invoked' via something like :
<participant ref="nemo" />
that can be shortened to :
<nemo />
This last 'nemo' [pseudo-]expression points to either a participant or
a subprocess.
If the real participant is chosen "at runtime", the form is :
<participant ref="${f:target}" />
or
<participant ref="${target}" />
> I'm a little confused on this:
>
> participant :ref => '${field:initiator}', :activity => 'notification'
>
> The rdoc would seem to indicate this should be ${f:initiator}, so I'm sure
> I'm missing something.
${field:initiator} and ${f:initiator} are equivalent. They get
replaced by the value in the workitem field named 'initiator'.
${v:my_variable} will be replaced by the value in the process variable
named 'my_variable'. It is equivalent to ${my_variable},
${var:my_variable} and ${variable:my_variable}
${fv:toto} will be replaced by the value in the workitem field named
'toto'. If the workitem has no such field, the value in the process
variable named 'toto' will be used. If there is no field nor variable,
the empty string will be used for the substitution.
${vf:xxx} looks for a variable, then for a field.
Note that those "dollar substitutions" results are always strings.
There is a last trick : ${r:xxx} will execute the ruby code in xxx,
turn it to a string and insert it in the target string. There is a
check for potentially dangerous code. By default, this "ruby
evaluation" feature is disabled, you have to enable it by passing
:ruby_eval_allowed => true when instantiating the ruote engine.
I will write a page of documentation about this "dollar notation".
> And, a bit confused on archival, although I'm wondering if that's a
> participant to be defined as well?
It was just a suggestion, you probably don't need it. It could be some
kind of final step. You'd have to define a participant for it. Ruote
has a History component, but it won't keep track of the terminated
processes, hence the 'archival' proposal.
> Would you mind explaining the difference between field usage with the dollar
> sign and without? Example:
> _break :unless => '{f:approved}'
> vs
> participant :ref => '${field:initiator}'
Sorry, it's my mistake. Without the $, no substitution gets performed.
> I looked through the documentation for participant definition, and it appears
> that :activity is not a named attribute it expect, so am I to assume this
> simply is put into the workitem's hash? How would this workflow be driven in
> this case?
You are right, this is just a convention. The participant expression
places its attributes in a field named "params". Those parameters are
thus visible to the participant implementation itself. When the
participant replies to the engine, the workitem field "params" is
cleaned.
"activity" is often used in the workflow domain, but you could use any
other field/attribute name.
> I'd be interested in hearing how others learned ruote....if anyone cares to
> share.
I'm not addressed by the question, but I'll state anyway that since
Ruote is developed on top of a scripting language, it's very easy to
write tests / prototypes and then throw them away. Small steps with
instant satisfaction (or quick failure). I feel that this is an
advantage for learning Ruote, but more importantly it's an advantage
for writing and maintaining process definitions. Ruby makes it very
easy to test/benchmark ruote process definitions. It's extremely cheap
to have a test/experimental ruote environment, a staging environment,
and so, apart from the production environment. Test and throw away
(even throw away ruote after a while if it doesn't suit you (but don't
throw away the experience and knowledge gathered)).
Best regards,
--
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
-~----------~----~----~----~------~----~------~--~---
