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
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?
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 ;-)).