"kukeltje" wrote : | Sorry, but I have no knowledge of how drools workitems are configured/created/used in their 'GPD' | No problem ;) A workItem in drools is in short an extension of their traditional workflow. They use a simple configuration file to make this extension aware to their GPD ("RuleFlow-Editor") and define some eyecandy-stuff like an icon, which is shown by the editor, a view class which is shown when editing the workItem , possible parameters for the workItem etc. The workItem itself is represented by a special xml-tag. A simple process-xml definition would look like that: <?xml version="1.0" encoding="UTF-8"?> | <process ....> | <header>....</header> | <nodes> | <start id="1" name="Start"/> | | <end id="2" name="End" /> | | <workItem id="3" name="Start"> | | <work name="SystemMessage" > | | <parameter name="Message" > | <type name= .... /> | <value>DemoProzess mit Datei gestartet </value> | </parameter> | | </work> | | </workItem> | </nodes> | | <connections> | <connection from="3" to="2" /> | <connection from="1" to="3" /> | </connections> | | </process> This results in a procedure to integrate customized node types which can configured with nontechnical domain knowledge into the editor and the definition language in approximatly 30 minutes. "kukeltje" wrote : | (Drools 'workflow' is not something that is supported by JBoss), so | Yes I suppose it would have been an better solution to define well defined interfaces between drools and Jbpm than creating a new Wokrflow-Engine(which is a bit of overburden for the most use cases) .... But who cares ;-). "kukeltje" wrote : | You are right in looking at the pvm documentation for extending jPDL 4. | Adding new element types is possible this way but indeed not by 'mapping' them to an existing common node type by using | e.g. an attribute value instead of an element name. Might be an interesting addition though. | I suppose the easiest way to achieve such a behaviour would be to change an editor in a way to map from user "workItems" to existing jpdl-components, because it would be downwards compatible and doesn't require a change in the engine itself. "kukeltje" wrote : | Aamof, the BPMN2 implementation on top of the pvm could use something like this as well. | I don't know Aamof. What we need is a stable and extendable engine .... But having a BPMN2 compatible engine sounds great. Where can I read about it ? Is there still a stable version ? "kukeltje" wrote : | The editor is a different story. With new (user defined) element names it is harder to extend than the runtime engine, but not completely impossible. | Using attributes would make it a little easier. | The editorpart is the most important for our use-case because of our "stupid" process-architects :-P. Which editor would you prefer (GPD or Signavio), I suppose Signavio would be the "state-of-art" solution, but the most important factor should be how easy the implemantation of such a feature is. "kukeltje" wrote : | With regard to your 40 days, I think it is very well possible to extend the existing jPDL (maybe even the pvm) | and the GPD to support large parts of this (contributions always welcome, with 'support' from our side in return ;-) ) | If you want to go this way, discussing this in the dev forum is a good thing to do. | That sounds very good ;), I will post a topic in the developer forum summarizing the task, but it can last until tomorrow, I need some time for summarizing the task in my head :-P. CU Jan P.S. I would hope to invest less than 40 days but that's the max. which I can provide.... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253337#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...