## Step 3 - Determine the Decisions and Sub-Decisions

Figure 1 Rule Flow Diagram

## Step 4 - Identify the rule sheets

Figure 2 Project Folder Structure and Rule Sheets

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

## Step 5 - Copy the relevant rule statements into the appropriate rule sheet

This is really two rules that define whether a person meets the criteria to receive the maximum subsidy

Figure 3 Rule Statements

## Step 6 - Model the Formal Rule Expression.

Figure 4 Formal Rule Expressions

## Step 7 - Verify the Rules

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.

• Case 3 is basically saying Corticon wants to know what to do when the currentPlanName is not one of {'Basic', 'Basic 4', 'MIP 7', 'MIP Fixed', 'MIP Graded'}. There’s a more concise way we can express this concept – Corticon has a special keyword other. Most likely in this situation we might want to report an error.

• Case 4 deals with the situation where the current plan name is acceptable but the person has previously been enrolled in the MIP Plus plan.  In this situation they are not eligible.

• Case 5 has a valid plan, no prior MIP Plus, active at time or retirement but neither of the prior years earnings is true. If the values of these attributes are both null then we cannot make a decision. If they are both false then the person is not eligible. So this rule needs to be split into two. One that deals with missing data and one that finds the person not eligible.

• Case 6 also needs to be split so we can distinguish between the missing data condition and the not active at time of retirement condition.

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.

## Step 8 - Add Natural Language Statements

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

## Step 9 - Deploy the Decision

Decisions may be deployed in two ways:

1. As web services
2. As in-process execution

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

1. Publish option in Studio
2. Create a CDD using the deployment console
3. Use the Web Console to deploy a decision

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).

## Step 10 - Check in The Project

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

## Step 11 - Connect the Rules to an Application

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

1. Create a SOAP template – specifies the payload to be sent to Corticon
2. Create a Request Trigger – this sends the SOAP payload to Corticon
3. Create a Response Trigger – this extracts the results from the response payload

## Appendix A - The Rules

Blue annotations indicate terms used by the rules

What is the decision that’s being made?

Do we have a UML diagram or data model?

## Questions.

Should we create our own data model to support these rules?