Custom nodes problem

[olivier_debels]

Hello,

I want to add some custom nodes with multiple actions. What is the best way to do this?

At this moment the database design only allows to have a single action (with actionhandler as delegation) per node.

As far I can see I have two options:

1) Create an action handler which will create the two actions once its called, something like an container action handler.
2) Create custom nodes which can have more than one action specified. There needs to be a link between this node and all its actions.

I would opt for the second, since the first option would leave me with actionhandler containing tons of xml configuration.

Any ideas?

Olivier.

[kukeltje]

you could also make a subprocess with a fork and have multiple nodes each with one action in there. (Re) Use that subprocess on a higher level

[estaub]

Olivier,

You might consider a script.

The custom node seems hard to do while retaining the parameter evaluation semantics for action nodes. Don't let me stop you, though!

I think Ronald assumed you needed the actions in parallel... I assumed you need them sequential, or don't care.

I'm curious - why do you need this, and how badly do you need it?

-Ed Staub

[olivier_debels]

I was thinking about adding a custom node which contains an action which actually is a container for other actions. This container action has a fixed set of pluggable actions. For example suppose I want a node where I need to perform A, B and C in sequence. I could model it using three consecutive nodes or I could add a node with configuration:

<node>
 <A class="com.xxxxxxx.ImplementationA">
 <B class="com.xxxxxxx.ImplementationB">
 <C class="com.xxxxxxx.implementationC">
</node>

Of course I could also create a single action with:

<node>
 <containerAction class="com.xxxxx.containerAction">
 <A class="com.xxxxxxx.ImplementationA">
 <B class="com.xxxxxxx.ImplementationB">
 <C class="com.xxxxxxx.implementationC">
 </containerAction>
</node>

But then I need to parse the configuration of A, B and C actions myself. I woud end up with a containerAction containing a configuration property with xml containing other action configuration.

So I felt the need to have action configuration which is recursive and some kind of container actions.

Since I don't see a way to do this right now in Jbpm (only one action allowed) because I prefer not to parse configuration in the execution of the handler and don't want to add a separate node for each action child, I came up with the multiple action node idea.

Anyway, I'm still searching the best solution, also considering the limited time constraint (you know how it feels ;-)).

thx,

Olivier.