The Use Case

In order to put rule writing into the hands of the business users there are a couple of approaches:

  1. Give them a copy of Corticon Studio and allow them to modify the rules – this assumes that they are skilled in rule modeling using Corticon. It also does not provide a way to control what parts of a rule model an individual is allowed to change.
  2. Give them a simplified interface which limits and controls what part of which rules they can change – typically this interface allows a business user to change the values or thresholds that are used in the underlying Corticon rule model. This is referred to as “Parameterized Rules”


In this document we’ll explore approach 2 – Parameterized Rules.


There are several options for the Parameterized Rules approach:

  1. We could simply allow the business users to go to the database holding the parameters and change them. The danger of course is that there are no controls over what values they might enter.
  2. We could create a java application that manages the “rules” or “parameters” – but this would involve a significant amount of development effort.
  3. We could use Rollbase Rapid Application Development to create a parameter management system. In this approach we can then use Corticon to help validate the parameters that are entered by the user.


In this document we’ll show how to accomplish option #3.


The Rollbase Solution

Detailed Edit Screen



Using Corticon to Validate the Parameter Values

Whenever a change is made to any parameter, Corticon needs to be invoked (via a trigger) to perform some validation checks. Corticon would need to retrieve ALL the records from the Rollbase database corresponding to the parameter name that had been modified. So the template for the data to be passed to Corticon would simply have the name of the parameter:

  1. Is the value valid
  2. Are there overlaps with other parameter values (ambiguity)
  3. Are there gaps in the ranges (incompleteness)


Using Corticon to Find Gaps in the Parameter Ranges

The Corticon Rules would look something like this for finding any gaps in the ranges


Using Corticon to Find Ambiguities in the Parameters

In order to find ambiguities in the ranges the rules might look like this:



Using the Parameters in a Corticon Rule Sheet

Then in the application that actually needs to apply the business rules that depend on these parameters you might see rule sheets like this:



A Test Case

Here’s a sample test case showing both the detection of problems with the database parameters and the results of applying the rules to some patient data:



How to Connect Corticon to the Rollbase Database

Create a Data Direct Cloud Source that points to your Rollbase instance.

Choose Rollbase as the data source

Enter your Rollbase Credentials

On this screen use the user id and password for the selected data source.

For Rollbase it will probably be your Progress id and password

NOTE: When you add business objects to your Rollbase instance you’ll need to recreate this data source otherwise it won’t pick up the newly added objects.

Set up EDC in Corticon to point to your DDC source:

The user id and password is the one you use to connect to DataDirect (probably your Progress id and password)


Import the database meta data into Corticon:

Adjust any mappings as needed:


Publish the decision service to your favorite Corticon server.

Make sure to set “read/update” for database access

Note that since the Rollbase instance is up in the cloud it will need to be able to “see” the URL for your Corticon instance. If Corticon is on your laptop then you may have to do port forwarding on your home router so that Rollbase can get to your Corticon server.


Configure the Web Console

In the web console, set up some monitored attributes to you can see what values are being passed into Corticon and what values the rules are producing.  This can be very helpful in tracking down problems.

A common problem is setting a Corticon value to something other than the contents of a picklist in Rollbase.


Modify the Document Template so the decision service name matches what you used when you deployed the decision service.

If you decide to pass any additional fields to the rules you can add them here.

If appropriate you could add either a version number or an effective date (but not both)


Modify the Request Trigger

Enter the URL for your Corticon Server (You can try mine, but it won’t always be running)



Modify the Response Trigger

But only if you need to extract additional data from the Corticon return payload