Extension of the Designer

[magro1202]

Hi everyone, Hi Koen

i'm doing a diploma thesis at a company in Germany which is working with the JBPM Workflow Engine.

they want me to extend the Workflow Designer to have a possibility to specify an action node for their special issues.

At the moment they add specific Elements manually via XML-Editor, but
with complex Workflow structures this is not efficient and very error-prone.

the Elements they want to specify looks like this for example
















There can be further elements within the "call" - Tag for example invoke or result parameters of an ant-script that is specified by scriptName

processVariables are global Variables within the Workflow that must be defined in an action node.

so my work is to implement a generic interface to be able do those configurations via the Designer

the idea is that with such an interface every user can load a specific definition in the designer to offer user dependant configuration of an action node.
For this i considered to create a new config-type for the action node e.g. "external" or "user defined" or the like.
when selected a user defined xml could be load in which the configuration elements are specified to be available in the designer

if such work is desired of a wide range of users one could transfer the results back to the Open Source Projekt

So my question is, does anyone have suggestions where in the code i have to make modifikations or extensions?
Or does anybody recommend a better way to do that?

Any comments are wellcome and would help me a lot

Regards
Matthias

[magro1202]

The example i mentioned above was not shown because i forgot the code statements

the example looks like this

<action name="provideFile" class="....CallAction">
 <asynchronous />
 <call>
 <scriptName></scriptName>
 <scriptTarget></scriptTarget>

 <processVariables>
 <var>
 <key></key>
 <value></value>
 </var>
 </processVariables>

 </call>
</action>

[koen.aers]

Hi Matthias,

Can you give some more information about what you are trying to do? More in particular:
- Can these actions occur anywhere (i.e. when any event is fired) or are they exclusively used within a generic node type?
- If its used in a node, does this node need to show up in the palette?
- Is it feasible to add specific xml elements for these actions you need? Or is it overkill?
- Is the custom configuration you want to do exclusively dependent on the classname of the action handler? Or are there other criteria as well?

We are slowly getting to node pluggability with the designer, and also action pluggability (custom predifined actions) is one of the things on the wishlist. So it seems your request falls in these categories.

It seems to me though that adding another configuration type is not the good approach. I would try to add a tabpage or a section on a tabpage in the properties view that contains entry fields for the needed configuration information. It would then be a matter of 'hiding' the default configuration properties pages. Could this work for you?

Regards,
Koen

[msandoz]

Here's a screenshot and xml snippet of what we have done that sounds similar. Is this like what you're thinking of?

...jpdl code...
 <node name="emailSender-node1">
 <action class="com.nexusbpm.services.email.EmailSenderService">
 <dfvariables>
...other variables...
 <dfvariable name="r" sourceNode="r-node1" sourceVariable="code" variableType="int">
 <dfvalue><![CDATA[]]></dfvalue>
 </dfvariable>
 <dfvariable name="port" required="true">
 <dfvalue><![CDATA[25]]></dfvalue>
 </dfvariable>
 </dfvariables>
 </action>
 <transition to="end-state1"></transition>
 </node>
...jpdl code...

[koen.aers]

Hi Matthew,

This is indeed what I meant. It is great to know and see that you are doing this.

Regards,
Koen

P.S. I will be in Atlanta Nov 9th. If you want to meet and have a chat/beer, drop me a line.

[magro1202]

Hi Koen

thank you for your answer

the action should be configurable in every case you can use an action node, e.g. in Nodes, transitions, states, events, ...

so i do not want to create a seperate action, or a special node, i would like to extend the existing Action node to give a user the opportunity to load a definition of all specific elements he needs for his special issue to the designer to show up controls with which he can configure these elements, whatever the elements are.

So for a concrete example:

i could imagine, in a standard action configuration page there is a new tab, as you mentioned, where you can choose a definition in XML Format for example.
in this XML File all custom elements are specified.
The XML File is to be parsed by the designer and then the designer offers
configuration possibilities for his elements.
Then the made configurations are transfered to the given action node in the process definition.

the elements need not necessarily be dependant to the ActionHandler, it could be that the specified class is not available within the designed Project

my intension is to make an action node freely configurable to every user with custum issues he wants to do within the action without manually adjust the process definition file.

May be there are a lot other possibilities to get that straight,
this is gonna be one main point of my thesis to figure them out.
this is getting interesting i think.

If you have any recommendations dont't hesitate to tell me, i'm open for all opinions

regards
Matthias

[camunda]

Hi Matthias.

Do you write that thesis in english and will it be available to the public? That could be interessting... Otherwise don't forget to send me a copy via email ;-)

Bernd.

[wkoziej]

Hi everyone

Magro1202 idea is very interesting for me.

I'm looking for a way to define custom node's in processes.
In fact I imagined this in a Matthew's way, but the magro1202's way is more powerfull.

Koen, can you tell something more about planned node pluggability, please?

Matthew, describe implementation of your solution in few words, please.

regards,
Wojtas

[tom.baeyens]

IMO, we need a limited grammar to express the configuration options for a node.

That would help to provide better support for this pluggability in the designer.

I think we should be thinking in the following direction:

1) limit the grammar to configure node-action properties to strings, numbers, lists and maps

2) helper classes to make it easy to build a form. the node grammar could be input. maybe even a simple special xml language for forms a la XForms could be made to create the eclipse node-action configuration forms.

3) a default way on how a grammar is translated to xml in the process definition.

That way, the only input that the designer would need to plug a new node type are:

* icon
* grammar
* form (either a class or an xml document)

If default grammer-to-xml is used, then the grammar would be sufficient input for the parsing of the process during deployment in the runtime engine.


So the important point IMO is that we need to think about a simple grammar to express node configuration options.

[koen.aers]

Having this grammar is definitely a possibility.

But what I still don't see in Matthias' case is how the designer should decide which form it should render if the type of the action is not in a way available.
You seem to suggest that for each configured action a user has to upload this grammar manually. Or am I wrong?

Regards,
Koen

[koen.aers]

Ah, I forgot to suggest to Wojtas to have a look at the plugins plugin.xml. There are a number of extension points available and examples of extensions in these extension points that show you how you can implement the kind of extensions that Matthew did. There are also a number of discussions on this forum and in JIRA related to this. It is not yet very easy but doable so it seems...
As for the planned things, have a look at the JIRA issues related to it (GPD-171, GPD-172, GPD-173). There is nothing yet in JIRA about pluggable actions, so that was not planned for the short term future. However, as this seems to be a current need to some of you guys, it might be the moment to take it into account.

Regards,
Koen

[wkoziej]

Thanks a lot,

I have to start learning more about writing eclipse plugins :)

Can I ask for:
1. More :) description/comments in GPD-172 JIRA isue. What does it mean DSL in this context?
2. More description/comments in GPD-173 JIRA isue.
a) What such example(s) should show
b) "jPDL extension" - is this an extension to the language or to the designer?

regards,
Wojtas

[tom.baeyens]

Koen, I want you to think about such a concrete grammar and how a node+grammar would translate into plugin extension points.

If we have a complete idea about this, we might consider going that way. But you need to know if and how it's going to work before we can think of starting coding it.

The clue will be to see how such extension point would be integrated with all the other features of the designer such as: xml-to-model synchronization, undo, and so on. With your knowledge, it should be possible to oversee all these kinds of implications of such an approach before you would start to code it.

Thinking about this is IMO much more important then any other feature.

[magro1202]

Hi everyone

i have done a first approach of my problem.

It is not full implemented, it is just the mask as i imagine

[img]http://img155.imagevenue.com/img.php?image=01653_tree_122_814lo.jpg[/img]

from a definition file the upper tree is created from wich you can select the elements and change values.

from this tree a XML of the following form can be created.

<root>
 <asynchronous></asynchronous>
 <call>
 <scriptName color="red" bold="no">test</scriptName>
 <processVariables>
 <var>
 <key>var1</key>
 <value>foo</value>
 </var>
 <var>
 <key>var2</key>
 <value>bar</value>
 </var>
 </processVariables>
 <resultMapping>
 <alias>
 <key>result</key>
 <value>intern</value>
 </alias>
 </resultMapping>
 </call>
</root>

So the next step is to transfer this into the given Action-Tag.

What do you think about it, would this work for anybody?
Any improvements you would recommend?

regards
Matthias

[msandoz]

we created what we called dfvariables - dataflow variables as parameters. included in them are the normal things you would want, a default value, a type, a direction (in/out/inout), etc. but we also put in a way of doing dataflow - namely a source node and source variable (we support superstate hierarchy as well) - to let you get your data from another node. the value is stored in the context and for large files we provide datatypes such as asciifile and binaryfile.
if you are interested in more info/schemas/whatever let me know.