Hi everyone! I am back to my blog and hopefully I will write again soon!.
This time I will talk about my work in GSOC 2012.
The idea of my project is to allow human tasks to be flexible and configurable, and not simply hardcoded in an mvel file. So, it sound ideal to represent the human task life cycle as a business process.
Here I will talk about the possibilities I reviewed and in the next post I will come up with the finished solution.
Basically, there are two main options: The stateless and stateful option. The “less” or “full” refers to the possibility to save the task state into the process, or treat each state change as a single process instance. Let’s check the two possibilities.
Stateless Approach.
This approach only aims to have a process that captures events, make the desired checks and status changes in tasks and finished. This is not too much business process oriented, but has the flexibility for the user to change the behaviour of each Task Operation.
It could also be represented with a process per each operation, with a conditional event start, which would be a bit more ordered but with same limitations.
This is a test that shows this behavior:
The “Completed”, “Claimed”, “Started” (and will be more) nodes and some special nodes that has the configuration for each node behaviour. If you double-click one of then you will see something like this:
This has all the configuration that nowadays it is in OperationCommand class loaded by an mvel file.
With this approach, the StatefulKnowledgeSession used to run the process does not need to the persistent, as processes just starts and end each time.
Stateful Approach
In this approach, each process instance will represent all the task instance life. For this purposes, the process will look like this (obviously, with the other needed states too):
This seems a bit more real for the task life-cycle. But it required some more work in the coding part. Let’s see this test:
Each task has a StatefulKnowledgeSession associated. When it is put in the jbpm code, in some persisted place, the association between taskId – sessionId should be saved. When an operation for some task comes, the correcte StatefulKnowledgeSession will be loaded and the correct event will be signaled. It makes us think that this session has to be persistent, so we will have to take care about it.
What happens, for example if a now allowed user tries to do an Operation in a task? As the session is persisted and will run into a transaction, an exception in the operation node handler will be thrown (not allowed exception), and the transaction will be rolledback. But if for some security concern the application needs to save a non authorized attempt in some place, this handler could be hooked to override this behaviour.
And what does each Operation Node does? If you see this new human task refactoring approach:
https://github.com/droolsjbpm/jbpm/blob/master/jbpm-human-task/jbpm-human-task-core-cdi
it has a hook to manage the task lifecycle, which is represented by the LifecycleManager interface:
The current implementation is an mvel based one:
The idea with the process based approach will be to have a ProcessLifecycleManager, which will get the session for a task and signal the correct event. And the code that nowadays is in the MVELLifecycleManager that checks if user is allowed and changes the task status, potential owner and other task data will be put inside the Operation Node configured after each event.
I think this last approach will give enough flexibility for jBPM user to understand and change the human task behaviour, and even mixing it with business rules!
So, I will be integrating this approach with the “jbpm-human-task-core-cdi” and I will come back with news.
Thanks!
Demian
Demian's Blog 
One response to “GSOC 2012”