Management of users, groups and permissions is commonly known as identity management. jBPM includes an optional identity component that can be easily replaced by a company's own identity data store.
The jBPM identity management component includes knowledge of the organisational model. Task assignment is typically done with organisational knowledge. So this implies knowledge of an organisational model, describing the users, groups, systems and the relations between them. Optionally, permissions and roles can be included too in an organisational model. Various academic research attempts failed, proving that no generic organisational model can be created that fits every organisation.
The way jBPM handles this is by defining an actor as an actual
participant in a process. An actor is identified by its ID called an
actorId. jBPM has only knowledge about actorId's and they are represented
as java.lang.Strings for maximum flexibility. So any
knowledge about the organisational model and the structure of that data
is outside the scope of the jBPM core engine.
As an extension to jBPM we will provide (in the future) a component to manage that simple user-roles model. This many to many relation between users and roles is the same model as is defined in the J2EE and the servlet specs and it could serve as a starting point in new developments. People interested in contributing should check the jboss jbpm jira issue tracker for more details.
Note that the user-roles model as it is used in the servlet, ejb and portlet specifications, is not sufficiently powerful for handling task assignments. That model is a many-to-many relation between users and roles. This doesn't include information about the teams and the organisational structure of users involved in a process.
The classes in yellow are the relevant classes for the expression assignment handler that is discussed next.
A User represents a user or a service. A
Group is any kind of group of users.
Groups can be nested to model the relation
between a team, a business unit and the whole company. Groups have
a type to differentiate between the hierarchical groups and e.g.
haircolor groups. Memberships represent the
many-to-many relation between users and groups. A membership can be
used to represent a position in a company. The name of the membership
can be used to indicate the role that the user fullfills in the
group.
The identity component comes with one implementation that evaluates an expression for the calculation of actors during assignment of tasks. Here's an example of using the assignment expression in a process definition:
<process-definition>
...
<task-node name='a'>
<task name='laundry'>
<assignment expression='previous --> group(hierarchy) --> member(boss)' />
</task>
<transition to='b' />
</task-node>
...Syntax of the assignment expression is like this:
first-term --> next-term --> next-term --> ... --> next-term
where
first-term ::= previous |
swimlane(swimlane-name) |
variable(variable-name) |
user(user-name) |
group(group-name)
and
next-term ::= group(group-type) |
member(role-name)
An expression is resolved from left to right. The first-term specifies
a User or Group in the identity model.
Subsequent terms calculate the next term from the intermediate user or
group.
previous means the task is assigned to the current
authenticated actor. This means the actor that performed the previous step in
the process.
swimlane(swimlane-name) means the user or group is taken
from the specified swimlane instance.
variable(variable-name) means the user or group is taken
from the specified variable instance. The variable instance can contain a
java.lang.String, in which case that user or group is fetched from
the identity component. Or the variable instance contains a User
or Group object.
user(user-name) means the given user is taken from the
identity component.
group(group-name) means the given group is taken from the
identity component.
group(group-type) gets the group for a user. Meaning that
previous terms must have resulted in a User. It searches for the
the group with the given group-type in all the memberships for the user.
member(role-name) gets the user that performs a given role
for a group. The previous terms must have resulted in a Group.
This term searches for the user with a membership to the group for which the name
of the membership matches the given role-name.
When you want to use your own datasource for organisational information such as your company's user database or ldap system, you can just rip out the jBPM identity component. The only thing you need to do is make sure that you delete the line ...
<mapping resource="org/jbpm/identity/User.hbm.xml"/> <mapping resource="org/jbpm/identity/Group.hbm.xml"/> <mapping resource="org/jbpm/identity/Membership.hbm.xml"/>
from the hibernate.cfg.xml
The ExpressionAssignmentHandler is dependent on the identity
component so you will not be able to use it as is. In case you want
to reuse the ExpressionAssignmentHandler and bind it to your user data
store, you can extend from the ExpressionAssignmentHandler and override
the method getExpressionSession.
protected ExpressionSession getExpressionSession(AssignmentContext assignmentContext);