I think you are just using abstract examples, though workflows are more than just creating a widget or approving invoices. The standard for workflow support is here: http://www.workflowpatterns.com/ (look here for a tidy list of workflow types... http://www.workflowpatterns.com/evaluations/opensource/) If your workflow engine can support all those patterns, then you have an all-purpose workflow. They've thought about this problem longer than any one of us have, so take a gander before you write your workflow engine.
Also, Fantasm is another workflow engine that works with Python (and GAE) though I'm not certain if GAE is optional or not. It might be worth checking out to see how that works. https://developers.google.com/appengine/articles/fantasm It appears you are planning on supporting sequential workflows, but what about "parallel split"? say you have an image file and you need to have a workflow such as this: reviewer (reviews image - if it is appropriate, approve and move to next stage which is split in two parts that operate in parallel) >art director - enhances image, fixing color balance, etc etc... >classifier - reviews content of image, adds tags for the website, advertising, etc then it goes to the next stage only after the preceding two are complete (which may be done in any order). The art director doesn't care if the art has tags, so his work doesn't need to wait on that, and the guy doing the tagging could care less if it matches the rest of the website design...however they both have their own separate and independent jobs to do. there are a lot more workflow patterns than those. In the example of "6 approvers" - if one of the first approvers has a sick day, the other 5 guys won't be able to do any work. With multiple parallel tasks, the rest of the guys can keep working, though nothing will be complete until the sick guy comes back. On Thursday, May 17, 2012 2:16:17 PM UTC-7, Ross Peoples wrote: > > > > On Thursday, May 17, 2012 3:54:44 PM UTC-4, Cliff wrote: >> >> Let's inject manufacturing into the order processing scenario you were >> using before. It's a three step process. Step one fabricates widgets. >> Step 2 attaches the widgets to widget bicarackets, purchased from another >> vendor. Step 3 packages the assemblies for shipment. >> >> If the last batch of widgets from the fabricator won't fit the brackets >> because they are oversize, obviously the guy in assembly wants to send them >> back for rework. How would the system handle this? >> > > In this case, assembly would reject their step, and enter a short message > to explain why they rejected it. Assembly would also select a previous step > in the workflow to send it back to, in this case the fabricator (step 1). > The message from assembly goes into the workflow_comments table as needing > to be resolved. Once the fabricator fixes the problem, they mark the > problem resolved and send the workflow on to the next step (which in this > case would be to step 2). > > >> >> And how would it avoid forcing the guy in charge of assembly to take >> action on every batch of good widgets, assuming the system's intent is to >> manage by exception? >> > > Let's say the guy in assembly has 5 work orders to assemble for the day > and each work order makes 20 assemblies (for a total of 100 things to make > for the day). He would come in with the parts waiting for him for all 5 > work orders, and he would have 5 workflows waiting on him. When he > completes one work order (20 assemblies), he marks that workflow as > completed and the workflow moves on to the shipping department. If we > wanted, we could even add a "progress" field that allows him to enter a > percentage of how close he is finishing the 20 assemblies for the one work > order. > > The great thing about doing it this way is allows management to track > where everything thing is. My implementation puts an emphasis on > accountability and making sure nothing gets lost or forgotten. Most > manufacturing places have computers on the floor, so asking the assembly > guy to click a button isn't a stretch for most places. In fact, by making > this whole implementation generic like this, you could even put a simple > keypad out there in assembly, shipping, and other places that don't have > full computers to manage workflows. > > Nothing about the implementation forces you to use a GUI. You could > program a keypad to accept a work order number that marks the associated > workflow as complete via a REST call or something. And worst case, you > could always have the assembly supervisor handle the workflows for the guys > in assembly. That's what supervisors are for, right? :) >
