Using JBPM to support advanced user interaction mode

Many common business processes include human participants. Human activities, from simple scenarios (such as manual approval) to complex scenarios (involving complex data entry), introduce new aspects into the process implementation, such as human interaction patterns. A typical collection of human interaction patterns includes:

The four-eyed principle (the 4-eyes principle), often referred to as "segregation of duties," is a common scenario in which decisions are made by many people independently of each other. In many cases, it is easy to get another idea/signature.

Appointment (nomination) refers to a situation in which a superior assigns a task to him manually according to the task arrangement, workload or experience of a team member.

Tasks are often modeled to express an expectation that they will be completed within a certain time period. If the task does not progress as expected, an escalation (escalation) mechanism is required. Two typical escalation implementations are reassigning tasks, often with a notification that an escalation has occurred, or a task that is not completed on time (usually to a manager).

Chain execution (Chained execution) is a process (fragment) in which a series of steps are performed by the same person.

Task management in the JBPM

One of the core functions of jbpm is to manage tasks and task lists for human beings. JBPM allows tasks and task nodes to be used as part of the overall process design.

Tasks are generally defined as task nodes in JBPM. A single task node can contain one or more tasks. A public behavior of the JBPM process that contains the task nodes is to wait for all tasks in the task node to complete before continuing. A task can be assigned to a person, a user group, or a swim lane:

If the task is assigned to a particular user, then only the consumer can execute it.

If the task is assigned to a user group, then any participant in the group can perform the task. JBPM uses the contributor pool (pooled actors) symbol (which can contain group names, list of group names, and participant personal lists) rather than group IDs. If users start to perform tasks in their group task list, they may end up with a conflict--more than one person may start doing the same task. To avoid this, users should move tasks from the Group task list to their own task list before starting the task.

A swim lane represents a process role, which is usually assigned to a user group. It is a mechanism that specifies that multiple tasks in a process are to be completed by the same participant. Therefore, after the first task is assigned to a lane, the process remembers that all subsequent tasks in the same lane will be completed by the same participant.

JBPM provides two basic ways to define task assignments: As part of a process definition or as a programmatic implementation. If it is part of a process definition, the assignment can be done by specifying a specific user, user group, or swim lane. In addition, you can use an expression to dynamically determine a specific user based on a process variable. The complete programming implementation is based on the allocation processor (assignment handler), which allows the task to find a user ID based on arbitrary calculation rules.

A process definition describes a process instance in a manner similar to how a task describes a task instance. When a process executes, a process instance-the Run-time representation of the process-is created. Similarly, a task instance-the Run-time representation of a task-is created. Task instances are assigned to a Contributor/Contributor group, depending on the task definition.

One of the roles of task instances is to support user interaction--displaying data to users and collecting data from users. A JBPM task instance has all the permissions of the access process (token) variable, and can also have its own variables. The task can have its own variables that are useful for the following scenarios:

Create a copy of the process variable in the task instance, so that immediate updating of the task instance variable affects the process variable only when the task completes and the copies are submitted to the process variable.

Create a "derived (calculated)" variable that better supports user activity.

The task's own variables are supported by the Task Controller processor (Tasks controller handler) in JBPM, which generates task instance data (from process data) when the task instance is created, and submits the task instance data to the process variable when the task instance completes.

To achieve the four-eye principle

As we have said above, achieving the four-eye principle means allowing more people to do a job at the same time. There are several possible ways to implement this:

Resolve outside the task: a task parallel loop that requires a lot of time (parallel looping).

Using the Action processor (action handler): An entry event that is attached to a task node (enter events) to create multiple node instances based on the process instance variable.

Resolve within a task: the introduction of Task acceptance (take) (similar to JPDL 4) and allow a task instance to be accepted multiple times.

Based on JBPM best Practices-"extending the JBPM API rather than dealing with complex process modeling", I decided to take the approach of the task. This requires modifying the task and task instance classes provided by JBPM.