BPM 11g - Case Management In-Depth: Cases and Case Activities Part 2 - Case Rules

In the previous blog entry we started to look at case artefacts, specifically case activities and how we should design these at the correct level of granularity.

In this entry we'll look at case rules, the "glue" that connects case artefacts together at the level of the case.

Case Artefacts & Case Rules

As of PS6, the design-time for Case Management inside BPM Studio has no "holistic" view of the case and its artefacts, however this is planned for a future release. In the absence of this I've been trying to understand how it would be possible to visualize everything that makes up a case and how these things are interrelated.

A Mind Mapping Approach

My colleagues Prasen Palvankar & Ravi Rangaswamy came up with a neat use of mind-mapping to show the case & its relationships....

... I find this great for understanding the questions that need to be asked in the design of a case from within BPM Studio..."who are the stakeholders", "what are the case activities", "which documents can be attached to the case" etc. but from this I could still not immediately grasp what my case looked like and the relationship between the artefacts.

A Spreadsheet Approach

This brought me to a spreadsheet approach.... I've used this with customers intially to get them to think about what case activities make up the case, their granularity and their inter-dependencies. I then extended this to identify the relevant case rules and if necessary the permissions that attach to each artefact.

In order to demonstrate this approach I'll use the standard EURent car rental scenario that is available with PS6.

Step 1: The case and its Artefacts

First I wanted to understand what explicit case artefacts the case consisted of... case activities, case milestones, user-defined events etc.

Specifically for the case activities, I wanted to visualise what properties they had.... manual/automatic, required, repeatable, conditional, the importance of which will become apparent later. This resulted in the following spreadsheet....

 Step 2: Understand Case Rules

This is where the importance of visualization is key. Initially case rules can seem complex and slightly overwhelming but in reality they are fairly straightforward.... in essence for case management they are just condition/action pairs... the conditions in this instance being case events and the actions being applied to a case artefact. As a result there are a finite number of combinations which can be sub-divided thus...

• Case Lifecycle Event Rules
  • when a case lifecycle event fires (condition), a case artefact is affected (action)
  • an example would be "case start" activates first case activity
• Case Milestone Event Rules
  • when a milestone event fires a case artefact is affected
  • an example would be when a milestone is reached the relevant case activity is activated
• Case Activity Event Rules
  • when a case activity event fires a case artefact is affected
  • an example of this would be one activity completes causes another to be activated
• Case Data Event Rules
  • when a case data event fires a case artefact is affected
  • an example of this would be when case data is uploaded via the API a case activity is activated to validate it
• Case Document Event Rules
  • when a case document event fires a case artefact is affected
  • an example of this would be when a document is attached to the case via the API a case activity is activated to view it
• Case Comment Event Rules
  • when a case comment event fires a case artefact is affected
  • an example of this would be when a comment is attached to the case a case activity is activated to view it
• User Defined Event Rules
  • when a user defined event occurs a case artefact is affected
  • an example of this would be the activating of a case activity on a user defined event firing

... that's it ! Seven types of condition which can result in actions on case artefacts.

Step 3: Add Dependencies

Now that we have the activities, milestones etc... for EURent, let us add the dependencies between them where they exist....

...now we can see the relevance of the case properties, specifically "conditional" since all conditional activities should have a dependency and an associated case rule, something needs to activate them (i.e. make them available, not run them).... here we can see that "Report Accident" and "Upgrade Customer" have no dependencies specified yet... we would need to go back and complete this (Note: in the EURent example, "Report Accident" activity is activated on completion of "Handover Car" activity... it is left blank here for illustration purposes)

 Step 4: Add the Case Rules

Based on the understanding of case rules in step 2 and the defined dependencies in step 3, we can now add the case rules where appropriate....

...as you can see, EURent is only using 4 of the 7 types of case rule. In theory this classification could be used in within the case rule definitions themselves in BPM Studio to group rules into their appropriate categories, e.g. a decision table(s) for "Case Lifecycle Event Rules" etc.. this should help making subsequent management of the rules easier.

Step 5: Extend to Include Security etc.

Based on the knowledge we gained around stakeholders and permissions in a previous blog entry, we could also cross-reference the permission tags for the case artefacts (Note: EURent does not use any tags for case activities)....

Summary

In the absence of a "holistic" design-time view of the case and its artefacts in PS6 (planned for a future release) it is necessary to visualize in some way the inter-dependencies. The method outlined above may not be optimal but I find it works for me for several reasons....

• Interactions with "the business" generally revolve around spreadsheets to some extent... both IT and the business can easily understand what they represent, so a spreadsheet seems the correct approach
• It is possible with one spreadsheet to easily view gaps in the rules, in the security etc.. which is the primary aim
• I like as much as possible on one page... it's not so daunting ;-)

This is the approach I am currently following with customers, so only time will tell whether better approaches are possible

Stay tuned for more case management blogs.