Versioning provides a way for InRule to execute different calculations and rules at various points in time. This allows the calling application to set dates in the rule application that determines which rule and calculation versions to use if there are other versions in addition to the default. All calculations have a default version which is used if no matches are found.
The first step in defining versions is to specify that the rule application will use versioning, and the dates that will be used to control the versioning logic. By default, versions are disabled. To enable them, check the Use versions setting in the rule application Settings. The Effective date and Created date can be set at the rule application, entity, rule set, and rule levels.
You will see that by default, only the Effective date is enabled, and set to the Current Date (resolved by the Today() function when rules execute). The Created date setting is disabled by default; this adds a more complex two-dimensional version selection mechanism, which will be explained later in the examples.
Now that versions are enabled, the following editors will display a Versions tab in the property panel that are used to configure the versions:
- If/Then rule (condition expression)
- If/Then/Else rule (condition expression)
- While rule (condition expression)
- Set Value action (value expression)
- Decision Table
- Language Rule
- Calculation Field
- Inline Table
- Database Table
The following screenshot shows a new calculation field with its default version selected.
This Calculation will display the test value “123” when it evaluates. A new version may be added by clicking the green + button. A new version is created and the existing Calculation expression is copied from the (Default) version; this can be changed to a different value or expression. The version’s Name and Effective Date may also be edited. In this example, version “v2” will cause the Calculation to evaluate to “321” when rules execute on or after 1/1/2035. (This could be tested by advancing the system clock to 1/1/2035)
By clicking back and forth between the two versions, the Calculation’s expression should change accordingly.
In this simple example, the Calculation’s version is determined by the value of the Effective Date when rules are executed. The Effective Date has been configured in the Rule Application’s Version Settings to evaluate to the current date (the result of the Today() function). If we introduce a Date field to the same Entity as the Calculation, the value of this field may be used as the version selector instead of the current date:
Now the version selection depends on the value of TestDate rather than the current date. Any date prior to 1/1/2035 will select the (Default) version; any date on or after 1/1/2035 will select the “v2” version.
The Version Settings that define the values of Effective Date and Created Date during rule execution may be overridden at different contexts in the Rule Application.
When versions are enabled, the following editors will display a Version Settings tab in the property panel that are used to override the Effective Date and Created Date for any rule or calculation relative to them:
- Rule set
- If/Then rule (only when authored at the root of a rule set)
- If/Then/Else rule (only when authored at the root of a rule set)
- While rule (only when authored at the root of a rule set)
- Language Rule (only when authored at the root of a rule set)
- Decision Table (only when authored at the root of a rule set)
The previous example illustrated how the Effective Date was used to select a version of a calculation field to evaluate. This works fine for ‘Entity1’, however there might not be any field named ‘TestDate’ relative to other Entities. For example, if a new Entity ‘Entity2’ were added to the Rule Application, and it only contained the same calculation field and versions as Entity1, it has no reference to a field named ‘TestDate’. The Rule Application would fail to validate if this scenario were authored.
To make this work, we can set the value of the Effective Date specific to each Entity. The Effective Date in the Rule Application Version Settings can be reverted to Current Date (the Today() function).
When ‘Entity1’ is selected, its Version Settings panel may be used to override the value of Effective Date for any rule or calculation in the context of ‘Entity1’:
The Rule Application will now validate successfully. ‘Entity1.Calculation1’ will use the version determined by the value of ‘Entity1.TestDate’. ‘Entity2’ has no Version Settings override, and therefore ‘Entity2.Calculation1’ will use the Current Date as defined by the Rule Application’s Version Settings.
Effective Date Example
The following illustrates a real world scenario using versions and the Effective Date:
A simple Invoice/LineItem Rule Application calculates the invoice total based on the price + quantity of line items, and the sales tax applied to the sub total.
First we enable versioning, using the Rule Application’s default Version Settings:
Next we add an ‘Invoice’ Entity and configure its Version Settings:
Now we can configure versions in the Versions tab for the ‘SalesTax’ calculation field. This example uses the UK sales tax history to calculate the applicable sales tax for domestic purchases based on the ‘InvoiceDate’:
By testing this Rule Application in irVerify, you can see how the total changes based on the value of the ‘InvoiceDate’ field.
When a new sales tax rate is announced, the retailer can simply add a new version for the ‘SalesTax’ calculation field that represents the new rate. This rate will only be applied when invoices are created on or after the date of the new version.
Effective Date and Created Date Example
When Created Date is enabled in the Rule Application’s Version Settings, a rule or calculation’s version selection depends on two date criteria instead of one. Any Version Settings override tab panel will now allow the override of Created Date in addition to Effective Date, and any versioned rule’s Versions tab panel will offer three columns for each version: Name, Effective Date, Created Date.
A common use of this feature is in insurance underwriting.
In this example, an insurance underwriter decides to offer a policy for a new product (e.g. Flood Insurance) which goes into effect on January 1st 2015.
The formulas used to calculate the premium for this product are created on November 1st 2014. These formulas can now have a version with Name=‘Launch’, Effective Date=1/1/2015, Created Date=11/1/2014.
Customer A from City X decides to buy a Flood Insurance policy from the insurer on November 15th 2014. Since the customer wants to buy the policy that is effective from January 1st 2015 and the policy is being purchased after the ‘Launch’ version’s Created Date, this version is selected.
On November 28th 2014, the underwriter receives updated information on the flooding risks in City X. After this analysis, they decide to change the formulas to increase the Flood Insurance product’s premium for customers living in City X in order to offset this additional risk. A new version is added with Name=’UpdateRisk1’, Effective Date=1/1/2015, Created Date=11/28/2014.
Customer B from City X also decides to by a Flood Insurance policy from the insurer on December 5th 2014. This customer wants the same policy and Effective Date as Customer A, however a higher premium will be levied for Customer B because the policy was purchased after the Created Date of version ‘UpdateRisk1’.
The Created Date feature adds more complexity to the versioning of rules and calculations. The following illustrates the two dimensional nature of the version selection:
In this chart, a calculation whose Effective Date starts 1/1/2006 may select one of three different versions (V4, V5, V6) based on when its formula was created (1/1/2004, 6/1/2004, 6/1/2005). Any Effective Date or Created Date that falls before any of the authored versions will be caught by the Default version.