On Thu, Dec 4, 2008 at 10:59 AM, John Mettraux <[EMAIL PROTECTED]> wrote:
>
> On Thu, Dec 4, 2008 at 5:28 PM, Kenneth Kalmer <[EMAIL PROTECTED]> wrote:
>> On Thu, Dec 4, 2008 at 10:17 AM, John Mettraux <[EMAIL PROTECTED]> wrote:
>>
>>> By "explicitely", do you mean that the process gets canceled by
>>> something like "engine.cancel_process(process_id)" (or its web
>>> interface equivalent) or that the receptionist did set a "please
>>> cancel whole process" to true in the workitem it received ?
>>
>> It would be the web equivalent (ruote-rest specifically). To add to
>> that, the process definitions are dynamically generated and posted to
>> ruote-rest.
>
> OK,
>
> let's explore the possibilities.
>
> As I initially understood your question, the receptionist could decide
> from within the process to cancel it as a whole :
>
> ...
> <receptionist />
> <subprocess ref="decommission" if="${f:receptionist_said_cancel}" />
> ...
>
> <process-definition name="decommission">
> <sequence>
> <participant ref="do-decommission" />
> <cancel-process />
> </sequence>
> </process-definition>
>
> Not that bad, the workitem would contain the info as last touched by
> the receptionist (pointers to things to decommission).
>
> But this is no "explicit cancel".
This is a great example, problem is I'd have to specify that in
several places since we have a lot of 'human' participants (ActiveP's)
that can either proceed or cancel. The decision to cancel/proceed is
handled by another interface, which does some of its own magic before
cancelling in ruote. But lets not mull over this one.
> Each expression is meant to have the methods apply/reply and cancel.
> If you cancel a process instance, active expressions will each receive
> the cancel message. ParticipantExpression instances will emit an
> OpenWFE::CancelItem instance to the participant to which they sent a
> workitem (and are waiting for it back)... That would mean that all
> participants in your flow are able to cancel/decommission the whole
> set of things required for their process instance... Sounds painful
> (well in Ruby it's not that hard).
Now this is brilliant, since ruote doesn't yet have a
KettleParticipant / CappucinoParticipant (yet). All the participants
in said process that would need the ability to roll back their effects
would be custom participants.
> I've just added "on_error" with Raphael, maybe we could add
> "on_cancel", so that we could specifiy a participant or a subprocess
> that'd be called upon the cancelling of a branch or a subprocess. The
> more I think about it the more I like it.
>
> <process-definition name="x" revision="y" on-cancel="throw_the_water_away">
> ...
> <process-definition name="throw_the_water_away">
> ...
>
> Like with on-error, on-cancel could point to a participant or a
> subprocess (or the URL of yet another process).
This is also brilliant. I think from the point of view that process
definitions should be readable and easily maintainable it makes
perfect sense. I can also imagine some backward African process
needing a sequence of politicians in the subprocess...
If you don't get to this by the 19th I'll gladly take a stab at it.
Would be nice to really dig in deep into the internals and explore
what is going on.
> Wdyt ? Sorry for the confusion, trying to reach a optimal solution... Cheers,
As always, champion answers, thanks.
Best
--
Kenneth Kalmer
[EMAIL PROTECTED]
http://opensourcery.co.za
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruote (OpenWFEru) users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/openwferu-users?hl=en
-~----------~----~----~----~------~----~------~--~---
