Derek, Thanks for the links.
My model handles parallel flows through the state links table. On Thursday, May 17, 2012 6:42:27 PM UTC-4, Derek wrote: > > 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? :) >> >
