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".
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).
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).
Wdyt ? Sorry for the confusion, trying to reach a optimal solution... Cheers,
--
John Mettraux - http://jmettraux.wordpress.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---