Creating non technical Actions / WorkItems

[barteljan]

Hello everybody :-),

I'm evaluating several java-process-engines for an business project,
were we have highly non-technical process developer.

Although I like Jbpm very much because of it's lightweight java oriented architecture,
it is a diffculty for us that there is java-knowledge needed to model jbpm-processes.
(At least when linking java-classes to a java or custom node)

What we would need would be a generic way to extend jpdl like it is done in drools with the drools WorkItems.
We need some form of NodeTemplate which could be mapped on a existing node type (maybe custom or java) to hide technical information
like class and method names from the users.

This wouldn't be a problem if I would be able to find some documentation,
about an "easy" way for extending the GPD or the Signavio Editor or to add simpler non technical nodes programmatically.
(Sorry I don't wanne grump about bad documentation ;) , it' just to illustrate my problem )

The only information about that would be the following articel http://www.mastertheboss.com/en/jbpm/106-jbpm-best-practices.html .
Which describes how to extend the Jbpm-Api for adding attributes to the task node.
But beside this article is about jbpm 3.x, it seems as if their is much insider-knowledge needed to create new nodes,
especially if they should integrated in an editor.
I did a quick scan about the pvm-documentation but I realized that XML-Processing is made by each implementing api, which implicates that this document didn't help me to map such nodes to a common type ....

Did I miss something ? Is there a way of doing such customizing of jPDL and jBPM which I didn't realized or understood ;) ???

And if not, would you think it is possible to implement such a feature for an experienced java-developer with low jbpm
and eclipse background in let's say 40 days of development work ?

I suppose this is one of the few topics were drools-flow outperforms jbpm ....

I would be very happy for every answer even if it is a "RTFM" statement :-P

Thank you for your help

Jan

[kukeltje]

Sorry, but I have no knowledge of how drools workitems are configured/created/used in their 'GPD' etc (Drools 'workflow' is not something that is supported by JBoss), so

But besides this, I'm not completely sure what you mean by

I did a quick scan about the pvm-documentation but I realized that XML-Processing is made by each implementing api, which implicates that this document didn't help me to map such nodes to a common type ....

so if my comment below is not related, please shoot :-)

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. Aamof, the BPMN2 implementation on top of the pvm could use something like this as well.

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.

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.

[koen.aers]

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

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.

At the moment the editor is not yet easily extendable in this way. Hence also the fact that you did not find a lot of documentation about it. We have focused on other priorities than extensibility but most of the pieces to do this are present. I would need to define a few more extension points (or add options to existing extension points) and clean up the code a little bit. There is a JIRA issue available already (GPD-292) so we can continue the discussion there as well.

In any case, 40 development days seems more then enough to me to pull this off. The final goal is to be able to do this in a couple of hours of development time at the most.

Regards,
Koen

[barteljan]

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

[kukeltje]

Aamof For the rest I think we are on the same line

As you have seen, Koen already responded. He is the 'lead' of the GPD (including most things in the Drools GPD afaik (as far as I know ;-)). So if you post in the dev forum and want to develop things, I'll make sure I'll have him comment and coordinate things. (coordinating the coordinations is my thing ;-))

So if you are proposing to help making it easier for you in the future... We're all ears.

Regarding the interface, there was one in jBPM 3, and in 4 it is in jira. So using 'best of breed' in an easy way will become possible again.

[barteljan]

"kukeltje" wrote:
<a href="http://www.acronymfinder.com/As-A-Matter-Of-Fact-%28AAMOF%29.html">Aamof</a>.

Oh :-D there is to much slang out there :-P

P.S.: I have to discuss those things with my boss but i'm quite shure that he would agree in such a project ....