Ruleflow versions and effective dates

You can apply versioning and effective dates so that you can focus requests, and delimit availability of a Decision Service

Ruleflow version

Major and minor version numbers for Ruleflows are optional. With the Ruleflow open in its editor, select the menu command Ruleflow > Properties, and then enter the Major Version and Minor Version as integer values, as shown:

When you use different version numbers to describe identically named Ruleflows, the Corticon Server keeps each Decision Service distinguished in its memory, so it can respond correctly to requests for a specified version. In other words, an application or process can use (or call) different versions of the same Decision Service depending on certain criteria. The details of how this works at the Server level are discussed in the topics at Decision Service versioning and effective dating .

Version label

You can add a text descriptor to the Ruleflow by typing in the Version Label field. The description stays with the Ruleflow file, and is packaged in any Decision Services created from the Ruleflow. In the Web Console, every deployed instance of the Decision Service lists the Version Label on its details page.

Major and minor versions

Major and Minor version designations are arbitrary and can be adapted to fit the version naming conventions used in different environments. As an example, Ruleflow minor versions can be incremented whenever a component Rulesheet is modified. Major Ruleflow versions can be incremented when more substantial changes are made to it, such as adding, replacing, or removing a Rulesheet from the Ruleflow.

Version numbers can be incremented, but not decremented.

For details about how to invoke a Ruleflow by version number, see the topic Decision Service versioning and effective dating .

Effective and expiration dates

Effective and expiration dateTimes are optional for Ruleflows and can be assigned singly or in pairs. When you use different effective and expiration dateTimes to describe identically named Ruleflows, the Corticon Server keeps them straight in memory, and responds correctly to requests for the different dates. In other words, an application or process can use different versions of the same Ruleflow depending on dateTime criteria. The details of how this works at the Corticon Server level is described in the Deployment Guide.

Effective and expiration dates can be assigned using the same window as for the version numbers. Clicking on the Effective Date or Expiration Date drop-down displays a calendar and clock interface, as shown:

Setting a specific target date for a Ruletest

When you execute a Ruletest against a corresponding Decision Service that is deployed and running on a Corticon Server that was deployed with effective and expiration dates, the day you are testing the Decision Service could be impacted by the data constraints. The ability to set a target date lets you execute the test as though it were sent at a specific date and time. Using this feature enables setting the clock back to see how past date ranges would have handled a request, as well as setting the clock forward to test deployed Decision Services in pre-production staging.

To set a version and effective target date for a Ruletest:

1. With the Ruletest in its editor, choose the menu command Ruletest > Testsheet > Select Test Subject.
2. Select the Run against Server tab, select a Server URL, and then click Refresh.
3. Click on a Decision Service in the list.
4. In the Optional Overrides section, specify the Decision Service's version identity and effective target date to use for the Ruletest, as shown:

   

5. Click OK. The dialog box closes. The details of the deployed Decision Service and its overrides are displayed at the top of the Testsheet:

   

6. Run the Ruletest.

The test executes against the specified Decision Service on the selected server using the overrides you entered.