Figure 1 Rule Flow Diagram
Figure 2 Project Folder Structure and Rule Sheets
Let’s start with the rule BR1:
Active at time of retirement and receives maximum insurance subsidy available. Must earn one-tenth
(0.1) or more years of service in each of the five school fiscal years immediately before their retirement
effective date, or at least one-half (0.5) years of service within the two school fiscal years immediately
before their retirement effective date
This is really two rules that define whether a person meets the criteria to receive the maximum subsidy
Figure 3 Rule Statements
Figure 4 Formal Rule Expressions
We could try to verify the rules using test data:
Figure 5 Testing the Rules As Specified
This does seem to give the correct results for persons 1 and 3.
However there are many other persons in the test data that get no results or messages. This is not very helpful – we really need to know why those persons got no result. Was it because of bad data or was it because they did not meet the conditions of the rule.
If we go back to the rule sheet and run the completeness checker we will see a number of conditions that we are not addressing:
Figure 6 Completeness Checker finds many missing conditions
Corticon identifies the following combinations of conditions that we have not addressed:
Figure 7 Completeness Checker adds missing conditions
Let’s take a closer look.
After splitting and cleaning up we might arrive at this:
Figure 8 Distinguishing Data Errors from Rule Failures
Since the null conditions apply regardless of the values of the other attributes we can further clean this up as follows:
Figure 9 Cleaned Up Rules
Now let’s see if there are any rule conflicts:
Figure 10 Conflict Checker finds ambiguous rules
What does this conflict mean? Is it really a conflict? Can both of these conditions arise?
Rule 4 means they have a prior MIP Plus and thus are ineligible. Rule 6 means two critical fields are missing. So we have to decide what action to take. In this case it doesn’t actually matter that we don’t know the values of the two prior years’ earnings. They still won’t be eligible even if they are both true.
So effectively rule 4 overrides rule 6. We can indicate this in the override section.
The next conflict is between 4 and 8
Figure 11 Resolving Conflicts with overrides
which we can deal with in a similar fashion.
Rules 6 and 7 can be dealt with the same way too
Now with these changes, the conflict checker is happy:
Figure 12 After Conflicts are resolved
But just to be sure let’s run the completeness checker one more time:
Figure 13 Still some missing rules
Looks like we missed something when we made these changes
In both these cases we cannot make a decision since we have critical missing data.
So after fixing this we end up with:
Figure 14 Complete and Consistent Rule Sheet
Which is both complete and consistent.
Here’s an alternative way to make the rule sheet complete and consistent which is a little cleaner.
Figure 15 Alternative Rule Sheet
In this avoid conflicts by make always setting the eligibility to false when there is bad data or the data does not meet the rule criteria.
So you can see that what appears to be a couple of very simple rules turns out to be quite complex.
It’s not very surprising that attempting to code this in a traditional programming language is rarely successful.
These help make the rules easier to read for those people who are not regular users of Corticon Studio.
Figure 16 Adding Natural Language Statements
Decisions may be deployed in two ways:
In this case study we’ll use Web Services Deployment
When the Corticon Execution Environment (Server) is installed (under Tomcat, Websphere, Weblogic etc) you can publish decision services in a number of ways
For this case study we’ll use the Studio publish option.
A decision service in Corticon is defined by a Rule Flow.
We already showed the rule flow for this case study earlier:
Figure 17 The Decision Rule Flow
In addition to the diagram, you can also define some properties, such as the version and more importantly the effective dates for the decision.
Figure 18 The Decision Properties
Once this is done you can use the publish option:
Figure 19 Publishing from within Studio
The first step is to select the server that you want to deploy to:
Figure 20 Selecting the Server to Publish to
We’ll use localhost. This brings up a list of the decisions that are available for deployment:
Select the one you want. You can rename it if you like.
Figure 21 Choosing the Rule Flow
You should then see the decision listed in the console browser window:
Figure 22 Viewing the Decision in the Web Console
Notice that the execution count and average execution time columns are currently zero (since we haven’t executed this decision on the server yet)
You can also see some other decisions on the server.
You can inspect the properties of the decision by clicking on its name:
Figure 23 Overview of the Decision Properties
You can use this screen to configure the decision service:
Figure 24 Configuring the Decision Service
In particular we’ll configure the decision so that it monitors the number of persons that are eligible or not eligible for the maximum subsidy:
Figure 25 Setting a Monitored Attribute
The list of monitored attributes will show up here:
Figure 26 View a List of Monitored Attributes
Now we are ready to execute this decision.
In a production environment we might write a java program that makes a SOAP call to the rule engine, or we might use a Business Process Engine that can invoke a web service as one of its tasks.
Before we get to that point however, we can test the web service call from within Studio.
This is done in the tester.
To do this we just select the Corticon Server URL (rather than a rule flow or rule sheet inside Studio):
Figure 27 Select the Deployed Decision Service for Testing in Studio
The test subject will change accordingly:
Figure 28 The Decision Service URL
Incidentally this is the URL you would use to call the decision service from other applications.
Now we can run the test (say 10 times)
We should get some results back like this:
Figure 29 Test Results
Now if we go back to the Web Console we’ll see that the execution count has been updated:
Figure 30 Execution Statistics
And if you click on the number 10 you will see the details of what happened.
First the performance
Figure 31 Monitoring Average Execution Time
The initial spike at 22 ms is for the initial loading of the decision for a single execution.
The following 9 executions are very fast.
The distribution chart shows how the results were broken down.
Figure 32 Viewing the Monitored Attribute Graphs
There were 70 transactions in total (10 lots of 7).
At this point we might want to check in the project to our repository for safe keeping.
Because Corticon’s rule assets are all simple files (XML) any content management system can be used for controlling the assets.
In this case study we’ll use the TEAM plugin from Roundtable Tugboat (A Progress partner) to manage our assets.
The project has already been configured to use TEAM:
Figure 33 Project Structure with Change Decorations
You can see some of the assets are flagged with * (they have been modified since the last checkin) and some of them are flagged with + (they are new). The rest haven’t changed.
The TEAM check in is performed here:
Figure 34 Checking In a Project
We can record some suitable commentary about the changes we are checking in:
Figure 35 Documenting the Changes
If we go to the history tab we can see the history of changes made to this project (and who made the changes):
Figure 36 The Complete History of Changes
If you select a specific change you can see all of the assets that we modified as part of that change:
Figure 37 Details of a Specific Change
If you select two assets you can compare them:
Figure 38 Comparing Assets
You can also compare two changes:
Figure 39 Comparing Changes
This will bring up a structure compare diagram:
Figure 40 The Change Structure Diagram
Selecting an item will bring up a detailed compare screen:
Figure 41 Comparing Changes
Eventually the rules will be used by a real application. This might be a batch processing job that sends many records to the rules for evaluation or it might be a web based application that handles a single record at a time.
For this case study we’ll examine the use of Rollbase, one of Progress’s Pacific software products that enables the rapid development and deployment of web based applications.
Connecting to Corticon
Blue annotations indicate terms used by the rules
Red indicates questions or comments.
What is the decision that’s being made?
Do we have a UML diagram or data model?
MPSERS - Insurance Premium Subsidy Eligibility: Basic Plan, Basic 4, MIP 7, MIP Fixed, and MIP Graded members (does not include anyone who has ever been MIP Plus)
Are these the plans to which the rules apply?
What does “ever been MIP Plus” mean?
Do we have data about all previous plans they have been enrolled in?
If Active at time of retirement and meets (A) or (B) then receives maximum insurance subsidy available.
(A) Must earn one-tenth (0.1) or more years of service in each of the five school fiscal years immediately before their retirement effective date,
(B) at least one-half (0.5) years of service within the two school fiscal years immediately before their retirement effective date
Active at time of retirement and receives maximum insurance subsidy available.
Must earn one-tenth (0.1) or more years of service in each of the five school fiscal years immediately before their retirement effective date, or at least one-half (0.5) years of service within the two school fiscal years immediately before their retirement effective date
Insurance Premium Subsidy Eligibility for participants who Deferred at time of retirement:
a. if Terminated after October 31, 1980, with at least 21 years of service then The subsidy will be 10 percent for each year of credited service they have over 20 years. With 21 years of service, they get 10 percent of the full subsidy. With 25 years the subsidy increases to 50 percent. If they retire with 30 or more years of service, they are entitled to the maximum premium subsidy allowed by statute as of their retirement effective date (unless they are subject to a delayed premium subsidy). The maximum subsidy is 80 percent beginning January 1, 2013; 90 percent for those Medicare eligible and enrolled in the insurances as of that date.
b. if Terminated after October 31, 1980, with less than 21 years of service then The participant may enroll (multiple plans?) for the health, prescription drug, and dental/vision insurance, but must pay the full premium.
c. If Terminated on or before October 31, 1980 then The retiree is eligible for the maximum premium subsidy allowed by statute as of their retirement effective date. The maximum subsidy is 80 percent beginning January 1, 2013; 90 percent for those Medicare eligible and enrolled in the insurances as of that date.
Insurance Premium Subsidy Eligibility for participants who Delayed Insurance Subsidy:
a. Participant became a member (enrollment date) of the retirement system before July 1, 2008.
b. Participant is applying for full retirement under the (plan name?) MIP 46 with 30, Basic 55 with 30, or Early-Reduced retirement.
c. Participant initiated a service credit purchase on or after July 1, 2008, that allows them to qualify for their pension earlier than if they had not made the purchase.
d. Participant is not qualified under a disability or duty-related death provision.
MPSERS - Insurance Premium Subsidy Eligibility for: MIP Plus members only
MIP 60 with 10
If, as of their retirement effective date, they have between 10 and 23 total years of service, a graded premium applies. With 10 years of service, a 30 percent subsidy is available. The subsidy increases by an additional 4 percent for each additional year of service.
SERS - For the person who attains eligibility through Service. Eligibility for insurance participation:
SERS - For the individual who attains eligibility through service.
Eligibility for insurance participation:
Defined Benefit Participation
a. SERS DB Classified, SERS DB30
i. Requires the existence of a retirement effective date.
b. SERS DB-DC Transfer,
i. Requires the existence of a termination date (eligible for DB insurance premium benefit).
Age 60 with a minimum of 10 years of service
Defined Contribution (DC) participation:
a. Regular State Employee
i. Age 60 with 10 years of serviceii. Age 55 with 30 years of service
b. Covered Employees
i. Age 56 with 10 years of covered serviceii. Age 51 with 25 years of covered service (3 years before termination must be in a covered position)(continuous or total? One position or multiple positions? Gaps allowed?)
c. Conservation Officers
Any age with 25 years of service (must have 23 years as a conservation officer , and the 2 years immediately before termination must be as a conservation officer).
Should we create our own data model to support these rules?
Add database access?
Add Rollbase application interface?
Develop a fact model in RuleXpress (or Rollbase, or DecisionsFirst)