Re: [Zope3-dev] Community opinion about workflow engine
Stephan Richter wrote: class Application(Contained, Persistent): ... @apply def stati(): See IApplication def getStati(self): return self._stati def setStati(self, value): removed = set(self._stati) - set(value) added = set(value) - set(self._stati) self._stati = tuple(value) for item in removed: zope.event.notify(StatusRemovedEvent(self, item)) for item in added: zope.event.notify(StatusAddedEvent(self, item)) return property(getStati, setStati) Apart from the quite confusing spelling of this property (I suggest something like http://cheeseshop.python.org/pypi/rwproperty for better readability), I just wanted to point out that stati is an incorrect Latin plural for status. The plural is simply status (the u being long in the plural, as opposed to being short in the singular). But as far as I know, the only accepted plural form in English is statuses. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Community opinion about workflow engine
Hi Godefroid One of the questions we are exploring is : which workflow engine should we use/expand on ? Draw the workflows as UML state diagrams if at all possible. Go with DCWorkflow as far as it takes you. Then fix ArchGenXML to generate code or GS XML for the next workflow engine you'd like to move to from the same UML. -- jean . .. //\\\oo///\\ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Community opinion about workflow engine
Hi Godefroid,
CCing zope3-users, where this post belongs to.
On Monday 12 March 2007 11:48, Godefroid Chapelle wrote:
- about the existing workflows (DCWorkflow, Zope3.wfmc, AlphaFlow,
OpenFlow...)
Kit asked the question about workflows on the SchoolTool list as well; I
assume that you guys are working together.
I have personally found that workflow engines are ususally overkill. In fact,
I think document/content publishing as it is done in Zope 2 CMSs is one of
the exceptions.
In SchoolTool we decided early to use a workflow engine to enforce process. We
have found there that it was overkill. (Everyone else can read Tom's comment
on the SchoolTool-Dev list.)
That said, here is my experience from another customer. This customer asked us
to rewrite a job application management software. You can easily see the
common workflows there. However, her complaint about the old system was that
the workflow was too stiff and she wanted to change the list of stati of a
particular application at any time manually, effectively breaking the
workflow.
With those requirements in mind we looked at our options, and she wanted to
deliberately break the flow we decided against any workflow engine. Instead,
we implemented stati as a special property of the application. Whenever the
stati are changed, we fire events for each added status and another event for
each removed status. We then created a module called policy that contains a
multitude of event subscribers listening to the events and doing the work.
Those tasks include writing logs, sending E-mails, triggering other status
changes, security changes, and data verification. Here is some of the
interesting code:
application:
class Application(Contained, Persistent):
...
@apply
def stati():
See IApplication
def getStati(self):
return self._stati
def setStati(self, value):
removed = set(self._stati) - set(value)
added = set(value) - set(self._stati)
self._stati = tuple(value)
for item in removed:
zope.event.notify(StatusRemovedEvent(self, item))
for item in added:
zope.event.notify(StatusAddedEvent(self, item))
return property(getStati, setStati)
policy:
@zope.component.adapter(interfaces.IStatusRemovedEvent)
def historyApplicationStatusRemoved(event):
log(
event.object,
_('Status Removed: $status', mapping={'status': event.status}))
# Not reacting to a status change, but nevertheless interesting to look at.
# Yes Martijn, I love hurry.query!
@zope.component.adapter(interfaces.IApplicationCompletedEvent)
def applicationCheckForDuplicate(event):
# When upon completion of the application, another application with same
# last name, first name and birth date is detected, then this application
# is marked as duplicate
app = event.object
duplicateQuery = query.And(
query.value.Eq(('app-catalog', 'firstName'), app.firstName),
query.value.Eq(('app-catalog', 'lastName'), app.lastName),
query.value.Eq(('app-catalog', 'birthDate'), app.birthDate),
query.query.Not(
query.set.AnyOf(('app-catalog', 'stati'),
(interfaces.INCOMPLETE,))
),
)
result = tuple(query.query.Query().searchResults(duplicateQuery))
# Only mark applications as duplicates, if the application is not itself
if (len(result) == 1 and app not in result) or len(result) 1:
app.stati += (interfaces.DUPLICATE,)
So in fact, our workflow engine is the Zope 3 event framework. I like it for
the following:
- There is no new framework overhead; use what you know.
- It is maximally flexible. I have control over the way I implement the
business logic and the UI.
- Having all policy in one place (this includes event subscribers to other
events as well) provided great oversight. Whenever the customer asks
me: What are the rules for this behavior? (even though she specified it, of
course), I can just go to this one place and give her an answer within a few
minutes.
- Easy to test. It is very simple to test each event subscriber in isolation
and go through all the cases.
I guess I would not have to say it again, but I really like this pattern.
Regards,
Stephan
--
Stephan Richter
CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Community opinion about workflow engine
Hello Godefroid, I'm having a bit biased view, because I know just zope.wfmc and have the luck developing a pure Z3 application. I think with zope.wfmc you have - WFMC/XPDL support, you can shine with standards and big companies love standards - because it's XPDL support there's a graphical process editor jpEd - the core itself is quite sophisticated, but still misses some things for complete WFMC coverage (the WFMC spec is rather huge) - you can/should add some layers on top of it: - z3c.wfmcpersistent to store the processes in ZODB - ecm.workflow to have a higher level of APIs and functions (That was written by Roger Ineichen, but as nuxeo moved to jboss it was not maintained by them. Therefore I intend to move that code to z3c.wfmc, when I have some time to breathe. I have some improvements to the code. We even have plans to implement time management or scheduling with the package) All in all we're quite comfortable with zope.wfmc in our project. The project is about document management, also a bit of administrative thing. Monday, March 12, 2007, 4:48:24 PM, you wrote: Hi all, We have the opportunity to bid for a project concerning the automation of administrative processes. The client currently has software in Python and Zope/Plone. They are quite explicit that they want their new applications to be built as much as possible with a mix of generic shareable modules and of custom modules. This is a quite big project that, among others, includes the aspects of collaboration with / support of the community. One of the questions we are exploring is : which workflow engine should we use/expand on ? In order to help us make a proposal, we would be very interested to hear your comments both - about the existing workflows (DCWorkflow, Zope3.wfmc, AlphaFlow, OpenFlow...) - or about the directions that you would suggest in order to help you use a given engine (missing features, simplification,...) and join the effort to improve one of the existing engines. Thanks -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Community opinion about workflow engine
Hi all, We have the opportunity to bid for a project concerning the automation of administrative processes. The client currently has software in Python and Zope/Plone. They are quite explicit that they want their new applications to be built as much as possible with a mix of generic shareable modules and of custom modules. This is a quite big project that, among others, includes the aspects of collaboration with / support of the community. One of the questions we are exploring is : which workflow engine should we use/expand on ? In order to help us make a proposal, we would be very interested to hear your comments both - about the existing workflows (DCWorkflow, Zope3.wfmc, AlphaFlow, OpenFlow...) - or about the directions that you would suggest in order to help you use a given engine (missing features, simplification,...) and join the effort to improve one of the existing engines. Thanks -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Community opinion about workflow engine
On Mon, 12 Mar 2007 11:48:24 -0400, Godefroid Chapelle [EMAIL PROTECTED] wrote: Hi all, We have the opportunity to bid for a project concerning the automation of administrative processes. The client currently has software in Python and Zope/Plone. They are quite explicit that they want their new applications to be built as much as possible with a mix of generic shareable modules and of custom modules. This is a quite big project that, among others, includes the aspects of collaboration with / support of the community. One of the questions we are exploring is : which workflow engine should we use/expand on ? In order to help us make a proposal, we would be very interested to hear your comments both - about the existing workflows (DCWorkflow, Zope3.wfmc, AlphaFlow, OpenFlow...) dcworkflow simple to use, well known, needs extension via custom guards and triggers to accomodate alot of workflow customization (send email, route to manager, etc.) zope3.wfmc.. abstract, potentially powerful, but imo, needs quite a bit of code to make anything non trivial functional. alphaflow.. i like the best as an architecture (ignoring AT implementation), i think that investing time rewriting it on z3 concepts would be time well spent, it has flexibility, a library for common actions, supports organizational workflows much better, and is model complete in terms of constructs to model conceptual workflows. openflow.. nothing to say. depending on your timeline.. of the two worth investigating, i would recommend alphaflow and z3.wfmc two cents, -kapil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Community opinion about workflow engine
Hi, this definitely invites for some biased commenting. ;) Am Montag, den 12.03.2007, 16:48 +0100 schrieb Godefroid Chapelle: Hi all, We have the opportunity to bid for a project concerning the automation of administrative processes. The client currently has software in Python and Zope/Plone. They are quite explicit that they want their new applications to be built as much as possible with a mix of generic shareable modules and of custom modules. This is a quite big project that, among others, includes the aspects of collaboration with / support of the community. One of the questions we are exploring is : which workflow engine should we use/expand on ? In order to help us make a proposal, we would be very interested to hear your comments both - about the existing workflows (DCWorkflow, Zope3.wfmc, AlphaFlow, OpenFlow...) AlphaFlow is currently on the trip to version 2.0. We've been removing support for older Plones (2.0, 2.1) and are running on Plone 2.5 now. Additionally, we'll feature an extension of the architecture to fix the problem that workflows become crowded of technical activities by introducing aspects. Those will allow the control flow itself to stay focused on the business aspects of the workflow and annotate the start and end(s) of an activity with aspects (like changing security etc). The existing activities will stay or be converted into aspects. Check the doc/proposals directory in AlphaFlow to find out a little bit more about this. Additionally we finally will support editing workflows visuall. We gave up on the creation of our own visual editor and will support importing external formats into AlphaFlow. Due to a customer project we start by providing an import for Microsoft Visio XML. Unfortunately we can not just rewrite the whole thing for Zope 3 and then make it work with Plone again at once. When implementing the new features we are going to use as many Zope 3 technologies as possible, though. Some things, like AT, are going to stay for a while though. :/ We'd be happy to help you if you have any questions regarding the use of AlphaFlow of course. We have an extensive list of issues we had when pondering DCWorkflow and OpenFlow for a project that reasons why we did not choose them. Google should have a copy of one of my talks somewhere. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Community opinion about workflow engine
Am Montag, den 12.03.2007, 12:16 -0400 schrieb Kapil Thangavelu: On Mon, 12 Mar 2007 11:48:24 -0400, Godefroid Chapelle [EMAIL PROTECTED] wrote: Hi all, We have the opportunity to bid for a project concerning the automation of administrative processes. The client currently has software in Python and Zope/Plone. They are quite explicit that they want their new applications to be built as much as possible with a mix of generic shareable modules and of custom modules. This is a quite big project that, among others, includes the aspects of collaboration with / support of the community. One of the questions we are exploring is : which workflow engine should we use/expand on ? In order to help us make a proposal, we would be very interested to hear your comments both - about the existing workflows (DCWorkflow, Zope3.wfmc, AlphaFlow, OpenFlow...) dcworkflow simple to use, well known, needs extension via custom guards and triggers to accomodate alot of workflow customization (send email, route to manager, etc.) zope3.wfmc.. abstract, potentially powerful, but imo, needs quite a bit of code to make anything non trivial functional. alphaflow.. i like the best as an architecture (ignoring AT implementation), Thanks! I don't like the AT implementation myself either, although I'm also kind of happy that I made AT do what I want. ;) i think that investing time rewriting it on z3 concepts would be time well spent, it has flexibility, a library for common actions, supports organizational workflows much better, and is model complete in terms of constructs to model conceptual workflows. Ack. However, some user-friendlyness is still missing. See my other post. openflow.. nothing to say. I think it's dead by now. It didn't seem active a few years ago when we looked at it. Also, the code was kind of scary. It has a very generic model that allows a lot of things in general but is missing the specificity of Alphaflow's library. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
