Re: Workflow engine

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

Most engines let you define a web service (SOAP) provider where you
specify the method to invoke, required parameters;  it simply a matter
of defining the provider 'schema', and then method can be invoked.
Responses are XML and every engine supports a "transform" action where
an XSLT is used to mash the result into whatever format you need, and
most support data extraction from a result document with XPATH.

> I suppose writing a small SOAP<->XML-RPC bridge should be pretty easy 
> in Mono?

True.  And on my to-do list.  I already have some .NET Remoting <-> OGo
XML-RPC code.  I'm currently redrafting all my slop and maybe I will
have something someone else would be interested in.

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

Just some mechanism for OGo to emit events would be terribly useful and
save a great deal of polling.  Even something as simple as 'object
created;task;11560' would be extremely useful.  Write it to a file or a
table, with a timestamp,   Currently for an external system to know a
task (or anything) was created is really hard,  although tracking a
existing object is easy based upon the objectVersion.

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

BPML?

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

Color me stunned. :)

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

Perhaps, I don't know if it has a plugin interface.  I've so far avoided
developing in Java; running the apps is hard enough.

> Writing some own simple modeller as a web app could be done as well. 
> Not sure whether people would be pleased with that though.

Like OpenWFE's droflo?

>  The 
> advantage would be better integration with OGo (that is the modeller 
> would know what actions can be triggered).


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