Introduction

This decision modeling case study examines how the Corticon provides a way to automate a benefits eligibility determination yet still provide the flexibility for the business experts to create and manage the rules.




Basic Decision Modeling

Identify the Business Decision(s) to be made

Determine if a farmer is eligible for benefits?

Collect and Review Rules needed for each decision

To make this decision we will need some rules.

Here are some sample rules provided by a customer

R1: Calf sale weight less than or equal to 350 lb are not eligible

R2: Breeding stock sold is eligible provided the animals are raised from birth and the producer is enrolled in the cow-calf category

 

We will walk through the entire process of modeling these rules, including the discovery of errors, ambiguities and incompleteness using Corticon Studio. 

 

Identify Business Objects (Entities)

By referring to the rule statements we can deduce the existence of objects such as these:

Cattle  – the entity that is being considered for approval

We can also deduce that a dependent will have some attributes such as

  • Breeding Stock (true or false)
  • Enrolled in Cow-Calf program (true or false)
  • Raised from Birth (true or false)
  • Sale Weight (decimal)
  • Eligible for Cow-Calf  Program (eligible or ineligible)

 “Eligible” is what the rules are being asked to determine

Create a Corticon Vocabulary

The data model to support the decision will be modeled in the Corticon vocabulary:

  

Figure 1 Cattle Business Object

Create Sample Data

This helps to make sure the data model makes sense

This can be done in the Corticon Testing tool which is built into Corticon.

We can also set up some expected results to verify that our rules are producing the answers we expect.

We’ll see during the demo how Corticon will automatically compare the actual and expected results and flag any variations once the rules have filled in the output column

  

Figure 2 Sample Test Data

 

Decide how the rules need to be grouped into Rule sheets

There are no hard and fast rules about how to divide up the rules into groups, but a good way to start is to group the rules according to the main attribute that they are determining.

The book “The Decision Model” has some good guidelines on how to organize rules.

For our simple two rule example a single rulesheet is going to be adequate but more complex problems may require a ruleflow that joins up all the individual rulesheets that are needed:

Here’s a more complex example based on the spreadsheets provided:

  

 Figure 3 Rule Flow

For each rule statement create a rule column that connects the conditions to the actions

Going back to our original simplified set of two rules:

R1: Calf sale weight less than or equal to 350 lb are not eligible

R2: Breeding stock sold is eligible provided the animals are raised from birth and the producer is enrolled in the cow-calf category

 

Here’s what the rulesheets might look like

Figure 4 Rules Modeled as Specified

If we run the test cases this is what we will get:

Figure 5 Test Results

Black indicates that the output agrees with the expected result. So for case 1 we got the right answer.

However red indicates that the output differs from the expected results.

So in case 2 we expected to get ineligible (because the weight is less than 350lb) but we got eligible.

When case 2 is selected, the corresponding rule statement will be highlighted below.

You can see that for case 2, two rules fired. The first one (R1) got the right answer, but then a second rule (R2) fired and overwrote the correct answer with the wrong answer.

This is a rule conflict.

Also notice that case 3 did not get a result at all. This means that there are missing rules in the rulesheet.

Unless we create a large number of test cases its quite likely that we might miss both of these situations.

Corticon has a better  way to find these problems:

Ambiguity Checking

Back in the rulesheet we can use this button   to automatically check for rule conflicts:

Figure 6 Conflicts Detected

This conflict occurs because (as written) both rules can file (when the weight is under 35 and all the other attributes are true) and their results are different. If the results had been the same then it would not be a logical conflict.

To resolve this we need to make rule 2 more specific. In fact it shoud probably only apply when the weight is greater than 350. If we make that change then there will be no conflict:

Figure 7 Conflicts Resolved

Next we can use the completeness checker button to find the missing rules:

Figure 8 Completeness Checker Finds Missing Rules

The rule author still needs to determine the appropriate action in each case and add an appropriate rule statement:

Figure 9 Actions and Rule Statements

Now at this point all the rules are mutually exclusive so when the weight is over 350 only one message will display if they fail to meet one of the other criteria.

If we wish to display a message for ALL reasons they failed then we can change the rules to this:

Figure 10 Alternative Rulesheet

Now even though rules 3, 4 and 5 are no longer mutually exclusive they are not in conflict because they all have the same result.

If we decide it’s not necessary to give a specific message for each of the reasons for failing the rules we could model the rulesheet in this way

Figure 11 Setting a Default

In this rulesheet column zero sets the eligibility to a default of “ineligible” and only when the data meets all the criteria is that value reset to “eligible”. While this results in fewer rules this is not recommended as best practice since there is now no way to know the reason for the “ineligible” result.

Unfortunately in traditional applications you see this problem all the time – you get a message back saying that your data is invalid but giving you absolutely no clue as to what is wrong with it.

Basically the question you have to ask is “Do I need to treat the different outcomes differently or the same?”




Deploy Decision Services

Once the rule model is complete it can be deployed to the Corticon execution engine.

Corticon offers two modes of execution:

  1. Web Services
  2. In-process execution

 For the Web Services option the Corticon Web Console is used.

Only authorized users can login to the console.

 

The Deployment Console

You can deploy a decision service using the Deployment Console

Figure 12 Deployment Console

This will show up in the server console

 

The Web Console

Figure 13 Logging on to the Server Console

Figure 14 Server Console Options

Viewing Deployed Decision Services

The first option allows you to see the currently deployed decision services.

S1, S2, S3 and S4 are different stages in the development of our Contra Loss rules

Figure 15 Deployed Decision Services

Decision Service Details

We can see the details of the decision service

Figure 16 Decision Service Settings

Web Interface for Viewing the Rules

We can view the rules as they are in the server using a web interface:

 

This shows  the natural language view of the rules in the web browser

Figure 17 Natural Language View of the Deployed Rules 

 

Editing the Rules in the Web Interface

We can even edit the rules using this web interface

First we create a new version from the existing version

Figure 18 Creating a New Version in the Web Console

Now we can edit the rules or the rule statements (access to this is configurable)

Now the rule values become editable

Figure 19 Web Based Rule Editor

This view allows a business user to change the values tested in the rules but not to add new rules

The web editor includes the analysis tools

Figure 20 Analysis Tools in the Web Console 

 

Monitoring Key Decision Service Attributes

 We can set up monitoring of key attributes in the decision service

Figure 21 Setting Up Monitored Attributes

Running Tests from the Web Interface

You can also run test cases in the web interface

First export the test case from Studio as an XML file (or create it some other way)

Figure 22 Exporting a Test Case as XML

 

Specify the location of the test data

Figure 23 Setting Up  a Test in the Web Console

The results will come back as XML

Figure 24 Test Results from Web Console 

 

Invoking Deployed Decision Services from Corticon Studio

We can now set up a test in Studio that invoke the deployed decision service

 

Figure 25 Using Studio to Execute Deployed Decision Services

 

By clicking on the number of executions you can view the performance statistics for that decision service:

Figure 26 Execution Count

 

Details of the monitored attributes can be viewed:

Figure 27 Monitored Attributes


 

Invoke the production rules via the application code (or BPM)

(note: from this point on a slightly different rule model is used in the example, but the principles are the same)

Once the decision service is deployed on the production server it can be invoked by any SOAP Client or by any BPM software that can make a web services call or from application code such as Java or .NET

Using Other SOAP Clients

These same tests can be executed from any SOAP client such as SoapUI .

In order to do this you must first generate the WSDL for the decision service.

This is done from the deployment console which is accessible in Studio:

Figure 28 Deployment Console in Studio

 

A generic SOAP client such as SOAP UI can be used to set up and run tests against the deployed decision service:

Figure 29 A Typical SOAP Client

The SOAP Request would look like this

Figure 30 Corticon SOAP Request

The results are resulted similarly to what you see in the Corticon tester:

Figure 31 Corticon SOAP Response

In fact you can export this soap message from the test cases in Studio:

Figure 32 Studio Test Data

By selecting from the Test menu

Figure 33 Studio Export SOAP Menu

 

BPM Clients

Corticon also partners with many of the BPM vendors.

Here’s an example of a business process that invokes a decision service.

Most BPMs provide for the import of WSDL and automatically generate the necessary connection to external web services. All that is required to invoke the decision service is to map the process variables to the input variables of the decision service.

Savvion Integration

Figure 34 Decision Service Invoked from a Business Process (Savvion)

 

Process attributes are mapped as inputs to Corticon

Figure 35 Mapping Corticon Inputs

Corticon results (status) is mapped to process attributes:

Figure 36 Mapping Corticon Outputs

Processes are started in the BPM Portal

Figure 37 Starting the Business Process

Inputs are entered on the web form

Figure 38 Web Data Entry Form

These are then passed to the Corticon rule engine

The user’s task list can be viewed:

Figure 39 User's Task List

The results are then displayed

Figure 40 Suspension Status Determined

Savvion Web Application

Statistics Recorded in the Corticon Web Console

Figure 41 Monitoring the Decision Results

PCT Dashboard

Figure 42 Performance Dashboard

Java Clients

Decision Services may also be invoked from programming languages such as Java.

In this case, in addition to the web services interface, you can also make a direct in-process call. To do this the Corticon Server classes are compiled into your java program. Then you can invoke the server class “execute” method and pass the data either as XML or as native java objects.

Here’s an example of the core java code you would write to invoke a decision service:

In-Process Java with Java Objects

Figure 43 In-Process Execution with Java  Payload

The actual code would contain additional statements to populate the FEMAdata object , to catch any errors and to process the results coming back from the rule engine.

Java with XML Payload

Here’s generally how our programmer will make an in-process call to the rules  using an XML payload:

Figure 44 In-Process Execution with XML Payload

Visual Basic Invocation

Figure 45 Invocation from Visual Basic

In-process call with XML

Figure 46 Invocation with XML Payload

Web Services Call from Java

Figure 47 Web Services Call from Java

 

Performance

  

 

 

 

Why is Corticon so much faster than Traditional Rule Engines?

In a traditional (RETE) rule engine a significant portion of the execution time is allocated to figuring out which rule to execute in which sequence – and if you process 1 million transactions the engine has to do this figuring out a million times.

Corticon does the figuring out ONCE at design time and so execution performance is considerably better than RETE based engines for most business rule applications.

 

Additionally Corticon scales linearly as the number of rules and the amount of data increases. RETE engines eventually reach a point where performance drops off dramatically as the data payload increases. RETE does scale well with increasing number of rules however.

Download

Download PDF version.