Creating domain specific nodes into a jbpm-editor

[barteljan]

Hello everybody :-),

Since we have chosen to use the jbpm-engine for some upcoming projects in the next year, we have delveloped an urgent need for "easy" read and extendable "domain specific " nodes in jbpm. Those nodes would have to be configured by highly nontechnical users with low or none java knowledge.

As those are features which are not provided by jbpm, we decided to implement them in the next months and provide them back to the community.

Our first idea is to modify a jbpm-editor (GPD or the Signavio-Editor), to show new domain specific node-types on it's panel, which provide domain specific properties to configure the underlying actions or java-classes.

This new nodetypes should be configured by a xml or properties file and map your jpdl-extensions on normal java- or custom nodes.
(A similar solution is provided by workitems into drools flow, for those who know drools ....)

As a result those new nodes would allow you an easily extending of jpdl with domian specific nodes without writing any additional codeline, beside the code needed for your actions.

Can you specify which of those features are already aviable and which would have to be added ?
Does anyone know if there are such possibilities within the signavio-editor ?
How is your opinon about providing such features into jbpm,
or elsewise do you have some ideas about providing such a feature in another way?

How can we organize the developement of those features and is there someone out there who would like to participate in the development process ....

Many questions ;)

I'm looking forward for your (possibly critical ;) ) questions

Until that,

Jan

P.S. It was already noted by koen (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160779) that the GPD would have to be extended for such a feature,
but that most pieces of such an extension are already implemented.

[sebastian.s]

Hello barteljan,

I have recently been thinking about this topic and to me the idea sounds great. I would highly appreciate something like this but I am curious to hear the opinion of somebody from the jBPM-Team on this. However to me this does not only seem to be connected with the development of the GPD but also with the extensibility of the jPDL schema.

https://jira.jboss.org/jira/browse/JBPM-2166

Thumbs up!! :)

Sebastian

[kukeltje]

There are more ways to approach this. Extensibility of the schema is not directly related in all of the possible solutions. And without going into much detail now, let me point out the differences between two approaches

- Really creating new elements
- Using a 'custom node' where there is a fixed definition on how to use/set properties of these nodes and where a 'type' element/attribute can be used to differentiate (instead of naming a java class). BPMN2 does this with the 'service' task.

The latter is possibly also easier for the GPD (it's kind of like what droolsflow does if I understand correctly), I think it is best to have Koen (GPD) and Tom (Core) have a little discussion on this. I explicitly notified both of this post (they receive the posts anyway, but just to make sure)

[kukeltje]

as promised, I pinged the core devs. So stay tuned.

Btw, could you tell us what specific node fuctionality you are thinking of? Kind of generic or realy domain specific?

[koen.aers]

Jan,

Do you have any experience with Eclipse plugin development? If not it would be good to read a tutorial about it (http://www.vogella.de/articles/EclipsePlugIn/article.html is a good start). We will need to define (or streamline) a few more extension points to enable smooth pluggability, so make sure you also read on how to define these. There are some good examples in the GPD code base already.

Which brings me to the topic of checking out the GPD code base so you can work on it:

- the SVN plugins as well as the GEF framework and the XML editor have to be installed in your eclipse installation to be able to check out the code and compile the code correctly.
- add the jboss tools svn repository to your workspace
- check out the following projects:
* org.jboss.tools.flow.common
* org.jboss.tools.jbpm.common
* org.jboss.tools.flow.jpdl4
* org.jboss.tools.flow.jpdl4.multipage

Let me know if this worked fine and you're able to browse the code.

Cheers,
Koen

P.S. I am usually to be found in the #jbpm irc channel on irc.codehaus.org. Ping me there for immediate help with this if needed.

[koen.aers]

Jan,

Something I forgot to ask: what is your timeline for this?

- When is it supposed to be finished?
- When do you start?
- Are you working on it constantly or maybe one day a week?

I would need this information to be able to include this in our overall planning.

Cheers,
Koen

[barteljan]

Hi :-),

At first thank you for your detailed comments about this task,
i'm trying to answer every point, please alert me if I miss one :-).

@add extensibility to jpdl schema
Althought I like the idea of an extendable schema for jpdl,I suspect this task is a bit of to much for our purpose, extending the schema means extending jpdl, which itself means extending the jpdl-core-engine. Since we want to use jbpm because of it's current stability, a modification of the engine itself should be avoided, because it holds a great danger for nasty bugs, which could be avoided by the "custom node approach". (Second approach noted by Ronald). I would prefer this approach because it looks like the easiest way to achieve extendebility. I would change my opinion if there are good arguments for doing that ;).

@BPMN2
I have to read more about it ....
although I would propose to use an already existing node-type (java or custom),
a new "service"-node would be acceptable for me.

@specific node fuctionality
I'm not quite shure what you mean with "generic", although we need a domain specific representation of our nodes (a stupid User should be able to differentiate two different "action-types" by sight ), It would be absolutly sufficient if those two different "action-types" are representated by the same node-type on xml-level.
And at last I suppose that there should be a generic approach for adding such action-types.

@eclipse development
My knowledge of eclipse-plugin-developement is quite limited,
I know the concept of an extension point, but I wouldn't be able to define one,
but this can be changed ;).

@timeline
We are calculating with about two days for jbpm-developement per week,
starting with evaluating the basics and targets in september.
Active programming could start in october, hoping about first eyecatchers in november and a nearly working solution in december ....
But that's only a rough calculation .... more time could be afforded if it is needed ....

Thank you for your comments and your time,

Jan

P.S. I will configure and co the svn in the next days and cry for your help if I can't manage that :-)

[kukeltje]

"barteljan" wrote:
Hi :-),

At first thank you for your detailed comments about this task,
i'm trying to answer every point, please alert me if I miss one :-).

We will

"barteljan" wrote:

@add extensibility to jpdl schema
Althought I like the idea of an extendable schema for jpdl,I suspect this task is a bit of to much for our purpose, extending the schema means extending jpdl, which itself means extending the jpdl-core-engine. Since we want to use jbpm because of it's current stability, a modification of the engine itself should be avoided, because it holds a great danger for nasty bugs, which could be avoided by the "custom node approach". (Second approach noted by Ronald). I would prefer this approach because it looks like the easiest way to achieve extendebility. I would change my opinion if there are good arguments for doing that ;).

That would be my preference to. At first sight it indeed would leave the core as it is.
And it comes closest to what would be needed for BPMN2 as well.

"barteljan" wrote:

@BPMN2
I have to read more about it ....
although I would propose to use an already existing node-type (java or custom),
a new "service"-node would be acceptable for me.

I think it is not needed since the custom node (jpdl) and the service node (bpmn2) are close enough.

"barteljan" wrote:

@specific node fuctionality
I'm not quite shure what you mean with "generic", although we need a domain specific representation of our nodes (a stupid User should be able to differentiate two different "action-types" by sight ), It would be absolutly sufficient if those two different "action-types" are representated by the same node-type on xml-level.
And at last I suppose that there should be a generic approach for adding such action-types.

With generic I meant an esb, ftp, ws, .... node, but I agree on the 'action-types'

"barteljan" wrote:

@eclipse development
My knowledge of eclipse-plugin-developement is quite limited,
I know the concept of an extension point, but I wouldn't be able to define one,
but this can be changed ;).

Then you are already further then I am ;-) Lets see how Koen can help, he is the 'master' ;-)

Might be interesting to also have a look at the RuleFlow editor (not sure if all the latest things are in the drools or jboss tools svn or there at all). Since we seem to be going to borrow/share something that Koen had an idea for a long time ago and Kris seems to have implemented it in quite a nice a way.

"barteljan" wrote:

@timeline
We are calculating with about two days for jbpm-developement per week,
starting with evaluating the basics and targets in september.
Active programming could start in october, hoping about first eyecatchers in november and a nearly working solution in december ....
But that's only a rough calculation .... more time could be afforded if it is needed ....

The next release of jBPM is scheduled for the 1st of November, with a code freeze (at least of the core) 2 weeks before, so that seems a bit to early. But the next release of january 1st could be a nice target.

"barteljan" wrote:

Thank you for your comments and your time,

Jan

P.S. I will configure and co the svn in the next days and cry for your help if I can't manage that :-)

Don't cry, it is better to shout it out loud, at least that would be my preference and I think Koen agrees.

So to summarize:

We need a way to specifiy
- A node type (name)
- reference to a pallet icon
- reference a node icon (process diagram level but could be the same as the palet icon)
- a reference to a custom node implementation (java class) that has to be included in the process archive
- some way to edit 'properties' of this node in a user friendly way (non-xml)

Designing these should be almost as easy as defining custom node, maybe by having the class implement a specific interface and find all implementing classes via reflection or use annotations or whatever and add them to the pallet on runtime. No XML hell... right ;-)

Would be good if we could break up all these things in jira and maybe some underlying things for Koen so it is clear what needs to be done etc.

[barteljan]

"kukeltje" wrote:

Then you are already further then I am ;-) Lets see how Koen can help, he is the 'master' ;-)

that sounds good ;).

"kukeltje" wrote:

Might be interesting to also have a look at the RuleFlow editor (not sure if all the latest things are in the drools or jboss tools svn or there at all). Since we seem to be going to borrow/share something that Koen had an idea for a long time ago and Kris seems to have implemented it in quite a nice a way.

I could write a simple drools-eclipse-project using some workItems if you want a simple example using the latest stable drools release (5.0.0).
But if you have good connections to Kris, asking him would be excellent ....

"kukeltje" wrote:

So to summarize:

We need a way to specifiy
- A node type (name)
- reference to a pallet icon
- reference a node icon (process diagram level but could be the same as the palet icon)
- a reference to a custom node implementation (java class) that has to be included in the process archive
- some way to edit 'properties' of this node in a user friendly way (non-xml)

Designing these should be almost as easy as defining custom node, maybe by having the class implement a specific interface and find all implementing classes via reflection or use annotations or whatever and add them to the pallet on runtime. No XML hell... right ;-)

Avoiding xml-hell sounds good,but what should we do if there are classes in the classpath who are correctly annotated or implement the right interface, but which shouldn't be shown in the editor (thinking of the example nodes provided in the jmpm.jar or the jar of project x, which uses nearly the same classes, but different "action-type nodes").
Another problem is that this means that the implementation class is needed while designing the process, which might be unwanted ....

I would prefer an option to configure it with a xml-jungle, but defaults which are using reflection or annotations ....

"kukeltje" wrote:

Would be good if we could break up all these things in jira and maybe some underlying things for Koen so it is clear what needs to be done etc.

Hmm .... seems like i will spend my weekend with jbpm :-P.

I would suggest starting a new forum-thread summarizing all requirements, so that we can split them up into different jira-issues.
Would you agree with that ?

[kukeltje]

"barteljan" wrote:

"kukeltje" wrote:

Might be interesting to also have a look at the RuleFlow editor (not sure if all the latest things are in the drools or jboss tools svn or there at all). Since we seem to be going to borrow/share something that Koen had an idea for a long time ago and Kris seems to have implemented it in quite a nice a way.

I could write a simple drools-eclipse-project using some workItems if you want a simple example using the latest stable drools release (5.0.0).
But if you have good connections to Kris, asking him would be excellent ....

That is not what I meant, I meant looking at the droolsflow editor to see how the extensibility is done there. I pretty confident an example in drools would work (I tested one myself here ;-))

"barteljan" wrote:

"kukeltje" wrote:

So to summarize:

We need a way to specifiy
- A node type (name)
- reference to a pallet icon
- reference a node icon (process diagram level but could be the same as the palet icon)
- a reference to a custom node implementation (java class) that has to be included in the process archive
- some way to edit 'properties' of this node in a user friendly way (non-xml)

Designing these should be almost as easy as defining custom node, maybe by having the class implement a specific interface and find all implementing classes via reflection or use annotations or whatever and add them to the pallet on runtime. No XML hell... right ;-)

Avoiding xml-hell sounds good,but what should we do if there are classes in the classpath who are correctly annotated or implement the right interface, but which shouldn't be shown in the editor (thinking of the example nodes provided in the jmpm.jar or the jar of project x, which uses nearly the same classes, but different "action-type nodes").

Maybe a solution where the designer could pick up classes in the project and runtime adapt the pallet to those classes that are just within this project. Then just adding a jar to your project would be sufficient.

"barteljan" wrote:

Another problem is that this means that the implementation class is needed while designing the process, which might be unwanted ....

Au contraire mon ami, I think you want to have them available for unittesting. Maybe they are even one and the same class (why not?)

"barteljan" wrote:

I would prefer an option to configure it with a xml-jungle, but defaults which are using reflection or annotations ....

hmmm.... where do you leave this config file then... I think it is more cumbersome than to just add a jar to your project.

"barteljan" wrote:

"kukeltje" wrote:

Would be good if we could break up all these things in jira and maybe some underlying things for Koen so it is clear what needs to be done etc.

Hmm .... seems like i will spend my weekend with jbpm :-P.

More with the GPD, and be glad it is not with a SOA (depending on your native language)

"barteljan" wrote:

I would suggest starting a new forum-thread summarizing all requirements, so that we can split them up into different jira-issues.
Would you agree with that ?

Yep, or even start a wiki page... Is even better I think and just post a link in this new topic if someting changes.

[barteljan]

"kukeltje" wrote:

That is not what I meant, I meant looking at the droolsflow editor to see how the extensibility is done there. I pretty confident an example in drools would work (I tested one myself here ;-))

I really did some SOA today, it looks like it leaves me a bit of braindead .... which is at least better than the first translation of this term.

Looking at the DroolsFlow editor is a good idea ....

I hope that I don't repeat things you already knew, but my first impression of the architecture involving workItems is the following:

DroolsFlow divides the definition of workItems in some sort of MVC concept ....
At first there is a MVEL-Definition in your META-INF folder which describes how to represent a node type in the editor and it's abstract parameters and properties. And secondly there is a additional Representation of a WorkItem at runtime with a WorkItemHandler. Such a handler is itself a class implementing the WorkItem-Interface with a central executeWorkItem method containing your domain specific code. WorkItemHandlers are normal java objects which are intanciated by the developer and passed to a WorkItemManager at runtime. Those handlers are then notified when a process instance signals a workItem node.

"kukeltje" wrote:

Maybe a solution where the designer could pick up classes in the project and runtime adapt the pallet to those classes that are just within this project. Then just adding a jar to your project would be sufficient.

Yes adding such an option to the GPD could be a solution .... or did I miss the point again :-/ .

"barteljan" wrote:

I would prefer an option to configure it with a xml-jungle, but defaults which are using reflection or annotations ....

"kukeltje" wrote:

hmmm.... where do you leave this config file then... I think it is more cumbersome than to just add a jar to your project.

Yes I fear that's true, I thought of a situation where I give a customer just the editor to create processdefinitions without a possibility of testing or executing them. It could even happen that I want him to model a process with actions which have to be implemented in the future.
In such a situation it would be a bit of annoying to provide java-classes or some stubs for him, but a config-file (even if this could be in the jbpm.config.xml) isn't really better ....

[koen.aers]

"barteljan" wrote:
Yes I fear that's true, I thought of a situation where I give a customer just the editor to create processdefinitions without a possibility of testing or executing them. It could even happen that I want him to model a process with actions which have to be implemented in the future.
In such a situation it would be a bit of annoying to provide java-classes or some stubs for him, but a config-file (even if this could be in the jbpm.config.xml) isn't really better ....

The only good solution in my opinion is a plugin-based solution. IE every node you want to contribute is an extension to the extension point that defines how to add new nodes to the editor.

The different elements of information that are needed to do this in its most simplified form are:
- a description of the node that has to be added (the properties of the node)
- how to serialize the node
- how to deserialize the node
Additionally the following elements are optional:
- description of the figure representing the node
- the icon and/or text that have to appear in the palette
- the path in the palette where they have to be added

Of course, you can even more generalize the possible extensions by defining a generic node type what is always serialized/deserialized in the same way and of which the properties are simple attributes and/or some well-known child elements. In this case the 'pure' xml solution comes in the picture. Nevertheless, I have a preference of describing these extensions in the plugin.xml of a plugin that adds these custom nodes instead of adding a jar file containing these xml files somewhere on the classpath (either by configuring a preference in the workspace or adding a jar file in a projet).

The latter solution (including the xml config in a jar file) is a more specific case of the former one. The former solution is not yet completely implemented at present. Roughly the following things need to be done first:
- define an extension point for serialization/deserialization
- define an extension point for the palette items

If you want to dive deeper into this, take a look at the Registry class in the package org.jboss.tools.flow.jpdl4.io and the JpdlPaletteFactory class in the org.jboss.tools.flow.jpdl4.editor package. The first step is to refactor these two classes and let them do their job based on information that is contributed in the plugin.xml by extensions of two new extension points. Another thing that you definitely want to look into is the already existing extension point for adding elements to the GPD (defined in the plugin.xml of the org.jboss.tools.flow.common plugin and used in the plugin.xml fo the org.jboss.tools.flow.jpdl4 plugin). It will show you how to create and use extension points. More in particular the class ElementRegistry in the package org.jboss.tools.flow.common.registry will be a good source of information.

I'll add a reference to this thread to GPD 292 and we can continue the discussion there. Also feel free to attach patches if you're fiddling around (or happen to define the extension points) so that i can test them. Make sure you sign the contributor's agreement if you're going to do this.

Cheers,
Koen

[kukeltje]

"barteljan" wrote:
Yes I fear that's true, I thought of a situation where I give a customer just the editor to create processdefinitions without a possibility of testing or executing them. It could even happen that I want him to model a process with actions which have to be implemented in the future.
In such a situation it would be a bit of annoying to provide java-classes or some stubs for him, but a config-file (even if this could be in the jbpm.config.xml) isn't really better ....

The only good solution in my opinion is a plugin-based solution. IE every node you want to contribute is an extension to the extension point that defines how to add new nodes to the editor.

Yes

The different elements of information that are needed to do this in its most simplified form are:
- a description of the node that has to be added (the properties of the node)
- how to serialize the node
- how to deserialize the node
Additionally the following elements are optional:
- description of the figure representing the node
- the icon and/or text that have to appear in the palette
- the path in the palette where they have to be added

Of course, you can even more generalize the possible extensions by defining a generic node type what is always serialized/deserialized in the same way and of which the properties are simple attributes and/or some well-known child elements. In this case the 'pure' xml solution comes in the picture.

Or one where you can implement a specific interface and/or annotations or both (not sure what is easier to find/parse classpath wise, maybe something like seam does)

Nevertheless, I have a preference of describing these extensions in the plugin.xml of a plugin that adds these custom nodes instead of adding a jar file containing these xml files somewhere on the classpath (either by configuring a preference in the workspace or adding a jar file in a projet).

For the element-name based extensions I agree, for the generic (custom) node type extension I don't. Not having to know anything about eclipse plugins, distributing your own ones and still be able to create 'extensions' is a (u)sp

The latter solution (including the xml config in a jar file) is a more specific case of the former one. The former solution is not yet completely implemented at present. Roughly the following things need to be done first:
- define an extension point for serialization/deserialization
- define an extension point for the palette items

If you want to dive deeper into this, take a look at the Registry class in the package org.jboss.tools.flow.jpdl4.io and the JpdlPaletteFactory class in the org.jboss.tools.flow.jpdl4.editor package. The first step is to refactor these two classes and let them do their job based on information that is contributed in the plugin.xml by extensions of two new extension points. Another thing that you definitely want to look into is the already existing extension point for adding elements to the GPD (defined in the plugin.xml of the org.jboss.tools.flow.common plugin and used in the plugin.xml fo the org.jboss.tools.flow.jpdl4 plugin). It will show you how to create and use extension points. More in particular the class ElementRegistry in the package org.jboss.tools.flow.common.registry will be a good source of information.

I'll have a look to

I'll add a reference to this thread to <a href="http://jira.jboss.org/jira/browse/GPD-292">GPD 292</a> and we can continue the discussion there. Also feel free to attach patches if you're fiddling around (or happen to define the extension points) so that i can test them. Make sure you sign the contributor's agreement if you're going to do this.

Cheers,
Koen

[koen.aers]

"Ronald" wrote:
For the element-name based extensions I agree, for the generic (custom) node type extension I don't. Not having to know anything about eclipse plugins, distributing your own ones and still be able to create 'extensions' is a (u)sp

Even for the generic node type extension there is value in using the Eclipse plugin mechanism. The installation mechanisms and location are well defined and the dependencies are automatically resolved. No issues when you delete or move around workspaces and/or projects, etc. And after all, a plugin in this case would contain nothing more than a plugin.xml file which is... well, just an xml file.

Cheers,
Koen

[kukeltje]

Custom example from the 'examples':

 <custom name="print dots"
 class="org.jbpm.examples.custom.PrintDots"
 g="96,16,100,52">

 <transition to="end" />
 </custom>

Needs a class. That has to be in the classpath from somewhere, so having this just as a xml file is (imo) impossible, you need the class somewhere for unittests and it needs to go in the .bar (jar currently) or whatever. So you need it *anyway* and why not combine the two and have it one class. But keep in mind, ONLY for this specific custom example which would satisfy lots of users and a pom.xml could/should be used for resolving the runtime dependencies or do I miss something?

Regarding the 'issues' about moving workspaces etc, you are right, but just like Jan mentions, I also think that not having a bloated (excusez le mot) pallet if there are to many 'nodes' on a high level in the GPD.

And it does not mean the more specific realy new nodes (elements) should be impossible, au contraire...