Re: Workflow engine

The OpenGroupware Coils project
<http://sourceforge.net/apps/trac/coils/> now has a workflow engine;  it
is useful enough that we are using it lightly in production.  It is
accessible via WebDAV [for creating, browsing, and starting flows].  The
engine compiles BPML 1.0 markup to an internal format;  adding
additional markup-notations wouldn't be much harder than writing a SaX
parser to produce the internal format.

Only linear execution and foreach flow-control are implemented so far.
Stubs exist for switch, until, and while; but foreach was the hardest so
I started with that.  Messages scope is handled correctly.

The actions implemented so far are: 
read [translate a message using a format, 
line oriented and XLS implemented so far], 
select [SELECT from a defined RDBMS], 
write [write a StandardXML message out using a specified format, line
oriented implemented so far], 
assign [XPath select a value or assign a static value to a message],
getEntity [retrieve an entity from the groupware database], 
xpath [create a new message from an XPath query], 
ldapSearch [search an LDAP DSA, results are in DSMLv1.0],
regularExpressionFind [perform regexp matches], 
readJSON [translate JSON data into XML], 
sendMail [which support attachments].  

All commands support label substitution in appropriate parameters.

<http://sourceforge.net/apps/trac/coils/wiki/Workflow-Engine>

On Thu, 2005-01-06 at 17:17 +0100, Helge Hess wrote:
> On 6. Jan 2005, at 16:23 Uhr, Adam Tauno Williams wrote:
> > I clearly see the connection between Groupware and CRM.  The connection
> > between Groupware and Workflow seems more abstract to me,  a workflow
> > can be basically anything; but as a source of participants the 
> > groupware
> > server is certainly useful.
> Also as a source for actions. A workflow definition itself is nothing 
> else but a declarative programming language which evaluates conditions 
> and triggers actions.
> The conditions can involve object status (like the role of a 
> participant).
> The actions can be "groupware actions", like creating an OGo task as 
> the final step.
> > Currently getting data from OGo from aworkflow engine is possible 
> > since you can usually invoke external commands or plugins and make use 
> > of XML-RPC,  and the same in reverse.
> > Altough this would be even more straight forward if OGo supported SOAP
> > since every engine i've met supports that natively.
> SOAP is just an RPC mechanism and doesn't say anything about the actual 
> calls (just like with XML-RPC). So OGo supporting "SOAP" doesn't help 
> anything, it would need to support the SOAP messages send by those 
> engines.
> I suppose writing a small SOAP<->XML-RPC bridge should be pretty easy 
> in Mono?
> > Would a workflow engine in ObjC/SOPE be able to simply interact with
> > objects in the OGo space?  (I only have a sketchy understanding of
> > SOPE).
> That is actually the major work, packaging the OGo functionality in 
> something which can be referred from the workflow definition. Not sure 
> how this is done in current solutions as it probably involves some 
> scripting.
> But yes, this would be what I'm interested in.
> > That would be cool for some simple processes where documents
> > need to move through a chain user modifcations/approvals.  I guess that
> > is CRMish.
> Thats CMSish ;-)
> > You mean a standalone workflow designer?
> Yes.
> > Unfortunately most designers
> > are linked pretty tightly to their respective engines,  and most of
> > those are labyrinthian J2EE abominations.
> OK, I guessed so. Since a generic designer only makes limited sense.
> > The only two stand-alone designer I know of is
> > http://jawe.objectweb.org/ which reads/emits XPDL files.  XPDL is the
> > XML Process Description Language.
> Actually the engine we have does read the predecessor of XPDL, don't 
> remember how this was called.
> > jawe is currently used by serveral workflow engines:
> > http://shark.objectweb.org/
> > http://www.openbusinessengine.org/
> > http://wfmopen.sourceforge.net/
> OK, interesting. Unfortunately its not really usable on OSX because the 
> UI is mixed up (well, its Swing ;-)
> > jawe supports the Meta-Model for participants and lets your build
> > particpant lists from an LDAP DSA, so with a little rigging you can get
> > data from OGo and avoid having to build particpant<->realperson
> > relationships in a third facility.
> Ah, sounds cool. Maybe it could be even extended with some OGo specific 
> plugins.
> Writing some own simple modeller as a web app could be done as well. 
> Not sure whether people would be pleased with that though. The 
> advantage would be better integration with OGo (that is the modeller 
> would know what actions can be triggered).

-- 
Adam Tauno Williams <[email protected]> LPIC-1, Novell CLA
<http://www.whitemiceconsulting.com>
OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba

-- 
OpenGroupware.org Discussion [email protected]
http://mail.opengroupware.org/mailman/listinfo/discuss