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
