I feel you with the business -> dev disconnect regarding your business process specifications. That can be a nightmare. We went through the same type of transformative process you're proposing embarking on and it has worked out pretty well. We use lucidcharts.com to document our business processes in the form of flowcharts and are strict about requiring the business to communicate their needs to us via these diagrams. Our part of the deal (development) is that our workflows will replicate the flowcharts. If they don't, then it is a bug. However, if our system matches the flowcharts, then it is up to the business folks to adjust the flowcharts so that things work the way they want and we'll adjust our ruote code to match, so there is no gray area about whether the software is broken or the business processes are under or improperly specified.
Anyway, that digression aside, I think it is an excellent idea to model your business processes via ruote as a method of formalizing the contract between the business processes and the software. We have found ruote can faithfully represent, one to one, about anything you can put into a flowchart. We also use a state machine gem, however, to manage the state of our business entities. Each state an object can be in is associated with a ruote workflow (which can launch any number of parallel workflows). So state transitions in the state machine control the launching (and often cancelling) of ruote powered business processes. On the flip side, ruote may request a state transition, or direct a user to cause a state transition through some user interface action. This arrangement works out pretty well. I can't imagine using a state machine without the sequential workflow support of ruote (we tried it and it was awful) and I can't imagine using a sequential workflow system like ruote without some kind of state machine. I see them as independent but both necessary functions that work well together. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of R Law Sent: Monday, August 15, 2011 3:05 PM To: ruote Subject: [ruote:3221] Re: conceptualizing state machine-like application as ruote workflow The model is called Submission and it keeps track of a variety of documents (the manuscript, cover letter, forms, etc). Statuses are tracked by an ad hoc "state machine" mixin. It's not really a state machine but a bunch of code spread out across the entire app (e.g. submission.reviewers.map{|r|r.status = "given_up"} if submission.status == "accepted") The problem we have is that there is no enforced workflow--i.e. a Submission can jump from "published" to "started" or vice-versa. Also, states are not changed automatically and therefore tend to get out of sync with respect to the actual business objects. Some processes happen offline and are not reflected in the history. The users of this app think in terms of assigning statuses instead of actual workflow. I would like to refactor this in an attempt to make the code more closely reflect reality and thereby improving both the code and the users' conceptions. The stakeholders haven't clearly defined their workflow yet and out of that confusion came a lot of sloppy and inconsistent code. Hopefully the exercise of defining a workflow in the code will help us all see things more clearly. I appreciate your honest advice not to rush into ruote. We could definitely improve things by using a real state machine such as rubyist_aasm. But the workflow engine model seems to provide a lot of benefits such as versioning and the ability to produce transactions in more than one model. Thanks, Reed On Aug 15, 4:34 pm, John Mettraux <[email protected]> wrote: > On Mon, Aug 15, 2011 at 11:37:11AM -0700, R Law wrote: > > > I've spent several hours reading docs, blog posts, and examples, but > > it's conceptually still a long way away. Our app uses state machine- > > like rules to track the status of various Active Record models. I > > think ruote is a great fit for this app (it's a document review > > system--just like the first example process in the docs), but I'm > > struggling on how to re-write everything as a workflow engine. > > > Our app has a model that keeps track of most of the workflow. When > > managers want to see the progress on each document, we query this > > model's status. Ruote should work fine as a replacement for nearly > > all the statuses, but once a process is finished, how should we > > query for documents that are in their final states (either > > "published" or "rejected")? Do we have to continue to store these > > states within the model? Or do we keep processes running forever? > > Hello, > > there is something ambiguous (for me) in your description. Is the state > attached to that separate model or to the document itself ? > > If you have a model pointing to a business object (like a document) with a > state attached to this model, you already have something strong. > > If the state is attached directly to the business object, it implies the > object is only in one state at a time. If the state is attached to an > external model, there could be multiple states pointing to the same object. > > If the state is attached directly to the business object, you could use ruote > to switch/swap states when necessary. To know the state of the thing, you > simply ask to the object. To know in which process an object is currently > involved you could query ruote (or keep tracks of ruote workflow instance ids > in the business object). > > Ruote is more about handing tasks to participants. You hand the task "review" > to the participant "Tony" and when he's done, you can incidentally change the > state of the document to "reviewed". > > > Another issue is how to keep track of the histories of each process. > > Should that be done separately? > > There is a HistoryStorage which might be used as is or adapted. > > https://github.com/jmettraux/ruote/blob/master/lib/ruote/log/storage_... > > Maybe this search may help > > http://groups.google.com/group/openwferu-users/search?group=openwferu... > > Now it depends if you want to keep the history per object or per process (or > both). > > Maybe don't rush into ruote, after all you already have a working system in > place. Try with a small system first. > > Best regards, > > -- > John Mettraux -http://lambda.io/processi -- 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 -- 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
