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

Vincenzo Di Somma e.disomma@icube.it
Fri, 12 Oct 2001 18:20:02 +0200


Phillip J. Eby wrote:

 > At 02:21 PM 10/12/01 +0200, Ulrich Eck wrote:
 >
 >> As far as I can see right now, it would be good to create a new tool
 >> e.g. portal-activity/portal-task or whatever it will be called.
 >>
 >> This tool holds different process-definitions and is based on the
 >> portal-worklfow-tool (optimally the interface could be used
 >> without major modifications).
 >>
 >> I see the activity-tool as a coordinator for Application-objects
 >> that internally use the portal-workflow (DCWorkflow/hardcoded ...).
 >>
 >> The activity-tool leads the participant to the application/task which
 >> is finished when it reaches a certain state. Then transitions defined
 >> in the activity-tool can be made (manually/automatically).
 >>
 >> Worklists can be used to determine which activities are open depending
 >> on the participants information of a ProcessDefinition.
 >>
 >> A participant can be a person/group/machine.
 >>
 >> Does this alltogether make sense ??
 >
 >
 >
 > Not to me, but I'm probably blinded by viewing this through the lenses
 > of my "waiter-for" model perspective.  What you're saying above sounds
 > like overkill to me, as I don't think it's necessary to modify the
 > existing CMF at all in order to do more complex workflows.  At most,
 > DCWorkflow might need some extra features, but I'm not sure even that
 > would be necessary.


Hi all,
First of all, sorry for my english :)

I`m an OpenFlow developer and I`m very interested in this discussion, I 
don`t want to start a flame, I`ve good experience in 'activity based' 
workflow but not to much in 'entity based', so it could be interesting 
for me to understand this approach.

We`ve started the OpenFlow development following as much as possible the
WfMC interfaces (and, in the next release we`ll do it better) because, 
even if it isn`t the smartest way, is certainly stable, well tested, as 
much general purpouse as possible and is often well appreciated by the 
customers who fells itself more guaranteed.

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?

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' ?


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.

All comments are welcome ;)

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