BPM 11g - Case Management In-Depth: Case Rules Revisited

In a previous blog post I covered case rules from a design perspective but I've recently heard from customers that I'm working with that they were still missing something which would allow them to implement those rules in a case project. What follows is based on a presentation I created to put some "flesh on the bones" of case rules. Straight up I'd like to thank my colleague Prasen Pavlankar... I've used screen-shots from some of his projects to help demonstrate some points.

Case Management Runtime Lifecycle Recap

If we remember from one of the earlier blog entries on the runtime lifecycle of a case management appication, the majority of events that happen within the context of a case can be caught and acted upon by case rules, a simple example being when a document is added to a case, a case activity can be initiated containing a human task to validate the document. As mentioned in the previous rules blog entry there are only a finite number of conditions and actions that can be caught and acted upon within case rules, I'll document all of these here....

Case Rules - The Basics

• Govern and automate case progression
• Rules dictionary created automatically within case project
  • Fact types for each Case Data type pre-seeded
  • Fact types for core case objects such as Case, CaseEvent etc
  • pre-seeded Functions to manage Activities and Milestones
• Rules can be created as "IF-THEN" or Decision Tables
• Condition - Action pairs - on condition "x" do action "y"

Case Rules - The Conditions

There are only 7 basic ACM conditions....

• Case Lifecycle Event
• Case Milestone Event
• Case Activity Event
• Case Data Event
• Case Document Event
• Case Comment Event
• User Defined Event

...let's go through these one by one...

Case Lifecycle Event

...as a decision table for example....

...or as a simple IF-THEN rule....

Case Milestone Event

• Reached
• Revoked

...as a decision table....

Case Activity Event

• Activated
• Completed
• Faulted

...as a decision table....

Case Data Event

• Case data changed

Case Document Event

This applies to documents added at the level of the case via the CM API or added to human tasks which are part of processes exposed as case activities.

• Added
• Deleted
• Modified

...as a condition table....

User Defined Event

• Occurred

As a decision table....

...or more simply as an IF-THEN rule....

Case Comment Event

Although this is available I would counsel caution here. Comments are free-form text and can be added in an ad-hoc manner to a case.... implementing rules which simply act upon a comment being added could lead to unexpected results.

Case Data Contents

It is also possible to query the contents of the case data itself as conditions to a rule. For example, assume we only want to act upon a milestone being reached if the "claimant" element of our case data is "Joe Bloggs"....

Case Rules - The Actions

Now that we have queried the conditions, what actions can we take ?

• At an Activity level
  • Activate Activity
  • Withdraw Activity
• At a Milestone level
  • Reach Milestone
  • Revoke Milestone

Activity Level

• Activate Activity
• Withdraw Activity

It is important to understand what is happening when we "activate" an activity. It is a slight misnomer as it just makes the activity available for invocation if it has been created as "conditionally available"....

...whether it is actually invoked or not depends on whether it is defined as "manual" or "automatic"....

• Manual - must be invoked via the API if "active"
• Automatic - will be invoked by the engine once it becomes "active"

Milestone Level

• Reach milestone
• Revoke milestone

Case Rules - Best Practices

Rule combinations can become fairly complex....

Use globals & bucketsets to define activity names, milestone names, event names etc... this will be provided out-of-the-box in an upcoming release....

Use functions to simplify decision tables....

Break up the rules into logical decision tables....

• Lifecycle event rules
• Activity event rules
• Milestone event rules

...as described in the previous case rules blog.

Summary

Case rules are an integral part of ACM, without them events that happen within the context of a case are more or less independent. Could you design an ACM project without rules, I think you probably could but it would be over-reliant on constantly querying the state of the case via the CM API. I think this is the nub of the problem with understanding case rules... the CM API itself is powerful and all-encompassing and it can be easy to fall into the trap of controlling too much of the lifecycle of the case from the API instead of allowing case rules to do a lot of the work. This is why I think the design of case rules is so important, it forces us to consider the relationships between case artefacts.