Hi Matt,
On 7/17/07, Matt Zukowski <[EMAIL PROTECTED]> wrote:
>
> I guess I could simplify the above to:
>
> p = @engine.get_participant(@participant_name)
> workitem = [EMAIL PROTECTED]
>
> # update workitem's attributes here...
>
> p.forward(workitem)
This is much better than the "pattern" exposed in your previous message.
@fei : you assume you know in advance the fei (you'll tell me you
launched it by yourself, but did you store that fei value ? What if
your Camping application (its VM) got restarted, did you keep track of
the fei ?
A store participant stores workitem for *any* process instance. You can do
store_participant.each |fei, workitem|
workitem.seen = "true"
store_participant.forward(workitem)
end
without knowing in advance the fei of all the workitems in the store.
Only with DHL and Fedex do you know the tracker id of the package you
receive in advance, with regular mail you don't know and don't care,
you just process the mail as you receive it (usually).
> .... I guess what I don't understand is how the engine knows which
> workflow instance to resume when I call forward() on the participant,
> since there is nothing here tying that participant instance to a
> particular workflow instance.
store_participant.forward(workitem)
The workitem is tied to its process instance (think Fedex tracker id).
The participant knows how to contact the engine, so you're just
telling "participant, please give back this workitem to the engine to
let it resume its flow".
I hope this helps, best regards,
John
P.S. I've seen the Fluxr initial commits, looks promising :)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OpenWFEru dev" 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-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
