On Fri, Nov 02, 2012 at 05:43:45AM -0700, Karl Falconer wrote: > > On Thursday, November 1, 2012 10:22:37 PM UTC-4, John Mettraux wrote: > > > > if the _worker participants were wrapping the code for updating orders. > > > > Just an exploration, not fitting your requirements exaclty > > (store/warehouse > > are modelled as humans). I hope it's OK. > > > > The first step (cron job to pull orders from store) could be skipped if > > the > > store would launch the workflow immediately. > > Can you expand on this a bit more? Are you saying have a second process def > with a single task to get new orders, and have it run/re-try indefinitely? > Would I need to launch a process def for each store at application start? > > Currently the cron job is polling a web service for new orders. I imagined > that after orders were found, the Store would launch the workflow for each > order that was saved. A single store could import as many as 100 orders at > a single time.
Hello again, sorry, let me rephrase/explain. I was thinking the store was emitting the order by placing them in the DB, and then the cronjob was pulling them. I had the impression this could be simplified by the store launching workflows immediately. Those batch operations are more reliable and easier to grasp than workflows. > So I could create 3 worker instances all pointed to the same storage. This > would enable the proces def's to run in parallel. And I am assuming, the > workers would cycle through all of the items on the queue until each item > was complete. In reality, I shouldn't need to have more than one worker if > the web service calls are executed quickly enough. Yes, exactly. > > It sounds right. In the bigger picture, it's probably missing a "receiver" > > to > > listen for events/messages/workitems coming back from the Warehouse. > > > Again, here I am polling with a cron job to update the order status for all > the orders at each warehouse, after which I intended to invoke the process > def to continue working on the order. Are you suggesting a better > alternative is to use a receiver. Looking at the Beanstalk sample, I am not > sure how a receiver would work in my case, can you expand a bit? Well, somehow, after thinking more about it, I think your cron jobs make excellent "receivers" by themselves. You could move from cron jobs to ruote receivers, but it's better if you stick with known and proven tools. Sorry for the confusion, best regards, -- John Mettraux - http://lambda.io/jmettraux -- 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
