Tips & Tricks: Rule Versioning

MG

Mike Grucella

02/02/2015

A Business Rule Management System is great for the sheer fact that you can quickly make changes to your application logic without having to involve programmers. Want to change that condition statement from “greater than” to “greater than or equal to”? No problem. Most changes are quick and easy and can be turned around in very little time.

But what if you have an existing business rule in place that you know will need to change on a specific date? You can’t make that change now because the current rule is working the way it’s supposed to work. And you really don’t want to wait until the eleventh hour to modify it. Last minute changes rarely go according to plan regardless of how many times you hear “it’s just a simple change.” This is where rule versioning can save the day.

In irAuthor, you can select any rule and create a new version of it now so that it’s tested, verified and ready to be executed on that future date. In the example below, we have our Default rule that is setting the Mortgage Rate to 4.9% if the condition is met.

Now let’s say that on April 1, 2015 the rate needs to increase to 5.15%. Again, rather than waiting until the last minute to cram in the change, create a new version of the existing rule. In the screenshot below we’ve called it RateForQ2. The Effective Date is the “go live” date for that version of the rule. The Implementation Date, which we are not using in this example, can be used to support more elaborate rule versioning scenarios where you want to phase rule versions in and out. For either the Effective Date or Implementation Date, you can type in a specific value, as I’ve done in this example, or you can point to a date field that is part of the data getting passed in at execution time.

Once you’ve created the new version, you can then test it in irVerify. Set an effective date to simulate processing on 4/1/2015 to make sure (a) the rule engine executes the new version of the rule and (b) you get the expected result. Once you’ve done your testing, you can then check in the rule. At that point, it’s just sitting there in the rule application, alongside the Default rule, just waiting to be executed on that effective date. When April 1 rolls around, the rule engine will say “Oh, I see you’ve got a new version that’s going live today. I’ll start using that one.”

InRule for JavaScript | inrule said: "[…] couple of weeks ago we announced availability of InRule® for JavaScript through an early adopter program. To our knowledge this is […]".
Dynamic Surveys in Dynamics CRM Part II: Managing Dependencies | inrule said: "[…] this post makes extensive references to my preceding post, Surveys in Dynamics CRM Part I: Don’t Be a Monkey With Your Survey. If you are the type of person who likes to get the full story, you should go back and read the […]".
Josh Elster said: "In the time since this post was published, I've added (via a PR) full Windows Containers example code, DOCKERFILEs and scripts. They share common ancestry with the GH Gists I posted earlier, but are more up-to-date and tested. Here's a direct link to that sub-folder: https://github.com/InRule/Samples/tree/master/Developer%20Samples/WindowsContainers Now that our Samples repository is public, feel free to file Issues if you have problems or features you'd like to see implemented. If you have something you'd like to contribute, then by all means do so! The contributor guidelines and process are listed in the root of the repository. Enjoy! I'll update the body of the post as well with this link.".