JBoss at Google Summer of Code

JBoss is mentoring projects at this year Google Summer of Code again. If you interested in working on jBPM or JBoss projects in general then please checkout the list of available projects.

jBPM offers a list of projects that will be mentored by Tom and me. If you are interested in one of those get in touch with us.

jBPM Task Management: A look at the participation model

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
   */
  List findTasksByParticipation(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 
   */
  List findTasksByParticipation(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.

Task management extensions: Human interaction management

a) Application: Some process being executed that hits a task activity

b) Task Mgr: The current jBPM4 base model for managing tasks. It includes assignments, variables, etc.

c) Notification Mgr: Decouples the notification features. I.e. email, ical,etc. The idea is borrowed from the latest code contribution.
How and if the task management does notifications will be pluggable. We will probably provide a smtp notification mechanism as the default.

d) Form Mgr: Interfacing the outside world. Formost use would be HTML forms of some kind, but can be a WS interface as well. The Form Mgr relies on the variables and resources associated with a process.

RFC: Process deployment use cases

This is a request for comments.

Since 4.0.0.Beta1

• What deployment use cases do we want to cover?
  
• What constraints should apply for each use case?
  

The matrix below shows the constraints for the deployment policies that are currently implemented:






Explanation:

There is currently four properties that are taken into consideration when processes get deployed:
the process name and version (part of jpdl.xml), the artifact name (i.e OrderProcess.par) and the artifact timestamp.
Process name, version and artifact name are the main properties that distinguish process deplyoments, the timestamp basically just acts as a fallback when no version is given and leads a version auto-increment.

Possible combinations of those properties lead to matrix above.

Work on the jBPM4 deployer started

Jbpm4 Deployer

View more presentations from hbraun.