Chapter 15. Case Management

Warning

In Red Hat JBoss BPM Suite 7.0, the Case Management API will be completely redesigned.

15.1. Introduction

Business Process Management (BPM) is a management practice for automating tasks that are repeatable and have a common pattern. However, many applications in the real world cannot be described completely from start to finish and include multiple paths, deviations, and exceptions. Moreover, using a process focused approach in certain cases can lead to complex solutions that are hard to maintain. Sometimes business users need more flexible and adaptive business processes without the overly complex solutions. In such cases, human actors play an important role in solving complex problems. Case management is for collaborative and dynamic tasks that require human actions. Case management focuses on problem resolution for unpredictable process instances as opposed to the efficiency-oriented approach of Business Process Management for routine predictable tasks.

Instead of trying to model a process from start to finish, the case management approach supports giving the end user the flexibility to decide what must happen at runtime. In its most extreme form for example, case management does not require any process definition at all. Whenever a new case comes in, the end user can decide what to do next based on all of the case data.

This does not necessarily mean that there is no role for BPM in case management. Even at its most extreme form, where no process is modeled up front, you may still need a lot of the other features that the BPM system provides. For example, BPM features like audit logs, monitoring, coordinating various services, human interaction (such as using task forms), and analysis play a crucial role in case management as well. There can also be cases where a more structured business process evolves from case management. Thus, a flexible BPM system enables you to decide how and where you can apply it.

15.2. Use Cases

Here are some common use cases of case management:

  • Clinical decision support is a great use case for case management approach. Care plans are used to describe how patients must be treated in specific circumstances, but people like general practitioners still need to have the flexibility to add additional steps and deviate from the proposed plan, as each case is unique. A care plan with tasks to be performed when a patient who has high blood pressure can be designed with this approach. While a large part of the process is still well-structured, the general practitioner can decide which tasks must be performed as part of the sub-process. The practitioner also has the ability to add new tasks during that period, tasks that were not defined as part of the process, or repeat tasks multiple times. The process uses an ad hoc sub-process to model this kind of flexibility, possibly augmented with rules or event processing to help in deciding which fragments to execute.
  • An internet provider can use this approach to handle internet connectivity cases. Instead of having a set process from start to end, the case worker can choose from a number of actions based on the problem at hand. The case worker is responsible for selecting what to do next and can even add new tasks dynamically.

15.3. case management in Red Hat JBoss BPM Suite

Red Hat JBoss BPM Suite provides a wrapper API called casemgmt that focuses on exposing the case management concepts. The core process engine has always contained the flexibility to model adaptive and flexible processes. These features are typically also required in the context of case management. To simplify picking up some of these more advanced features, the wrapper API exposes some of these features in a simple API. Note that this API simply relies on other existing features and APIs, and can easily be extended. The API and implementation is added as part of the jbpm-case-mgmt module.

Process instance description
Each case can have a unique name, specific to that case.
Case roles

A case can keep track of who is participating by using case roles. These roles can be defined as part of the case definition by giving them a name and (optionally) a cardinality. Case roles can also be defined dynamically at runtime. For active case instances, specific users can be assigned to roles.

You can define roles for a case definition and keep track of which users participate with the case in which role at runtime. Case roles are defined in the case definitions as below:

<extensionElements>
  <tns:metaData name="customCaseRoles">
    <tns:metaValue>
      responsible:1,accountable,consulted,informed
    </tns:metaValue>
  </tns:metaData>
    <tns:metaData name="customDescription">
    <tns:metaValue>
      #{name}
    </tns:metaValue>
    </tns:metaData>
</extensionElements>

The number represents the maximum of users in this role. In the example above, only one user is assigned to role responsible.

The case roles cannot be used as groups for Human Tasks. The Human Task has to be assigned to a user with the case role, hence a user is selected in the case role based on random heuristics:

public String getRandomUserInTheRole(long pid, String role) {

  String[] users = caseMgmtService.getCaseRoleInstanceNames(pid).get(role);
  Random rand = new Random();
  int n = 0;

  if (users.length > 1) {
    n = rand.nextInt(users.length - 1);
  }

  return users[n];
}
Ad hoc cases
One can start a new case without even having a case definition. Whatever happens inside this case is completely determined at runtime.
Case file
A case can contain any kind of data, from simple key-value pairs to custom data objects or documents. A case file contains all the information required for managing a case, and comprises several case file items each representing a piece of information.
Ad hoc tasks

A case definition is a very flexible high level process synonymous to the ad hoc process in Red Hat JBoss BPM Suite. You can define a default empty ad hoc process for maximum flexibility to use when loaded in RuntimeManager. For a more complex case definition, you can define an ad hoc process that may include milestones, predefined tasks to be accomplished, and case roles to specify the roles of case participants

Using the ad hoc constructs available in BPMN2, you can model optional process fragments that can be executed during runtime.

This could occur in the following ways:

  • End users selecting optional fragments for execution.
  • Automatically, for example:

    • Rules that trigger certain fragments under certain conditions.
    • Whenever triggered by external services.
Dynamic tasks
It is possible to add new tasks dynamically, even if they were not defined initially in the case definition. This includes human tasks, service tasks and other processes.
Miliestones
You can define milestones as part of the case definition or dynamically, and keep track of which milestones were reached for specific case instances. You can define milestones in a case definition and track a cases progress at runtime. A number of events can be captured from processes and tasks executions. Based on these events, you can define milestones in a case definition and track the progress of a case at runtime. The getAchievedMilestones() is used to get all achieved milestones. The task names of milestones must be Milestone.

15.4. Starting a Case

In an ad hoc process definition, a case instance is created that allows the involved roles to create new tasks. You can create a new case instance for an empty case as below:

ProcessInstance processInstance = caseMgmtService.startNewCase("CaseName");

During the start of a new case, the parameter Case Name is set as a process variable name.

Alternatively, you can create a case instance the same way as new process instance:

ProcessInstance processInstance =
  runtimeEngine.getKieSession().startProcess("CaseUserTask", params);

15.5. Example Case Model

The following example of a user task demonstrates the ad hoc capabilities of case management in Red Hat JBoss BPM Suite6.4.

Figure 15.1. User Task Case Management Example

CaseUserTaskBPMN2

The provided case instance example can have the following work flow:

  1. Start a case instance:

    ProcessInstance processInstance =
      runtimeEngine.getKieSession().startProcess("CaseUserTask", params);
  2. Set roles for users.

    caseMgmtService.addUserToRole(processInstance.getId(), "contactPerson", "myuserid1");
    caseMgmtService.addUserToRole(processInstance.getId(), "contactPerson", "myuserid2");
  3. Assign Hello1 to someone with the role contactPerson.

    String userid = getRandomUserInTheRole(processInstanceId, "contactPerson");
    taskService.claim(taskId, userid);
  4. Complete the task Hello1.
  5. Trigger and complete Hello2.

    Ad hoc tasks, such as Hello2, can be triggered and completed afterwards using the following:

    caseMgmtService.triggerAdHocFragment(processInstance.getId(), "Hello2");
  6. Trigger the milestone called Milestone1 with a signal sent to the case instance:

    runtimeEngine.getKieSession().signalEvent("Milestone1", null, processInstance.getId());
  7. Create a dynamic human task called Hello3 and complete it afterwards:

    caseMgmtService.createDynamicHumanTask(processInstance.getId(), "Hello3", "user1", null, "Make XY done", null);
  8. Add a case file summary document.

    caseMgmtService.setCaseData(processInstanceId, "summary", mySummaryDocument);
  9. Trigger Milestone2:

    runtimeEngine.getKieSession().signalEvent("Milestone2", null, processInstance.getId());