On May 15, 4:29 pm, John Mettraux <[email protected]> wrote: > Hi Marc,
Hello John > thanks for your remarks about the documentation. Any help/feedback is > welcome. Let me correct what I said, because of course, just after my first post, I went back to the documentation and found out that they're actually is an example of how to use a worklist... it's in the mano_tracker.rb example, but at first glance I didn't realize that a "store" is a synonym for "worklist". Be sure I'll be glad to help I have the chance in the future (until you get bored of my remarks :) ) > There is no clear solution... We cannot take architectural > decisions for all the readers... Users know better than me how to walk > their last mile. Don't get me wrong, I wasn't asking for the solution to my problem, but for hints about how to begin with. Think of me as a user asking for directions before walking a few dozen miles :) > 1) block participant > > engine.register_participant :process_file do |workitem| > Lib.process_file(workitem.attributes[:filepath]) > end > > + simple > - what if it fails ? (stalled expression issue) > - may slow down the whole engine The failure isn't a problem for me (it can be elegantly handled with the external tool), but I surely do not want to slow down the engine of wait for the lib to answer before moving on.. anyway, I never thought of it as the good way to handle my process, but I needed a second opinion. > 2) via a 'worklist' > > engine fires workitem to database (see ar_participant), where it's > picked by another process with does the process_file. When done, the > other process removes the workitem from the db and pings back the > engine (HTTP, file or socket listener, ...) > > + separates engine from agent > +/- many agents may read db, have to arbitrate which one picks the workitem > - requires setting up and maintaining db > > http://github.com/jmettraux/ruote/blob/master/lib/openwfe/extras/part... > http://github.com/jmettraux/ruote/blob/master/lib/openwfe/listeners/l... > > 3) via XMPP, AMQP or SQS (queue) > > engine and other process communicate via a queue. > > + separates engine from agent > + many agents may read the queue > - requires setting up and maintaining queue > > http://github.com/jmettraux/ruote/blob/master/lib/openwfe/extras/part... > http://github.com/jmettraux/ruote/blob/master/lib/openwfe/extras/part... > > http://github.com/jmettraux/ruote/blob/master/lib/openwfe/extras/list... > http://github.com/jmettraux/ruote/blob/master/lib/openwfe/extras/list... > > 4) web service > > + separates engine from agent > + other application may use agent > - maybe have to secure agent > > engine posts job to agent via HTTP, agent replies via HTTP when job is done. > > I wouldn't go with 1. Block participants are meant for simple, > one-shot participants. Having a separate agent/process or set of > processes. > > I would go with one solution and then after a while refine it. It's > just ruby code in the end, easy to throw away / rewrite and so on. Thank you so much ! I'll look into this and the AMQP participant/listener Kenneth mentionned. And yes, this is one of the many things I like about Ruby, being able to quickly correct and retry. > I've just seen Kenneth's reply, it's excellent. Thanks Kenneth ! Maybe > this requirement of Marc needs to be considered as a single step in > some bigger "business process" and the details of it abstracted away > from the engine. Again, thank you Kenneth and John for your advised answers. It will surely take me a few days of tests when I get back, but be sure I'll try to give you a clear feedback. Best regards, Marc --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
