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.
Determine if a farmer is eligible for benefits?
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.
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
“Eligible” is what the rules are being asked to determine
The data model to support the decision will be modeled in the Corticon vocabulary:
Figure 1 Cattle Business Object
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
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
Going back to our original simplified set of two rules:
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:
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?”
Once the rule model is complete it can be deployed to the Corticon execution engine.
Corticon offers two modes of execution:
For the Web Services option the Corticon Web Console is used.
Only authorized users can login to the console.
You can deploy a decision service using the Deployment Console
Figure 12 Deployment Console
This will show up in the server console
Figure 13 Logging on to the Server Console
Figure 14 Server Console Options
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
We can see the details of the decision service
Figure 16 Decision Service Settings
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
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
Figure 20 Analysis Tools in the Web Console
We can set up monitoring of key attributes in the decision service
Figure 21 Setting Up Monitored Attributes
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
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
(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
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
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.
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
Statistics Recorded in the Corticon Web Console
Figure 41 Monitoring the Decision Results
Figure 42 Performance Dashboard
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:
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.
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
Figure 45 Invocation from Visual Basic
Figure 46 Invocation with XML Payload
Web Services Call from Java
Figure 47 Web Services Call from Java
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.