Hi Matt, On 7/11/07, Matt Zukowski <[EMAIL PROTECTED]> wrote: > > This is mainly aimed at John M, but I figure I might as well post this > here rather than through private correspondence.
Yes Matt, this is the way to go. These are important questions that deserve to be answered and archived. > As you (John) know, I'm writing a Camping-based server (Fluxr) that > will act as a front-end for OpenWFEru. The server will be responsible > for launching workflows, reporting on their status, etc. Looking forward to see it. > One use pattern I see in our immediate needs is for a workflow to stop > and wait for some external event. So for example, the Camping server > receives an order to launch a workflow, and the workflow progresses up > to a point (for example, a branch) where it must wait for an external > trigger or for some additional external input data. I'm looking for > some opinions as to the best way to implement this. Usually the "external trigger" thing is embodied by the engine sending a workitem to an external participant (or a 'store' participant) and waiting until the participant replies. That's the easy way. The ParticipantExpression 'participant' is designed to wait for answers. So 'wait' and 'when' are really advanced constructs for special scenarii, don't worry about them for now. Maybe have a look at this unit/functional test where a StoreParticipant receives workitem and the engine patiently wait for someone else to 'forward' /'proceed' the workitem before resuming that process instance : http://viewvc.rubyforge.mmmultiworks.com/cgi/viewvc.cgi/trunk/openwfe-ruby/test/hparticipant_test.rb?root=openwferu&view=markup > I know that OpenWFEru has a when/wait expression, so it probably makes > sense to use this to wait for external events. However, the way I > understand it, OpenWFEru creates a separate process for each workflow > launched, and this process keeps running until the workflow is > completed. Yes and No. Yes if by 'process' you mean 'business process instance'. No if by 'process' you mean 'operating system process' or 'thread'. At its heart OpenWFEru has a workqueue where operations for all the running process instances are queued and processed by one work thread (maybe later, future implementations may benefit from better threading in Ruby 2.+). > Since the event could be triggered days or weeks later, I'm > weary of keeping all these processes running. Instead, I'm wondering > if it might make more sense for the Fluxr server to persist the > workflow's state and shut it down. It would then be up to the Fluxr > server to listen for the trigger event, and re-instantiate and resume > the workflow from the persisted state. This is all handled by OpenWFEru for you (as long as you use a persisted implementation of the engine, like OpenWFE::CachedFilePersistedEngine). The engine is implemented in a way that it can wait for long time, be stopped and restarted and still be waiting for those 'external events' (or simply for a sleep expression to wake up). > Is this the right way to go? What would you suggest as the best way to > do this? I'm not exactly sure how I could go about pausing, > persisting, and then resuming an entire workflow in mid-process... the > fact that this seems difficult makes me wonder if I'm going about it > the wrong way. Yes, this is difficult, but that was my task to implement it. Now it's your turn to build something nice and fancy on top of it. pausing, persisting, resuming, this is all taken care by the engine. You have to provide decent participant implementations and decent process definitions. > Also, I realize that wrapping the OpenWFEru engine inside a Camping > server is a bit redundant, since OpenWFEru is meant to act as it's own > server (hence the old REST interface), but I think the added layer of > abstraction between the web application (i.e. Camping) and the > business process executor (i.e. OpenWFEru) makes sense. I think it's not that redundant, I think it makes sense. OpenWFEru is either standalone, either embedded. With ActiveResource now maturing it's good to be embedded within a web application framework (rails or camping) and be accessible via a human web interface or a REST (ActiveResource) web interface. Don't look at the old REST interface, I have implemented it, hoping someone will use it, but maybe I was wrong. It's better to look at something more RESTful built on top of ActiveResource. Look forward. So I think that your idea of wrapping OpenWFEru inside of Camping makes complete sense and I'm happy to help you with that. Your questions are welcome, don't hesitate to ask more detailed question about the working of the engine. Best regards, -- John Mettraux -///- http://jmettraux.openwfe.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
