[Zope-CMF] Project-style workflows, DCWorkflow, SQL, etc.

[Kent Polk]

Shane Hathaway wrote:
> 
> I also need to understand activity-based workflow better.  Let's compare 
> the two approaches, maybe that will help.
> 
> - How do you begin a workflow?  With DCWorkflow, you create an object 
> and it is automatically put in an initial workflow state.
>
> - How does the user interact with workflow?  With DCWorkflow, the CMF 
> actions box is populated with actions corresponding to transitions.

Most of our workflows will start with a request to perform some
action. This action may be to create a document or other cmf item,
or to simply respond to the request with information. Or it may be
to start the creation of some collaborative project. The thread of
actions in the workflow should be represented by a status diagram
(dtml tree layout would be sufficient, I believe).

The simplist example might resemble an informal email exchange or
collection of email exchanges. The status diagram would report the
initial request, its status, and all other requests that were issued
as children of that first request.

The next level would apply specific constraints that must be met
before requests are completed. While possibly DCWorkflow might
suffice, I believe I need something that is easier to understand
and configure to accomplish this. Possibly a superset of DCWorkflow.

> - How do you implement subflows?  With DCWorkflow and the portal_types 
> tool, you can set up objects that get stored in workflowed containers. 
> The contained objects can have partially dependent workflows.

This is (IMO) the big difference between entity based and activity
based workflow. With activity based, you don't need to create some
Item to have a workflow, and indeed, much workflow doesn't revolve
around creating items, but mainly passing information around, often
resulting at different points in creating both temporary as well
as permanent informational items.

Activity-based subworkflows are not (necessarily?) related to a
created item, but to a request that someone or something is waiting
on or for.  This is where Philip's 'waiters' concept comes in. At
any point in an existing workflow, another request can be issued
- for more information or for some additional requirement to be
issued/created. When this request is issued, it is somehow attached
to it's parent request or waiter so a status diagram can explore
and report on these relationships.

 View Status:

        item name   status                 actor
    [+] Req 1       Received  12/15/2000    jfk 
    [+] Req 2       Requested 12/14/2000    gwb
    [-] Req 3       Received  12/14/2000
     [+] Req 4      Completed 12/15/2000    ---  (limit sub-wf view)
     [+] Req 5      Received  12/16/2000    ---
     [+] Req 6      Rejected  12/15/2000    ---

> It sounds like you're saying activity-based workflow is more appropriate 
> for large, complex processes, while a simple state machine is more 
> appropriate for simple things.

Yes! And likely the current item-specific state-machines can be
used when an item is created as part of an activity-based workflow
(or maybe overridden when needed).

> I still hold the opinion that if your workflow is too complex for a 
> simple state machine, it really ought to be modeled using a programming 
> language.  Python, which is flexible, portable, fast, easy to 
> understand, and easy to write, would be a good choice. ;-)

Quite possibly so. But I still think that a framework is better,
and I think one should be able to specify/configure the relationships
separate from the code, so it looks like we are back to something
like DCWorkflow.