OpenRules, Inc. offers methodology, proven open source tools and services that enable business analysts to work in concert with software developers to create and maintain Rules-based applications with complex business and presentation logic.

Versioning of dictionaries aims at rules administrators, which can either be a business analyst or a developer.
Versioning of repositories aims at developers. The prime reason you might want to version repositories, is that during maintenance of the application the fact definitions may change.

This column is the first in a series that will provide the reader with best practices on using or choosing a rules engine. The following topics will be discussed in future columns:

* magic values
* rule templates
* rule on/off
* exception handling
* what to do procedural, when to do rules
* local variables in rules
* arrays and chaining
* forward chaining over multiple instances
* backward or forward chaining?

Today we continue our discussion on how to deal with rule versioning and rule history in a declarative way. In our first column[1] on this topic we described the characteristics of the rule history and versioning problem, and we discussed an example and a simple solution. In our second column[2] on this topic we discussed an efficient and declarative solution that can be used when rules are versioned on a small number of dates (for example every year on the first of January).

A Business Rule Engine is one part of a complete system for handling all the things involved in working with rules. Admittedly, it’s an important part, but it deals only with execution… which rules need to be executed in what order? The big enterprise-oriented players are concerned with a lot more… There’s all the development and testing; linking up to data sources and other applications; measuring and reporting; deployment to different computing environments; making rule maintenance easy; looking for conflicts; and so on.