I try to implement "Pattern 15" in jbpm4
"Multiple Instances without a priori Run-Time Knowledge"
I use a custom implementation of ExternalActivityBehaviour, that basically just waits for signals to spawn off dynamic task instances, the code in signal() to do this looks like this:
DbSession dbSession = Environment.getFromCurrent(DbSession.class); // create new task TaskImpl task = (TaskImpl) dbSession.createTask(); task.setName(taskname); task.setNew(true); // no idea what this is but looks good task.setExecution(execution); task.setProcessInstance(execution.getProcessInstance()); task.setSignalling(false); task.setAssignee("assignor"); task.setActivityName("complete"); // save task dbSession.save(task); // deal with the history table HistoryEvent.fire(new TaskCreated(task), execution);
this gives me the tasks in the users tasklist and they can be completed, however the problem is the history table, as pointed out in
there is no way to get the information about the task instance from the taskHistory table, the only useful information would be the activity, but since all these dynamic tasks are created for the same activity this doesn't help much either.
My second approach to implement "Pattern 15" is to use dynamic activities like described in:
(this isn't exactly the pattern but close enough) the code in this thread implements an event listener which means it can only be invoked on a limited set of workflow events (start, end) when taking
transition or entering nodes as far as I understand (someone please correct me if I am missing something here).
So again I tried to implement this in a custom ActivityBehaviour, which can
receive random signals with executionService.signalExecutionById(..). I basically use the code from the event listener which dynamically creates a
new execution first, then a new Activity and wires them with transitions. The code is in the placeViceMentorTask() method at
The problem with this approach is:
what is the state of the new execution? Execution.STATE_ACTIVE_CONCURRENT doesn't work since it requires a Execution.STATE_INACTIVE_CONCURRENT_ROOT for the parent execution which means I can no longer signal it for more executions.
the dynamic created activity and its transitions are not in the process definiton and I can't find any database table for the transitions, now when I reboot the process engine they probably will be lost...
so I am running out of ideas and wanted to know if someone is tackling the same problem with more success than I had so far, any ideas are very welcome, the first one with a solution gets a beer from me when he/she is in Stuttgart, Germany