Since 4.0.0.Beta1
The revisited task management model in jBPM introduces a new concept: task participation. The participation model describes identities (user or groups) and the type of involvement in the actual completion of task:
Example 1: User and business administrator participation
A common use case where this model fit's quiet nicely is the distinction between a user that actually performs the task and a business administrator monitoring progress. Depending on the participation type some principals will actually do the work, while others make sure tasks are executed within given constraints (i.e. priority, duedate, etc).
Example 2: Task stakeholders with different participation types
Another example could be stakeholders monitoring the actual outcome of task, or delegation between different participants that co-operate on a task. In this case a "initiator" of task, a "candidate" performing the work and the "final recepient" might be different participation types.
The TaskService API already reflects those changes:
org.jbpm.TaskService
{
[...]
/**
* retrieves a list of tasks for a user
* and a particular {@link org.jbpm.task.Participation} type
*
* @see org.jbpm.TaskQuery
*/
ListfindTasksByParticipation(String participation, UserRef user);
/**
* retrieves a list of tasks for a group
* and a particular {@link org.jbpm.task.Participation} type
*
* @see org.jbpm.TaskQuery
*/
ListfindTasksByParticipation(String participation, GroupRef... groups);
}
Currently we ship some default participation types, out of which only type 'candidate' is supported, but you can expect this to be extended in the near future.
org.jbpm.task.Participation
{
[...]
String CANDIDATE = "candidate";
IdentityRef getIdentityRef();
/** see constants for default participations */
String getType();
}
Stay tuned.
6 comments:
This seems like a good model. The 3.x model only related tasks to strings for users. One side affect of this is that the model was quite flexible.
Currently in 4.x, how are we going to ensure that the flexibility of the user/group model will still allow other authentication modules [such as LDAP] to be plugable?
Heiko,
I like it.
It is an evolution from 3.x, without losing the original flexibility. I did have use cases in the past that could benefit from this mechanism. Keep up the good ideas :-)
@robotriding
The IdentityRef still uses string fields as Id's, it's just that we introduced subclasses to distinguish users and groups. See my comments here in the forum [1]
The actual identity management is decoupled through an SPI. We currently support 2 identity management implementations: the JBoss IDM [2] project and more simple jBPM4 implementation.
[1] http://www.jboss.org/index.html?module=bb&op=viewtopic&t=153217
[2] http://www.jboss.org/community/docs/DOC-13258
The IDM project would be our preferred solution, because it will eventually become the default JBoss Identity solution that works across products: Portal, ESB, jBPM. etc
Heiko,
How about reusing the terminology as defined in the WS-HumanTask specification?
* (Generic human) role corresponds to participation, the spec defines the following predefined roles:
- Task initiator
- Task stakeholders
- Potential owners
- Actual owner
- Excluded owners
- Business administrators
- Notification recipients
* OrganizationalEntity as the parent of User and Group
One other thing that is not completely clear to me is whether a participation is always linked to one identity or whether it can contain references to multiple? In WS-HT, multiple entities can be linked to the same role.
@Kris
Yes, I would agree with your suggestion. But that has to be discussed with the jbpm team as a whole. But the current model in it's abstract form doesn't restrict itself to particular role/user/group representations.
Which means that within the console, the task management should work with both WS-HumanTask and the proprietary jBPM4 implementation.
WS-Human Task and BPEL4People related participants would seem to be orthogonal to the notion of whether you are dealing with an individual person or an organisation.
The main issue would appear to be cardinalities, in that a number of entities can share that same participation role [context], via escalation, monitoring, or other predefined organisational relationships.
I am definitely in favour of Kris Verlaenen's suggestion. We would be happy to contribute to this initiative.
Post a Comment