...

org.jbpm.services.task.wih.ExternalTaskEventListener#processTaskState

TaskService

The TaskService is registered by the RuntimeManager to the RuntimeEngine. Magnolia provides it's own RuntimeManager implementation for easy registration of a custom TaskService Implementation. It's purpose is to handle the lifecycle of User Tasks, which is pretty obvious when looking at its interface:

...

During implementation we realised that this will be more complicated than necessary. While registering the TaskService to the RuntimeEngine would be nice, the gain is not much more than being a bit more consistent with jBPM. And when looking at the TaskService interface provided further down in the document, we would somehow have to wrap a lot of objects to work with our own Task's implementation, which should be part of the UI.

...

Compared to the first diagram, the TaskManager is not registered to the Runtime, but it is injected into the HTWorkItemHandler. The LifeCycleManager which takes care of notifying the process about completed tasks is replaced by TasksEventManager, which is part of the UI project and allows registering EventHandlers. This could e.g. be used to register an handler which sends mail every time a task is created, or in our case we register an handler, which takes care of notifying the process about completed user tasks.

Possible Risks and Problems

• Access to the TaskManager different than in jBPM.
• How to extend the Task object by workflow specific parameters, how to store it?

This approach allows a very slim integration with Magnolia's TaskManager. The whole Task Management is a standalone, reusable part of the UI project and for jBPM we communicate with the standard TaskManager interfaces using the HTWorkItemHandler and event handlers registered to the TaskEventmanager

Input from architecture meeting

3.4.2014: Task related classes should go to a separate module in main

Possible Risks and Problems

Accessing the TaskManager

Accessing the TaskManager is different than in jBPM. In jBPM the TaskService is bound to a RuntimeEngine and can be obtained like this:

long taskId = ((InternalTaskService) runtime.getTaskService()).addTask(task, content);

This will not be doable with our approach. 

Extending the Task object

How to extend the Task object by workflow specific parameters, how to store it?

Other Possible approaches

...

Continue down the road we chose and ignore User Tasks:

<Insert magic here>

Image Added