In order to put rule writing into the hands of the business users there are a couple of approaches:
In this document we’ll explore approach 2 – Parameterized Rules.
There are several options for the Parameterized Rules approach:
In this document we’ll show how to accomplish option #3.
Detailed Edit Screen
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:
The Corticon Rules would look something like this for finding any gaps in the ranges
In order to find ambiguities in the ranges the rules might look like this:
Then in the application that actually needs to apply the business rules that depend on these parameters you might see rule sheets like this:
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:
Create a Data Direct Cloud Source that points to your Rollbase instance.
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.
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)
Enter the URL for your Corticon Server (You can try mine, but it won’t always be running)
But only if you need to extract additional data from the Corticon return payload