Hi Torsten,
thanks again for your "Mongrel stop patch".
Please see my comments inline :
On Tue, Nov 25, 2008 at 12:53 AM, Torsten Schoenebaum
<[EMAIL PROTECTED]> wrote:
>
> #
> # Ruote participant which does a REST call. It's using ActiveResource
> to do the
> # actual magic. Currently, only PUT requests are supported and the
> response is
> # ignored, but if you need more functionality, it should be easy to
> add.
> #
> # ==Parameters
> # default_site:: The URI (as string; URI objects should work, too) of
> the site where your REST interface sits. See <tt>site</tt> parameter
> in ActiveResource::Base.
> # default_element_name:: The name of the resource you like to access.
> See <tt>element_name</tt> parameter in ActiveResource::Base.
> # default_action:: The action or method which should be called.
> # default_element_id:: The ID of the resource on which the action
> should be called on default.
> #
> # The URLs which will be generated and called will look like this:
> # <tt>#{default_site}/#{default_element_name.pluralize}/#
> {default_element_id}/#{default_action}.xml</tt>
> #
> # All parameters set default values -- you can always override them in
> the
> # process definition.
> #
> # ==Using it
> # The participant should be registered in the engine in a way like
> this:
> #
> # Engine.instance.register_participant(
> # 'reminder',
> # RestCallParticipant.new(
> # 'http://localhost:7000',
> # 'story',
> # 'send_reminder',
> # 0
> # )
> # )
> #
> # You can now use the participant in your workflow definitions. An
> example using
> # XML:
> #
> # <concurrence count="1">
> # <participant ref="qa" />
> # <cron every="1d">
> # <participant ref="reminder" site="http://localhost:7000";
> element_name="story" action="send_reminder" element_id="$
> {field:story_id}" />
> # </cron>
> # </concurrence>
> #
> # Here, the RestCallParticipant is used to send a reminder.
> #
> # See the descriptions of the default parameters for an explanation of
> the
> # attributes <tt>site</tt>, <tt>element_name</tt>, <tt>action</tt>
> and
> # <tt>element_id</tt>.
> #
> class RestCallParticipant
> include OpenWFE::LocalParticipant
>
> def initialize(default_site, default_element_name, default_action,
> default_element_id)
> @default_site = default_site
> @default_element_name = default_element_name
> @default_action = default_action
> @default_element_id = default_element_id
> end
>
> #
> # This method is called each time the participant receives a
> workitem. It does
> # the PUT request and imediatly replies to the engine after that.
> #
> def consume(workitem)
> site = workitem.params['site'] ? workitem.params['site'] :
> @default_site
> element_name = workitem.params['element_name'] ? workitem.params
> ['element_name'] : @default_element_name
> action = workitem.params['action'] ? workitem.params['action'] :
> @default_action
> element_id = workitem.params['element_id'] ? workitem.params
> ['element_id'] : @default_element_id
maybe something like
site = workitems.params['site'] || @default_site
would be easier to read.
> # create new subclass of ActiveResource::Base
> active_resource_class = Class.new(ActiveResource::Base)
> active_resource_class.site = site # set site parameter
> active_resource_class.element_name = element_name # set element
> name
Maybe "resource" instead of "element" would better suit the
ActiveResource context : "resource_id", "resource_name"...
> # create new object from the freshly created subclass
> active_resource_object = active_resource_class.new(:id =>
> element_id) # set id to given element id. This way we don't have to
> load the element first by using find -- but we won't know, if the
> element exists
>
> # do the action...
> active_resource_object.put(action)
>
> # reply to the engine
> reply_to_engine(workitem)
> end
> end
>
>
> (don't wonder ActiveResource isn't required, I'm using Ruote inside
> Rails.)
Maybe this participant could be called "ActiveResourceParticipant"
since it's ARes specific (though active resource compliant servers got
be used as well).
> For me, this implementation works fine, but I'd like to make it more
> general usable: Not only PUTs should be possible, but all other REST
> actions. I'm thinking of replacing
> active_resource_object.put(action)
> by
> active_resource_object.send(rest_method, arguments)
Indeed, makes sense. Would you consider "donating"/"contributing" this
code to OpenWFEru / Ruote ? It could be placed under
lib/openwfe/extras/participants
(http://github.com/jmettraux/ruote/tree/master/lib%2Fopenwfe%2Fextras%2Fparticipants),
adding a few tests could be feasible with some ARes mocking.
I did some exploratory work on "REST" methods inside of process definitions :
http://jmettraux.wordpress.com/2008/05/27/restful-bpm/#more-445
http://github.com/jmettraux/ruote/tree/master/lib%2Fopenwfe%2Fexpressions%2Ffe_http.rb
but I'm not really convinced by my own approach. Somehow, wrapping
things inside of participants like you're doing feels better.
> In this context I'd like to know if there is a possibility to use
> hashes or arrays as attributes in the xml definition of a workflow?
> Something like
> <participant ref="reminder" action="put" arguments="{:action =>
> 'send_reminder', :some_parameter => 'foo'}" />
> ?
Please have a look at this test (and the adjacent tests) for a
suggestion of how you could do that :
http://github.com/jmettraux/ruote/tree/master/test%2Fft_57_a.rb#L147-167
This test wraps some JSON inside of the XML process definition.
Thanks for using Ruote, your questions, suggestions and contributions
are welcome, best regards,
--
John Mettraux - http://jmettraux.wordpress.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"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
-~----------~----~----~----~------~----~------~--~---
