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

[Vincenzo Di Somma]

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.


In OpenFlow after the creation of  a process map, the starting
application generates a process  instance (called Token for the
moment, but which will be soon renamed ProcessInstance)  that starts 
from the
activity of "begin" kind.

 > - How does the user interact with workflow?  With DCWorkflow, the CMF
 > actions box is populated with actions corresponding to transitions.


The interaction between workflow and the user is basically a task 
assignment.
There are two task assignment metodology, the "pull" and the "push".
With the "pull" the system offers to the user a list of task, depending
on his roles, and user chooses what to do first. For the moment is the
only methodology OpenFlow supports.
With the "push", another user or the system assign a task specifically
to a user.
The user interacts with its "ToDoList" (that will be renamed "WorkList" in
the next release). In this list the user will find the task he has to do
and the links to the applications.

 > - 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.

Subflows (and loops) are simply process maps, like the others. OpenFlow
will support subflows and loops in the next release.

 > - If the model doesn't support some capability, how do you fit it in?
 > DCWorkflow lets you use persistent variables, expressions, and scripts.
 >  (We both know WfMC, nor anyone else, can create a perfect model that
 > lets you do everything.)

In the same way as DCWorkflow :)

 > I've been keeping track of OpenFlow and WfMC, but frankly, it took less
 > time and effort to write DCWorkflow than it's taking to make sense of
 > WfMC. :-)

Regarding WfMC docs you`re perflectly right :) I`ve spent a lot of time
trying to understand the meaning of some specifications, but as I said 
before, maybe MfMC interfaces are not the smartest, but, IMO, a good
starting point.

Regarding OpenFlow I`m sorry, maybe our code and docs aren`t as clear as
we think they are, we`ll try to make them better, all comments are 
welcome :)

 >> IMO, there are situations in which follow the status changes of an
 >> object is all you need for your application, but often the activity
 >> based workflow are the natural way to describe business processes and,
 >> for great or strange process, the fastest way to design the flow. Lots
 >> of problems described in the thread find simple solutions with this
 >> approach.Companies, often, have well defined (and activity based)
 >> procedures and they wants applications that can help them to work
 >> better. So you have a good description of their processes when you
 >> start your work, what is the advantage of remap the activity based
 >> processes in entity based?
 >
 > 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.

 > 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. ;-)

What I mean is that there are problems you can easily solve with 'entity
based', problems you can easily solve with 'activity based'. If we offer
both we surely help more developers in createing applications without 
python coding.

 > But maybe there are companies ought there who are already sold on WfMC's
 > workflow concepts and don't want to move.

Maybe but, if we give them familiar tools maybe they will appreciate all
the rest, have to say, some IT  companies and universities, are 
following OpenFlow development and the main reason is his WfMC inspiration.

 >> Moreover, a fundamental workflow function is the processes, activities
 >> and eployees, monitoring and statistic reports, important because
 >> helps quality enanchements, process optimizations and offers good
 >> corporative decisions support. Can 'entity based' approach offer this
 >> features with the same flexibility of the 'activity based' ?
 >
 > I can answer the question, "Can 'entity based' approach offer these
 > features?"  The answer is certainly yes.  I can't answer the question
 > you asked, however, because I have not used any tools based on the WfMC.
 >    Besides OpenFlow, what tools are there?  (Preferrably open source.)

I`ve seen lots of opensource projects but most of them are ad hoc
workflows or in early development state. There are instead many 
commercial workflow management system like Plexus Floware www.plx.com 
and Ultimus www.ultimus.com. If this could help tell me your 
diffuculties with using OpenFlow so I can understand the usability 
problems and you could have an idea of an activity based workflow 
paradigm. What do you think about ?


 >> The last thing I want to consider is that the most important
 >> commercial WfMS are tryng to hide lots of implementative details to
 >> the users and even to the developers, giving them natural tools to
 >> develop workflow based applications. IMO excluding an important design
 >> approach as the 'activity based' is, can make work more difficult for
 >> a lot of developers who use commercial system and are searching for
 >> good opensource workflow tools till they will not use it at all.
 >
 > Then do you agree that the goal is to integrate OpenFlow into CMF?

I think it will be a good idea to have an 'activity based' togheter
with an 'entity base' workflow. We are working hard on OpenFlow and
I think the next release (0.5) will be a mature activity based workflow
engine, so if is interesting for you to add an activity based workflow 
in CMF we will be pleased to collaborate.

-- 
Vincenzo Di Somma - Responsabile Ricerca e Sviluppo - Icube S.r.l.
Sede:   Via Ridolfi 15 - 56124 Pisa (PI), Italia
E-mail: e.disomma@icube.it              WWW: www.icube.it
Tel:    (+39) 050 97 02 07              Fax: (+39) 050 31 36 588