Re: Workflow engine
Helge Hess <[email protected]>
| Newsgroups | gmane.comp.cms.opengroupware.discuss.general |
|---|---|
| Message-ID | <[email protected]> |
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). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org -- OpenGroupware.org Discussion [email protected] http://mail.opengroupware.org/mailman/listinfo/discuss