Asier schrieb:
> El 06/04/2010 13:55, Torsten Schoenebaum escribió:
>
>>>> You don't have to use the participant registration method of
>>>> RuoteKit at
>>>> all. If you like to register participants dynamically, call the
>>>> engine's
>>>> registration method for yourself and don't use rk's convenience wrapper
>>>> (the call should be something like
>>>> RuoteKit.engine.register_participant participant_name,
>>>> participant_class_or_instance, additional_args
>>>> ).
>>>>
>>>> RuoteKit is just a wrapper to Ruote, it's perfectly well to use Ruote's
>>>> methods directly. RuoteKit's power lies then therein that it provides
>>>> you with a singleton method to access the engine (via RuoteKit.engine).
>>>
>>> Yes, but I think that will only work if I'm developing with Ruby and
>>> have access to ruote internals, but if I'm working with an external
>>> application (c#, java) I can't "interface" with Ruby, so there's the
>>> need for ruote-kit and it's REST interface.
>>
>> It should be really easy to build your own participant controller in a
>> rk fork which takes care of participant registration.
>>
>> As John wrote: It depends on what you want to do. Did you consider using
>> a catchall participant?
>
> Hmmm "catchall participant". I haven't considered it, but it should work.
>
> My scenario can be push or pull; it depends of the approach.
>
> 1. I can have a service accepting external workitems so I can process
> them, and build the reply when done.
>
> 2. I can have an application querying ruote-kit workitems for some
> specific participants, f.i. when the user logs on, and reply when done.
>
> 3. With a catchall participant I feel like I'm doing some of ruote's
> work, but sure it's an acceptable approach.
So what approach do you like to use? 1. and 2. may both use a catchall
without any hassle.
ad 1.: Will be best suited if you need an immediate (and probably
automated) response from your system within the workflow.
ad 2.: Is fine for the use cases you mentioned and others where user
interaction is involved. Have a look at the workitems resource,
it's built for stuff like that (especially the 'participant'
parameter to the get method might be your friend).
Note that in both cases workitem.participant_name will be set to the
participant name actually used in the process definition and NOT the one
registered to the engine. That way it's very easy to filter by your
participants without having to register every one of them within ruote.
Anyway, my crystal ball is in maintenance right now. Without knowing
what you like to achieve with your 'dynamic' participants, further help
won't be possible / will be a pain for you, me and all the others here.
HTH,
Torsten
--
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
To unsubscribe, reply using "remove me" as the subject.
