RSS

GSOC 2012

02 Aug

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:

https://github.com/calcacuervo/jbpm-human-task-gsoc-poc/blob/master/src/test/java/com/wordpress/demian/LifeCycleStatelessTest.java

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:

https://github.com/calcacuervo/jbpm-human-task-gsoc-poc/blob/master/src/test/java/com/wordpress/demian/LifeCycleStatefulTest.java

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:

https://github.com/droolsjbpm/jbpm/blob/master/jbpm-human-task/jbpm-human-task-core-cdi/src/main/java/org/jbpm/task/internals/lifecycle/LifeCycleManager.java

The current implementation is an mvel based one:

https://github.com/droolsjbpm/jbpm/blob/master/jbpm-human-task/jbpm-human-task-core-cdi/src/main/java/org/jbpm/task/internals/lifecycle/MVELLifeCycleManager.java

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

Advertisements
 
1 Comment

Posted by on August 2, 2012 in Drools

 

One response to “GSOC 2012

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: