Master Process Pattern for Case Management with TIBCO® BPM

• Concept
• Functional Overview
• How do users manage cases using this approach?
• How can a user dynamically change the behavior of a case instance? Do I have to go via a work item?
• Where can I get a sample of this type of pattern?

This page describes a pattern for using a master process to manage a case lifecycle in TIBCO^® BPM.

Concept

The idea of this pattern is to provide a single 'model' that gives a view of a case lifecycle in a BPM Case-based application. Case Objects in BPM have their own lifecycle and do not require a process. However, processes are often used to manage cases, for example using Actions, Business Services, Processes, Tasks (User, Service, and Script tasks).

The use of a 'master process' to manage the lifecycle of the case has the following benefits:

• Consolidated view of case lifecycle at design time
• The ability to get an auto-generated audit trail of what happens for a case and related processes/tasks/sub-processes much as you would with a more traditional structured process model
• The ability to define that processes run based on rules (ad-hoc tasks)
• The ability for a process to 'react' to case changes and external signals (using global signals and case data signals to trigger Adhoc tasks)
• The ability for a process/case to move backward and forwards between states - without having to explicitly model each transition (the mega process model which is hard to understand)

Functional Overview

The concepts assume that on case creation (typically through a business service or service process) the case object 'case class instance' will be created, and a single 'master process' instance will be created. The new case instance reference is passed into the master process as a parameter.

An example 'master process' model is shown below:

The top 'main process' swimlane is very straightforward. The Start event triggers the creation of the master process, it is passed a caseReference, then it waits on a local signal 'Case Completion'. Once this is received the process is terminated.

At the bottom of the process model in the 'State Drive Sub-Processes' swimlane are a series of ad-hoc tasks. The idea of this pattern is that whilst the master process is 'running' any of the ad-hoc sub-processes in this swimlane can be executed, either triggered manually through a UI or triggered by rules.

These are ad-hoc Sub Processes. They do not have an inflow or outflow. Instead, the process defines that when they can be run on the Adhoc task properties panel:

The Adhoc task property, in this case, defines that this sub-process (Await Auto trigger) will automatically execute when the case state is waiting.

In the simplest scenario, you could define an ad-hoc sub-process to run for each case state. This sub-process might typically create a user task which a user will need to open to progress the case.

It is important to note that the Adhoc tasks are not actually running based on case data changes since those are outside of the scope of the process model. Instead, they are working on a cached copy of the process data kept with this master process instance - in this case, the 'reconcilliationCase' data field (BOM object).

In order to make this work, the master process 'subscribes' to any changes to this case reference. On a change, the local copy of the case data 'reconcilliationCase' is updated, and hence the Adhoc activities fire as required. This is managed by the part of the master process shown below:

You can see this logic in the above image. A case data signal starts this flow when case data changes - effectively it is subscribing to a case data change using the case reference passed to the master process instance. If the data 'changes' the local BOM object reconciliation case is updated. In addition note that if the case status is changed to 'resolved' the 'Case Completion' Signal is thrown. This is then caught by the main process flow and the master process (and any attached ad-hoc sub-processes) are cancelled:

How do users manage cases using this approach?

This implementation assumes that you will be controlling the case through the following mechanisms:

• User Tasks as part of ad-hoc sub-processes will be delivered to users. Users will make decisions in these tasks which will process the state - typically by updating the case data and eventually changing the case state.
• Service Processes will be exposed to external systems. These can also be called to update case data and change the case data/state.
• Catch timer/signal tasks. These will likely be part of the ad-hoc sub-processes, on expiry/trigger they will likely update case data and change the case state.

Based on the above changes, the case data will change and hence Adhoc sub-processes will fire.

How can a user dynamically change the behavior of a case instance? Do I have to go via a work item?

A common requirement of case management is that a user wants to interrupt a case and change behavior, make something else happen, such as cancel a case, move a case manually to another state, update case data. These kinds of activities are best modeled as 'case actions'. A case action can be executed based on case type, state (and limited to user privileges). These will typically present the user with a screen and then update the case data.

Note: When case actions cause case data you may want to terminate any running 'ad-hoc' sub-processes. This can be achieved by using either 'case data change' catch flows inside the ad-hoc sub-process by using 'global signals' (a pub/sub pattern). Any ad-hoc processes would, therefore 'catch' this signal and terminate themselves. An example of an ad-hoc sub-process that terminates itself on a case state change is shown below:

Where can I get a sample of this type of pattern?

A studio project (zipped Business Studio 4.1 .maa file) for the sample process pattern described above is attached along with a PDF explaining how to run the sample application.

Note you will need to unzip the master-process-sample.maa_.zip before importing the .maa file to Business Studio.

Attachments

master_process_template_sample.pdf

master-process-sample.maa_.zip