there will be some enhancements in the oracle soa suite 11g regarding versioning of rules for oracle business rules. until then we will have to do with versioning of dictionaries and repositories. this topic will address some best practices i have with versioning and oracle business rules 10.1.3.x.

versioning of dictionaries

versioning of dictionaries aims at rules administrators, which can either be a business analyst or a developer. versioning of a dictionary is done by saving a particular dictionary using another version number. sounds trivial, not? think again. the dictionary probably will work in combination with some application calling the rule engine, providing it with a particular version number to work with. so if you want to change something that should be effective immediately, you should save the dictionary using that particular version number. but what if there is a problem and you want to revert to the previous version? or would you not rather want to be able to test your changes first before disrupting production? in other words, you want to be able to use at least two different versions: one to be used for testing and one for real.

what i always have is two dictionaries, one version for example with number 2.1.0 for production and another one with number 2.1.x for testing purposes. the test version i can always recognize by the 'x' at the end. which version the application is supposed to work with, is read from a properties file that i can change on the fly. what i also could do, is create some preference screen through which the rules administrator can select the version to be used during a particular session, the one from the properties file being the default.

as property files can be written, that screen could easily be enhanced to allow changing the default. in this way the rules administrator will have a way to change existing rules or add new ones and test them first, before bringing them into production. the latter can be done by either overwriting the 2.1.0 dictionary with the 2.1.x version, or by saving the 2.1.x dictionary as 2.1.2 and set that as default. the rules administrator will also have the option to activate particular rules for a specific period of time, by putting them in a specific version, and set that as default only during that period.

versioning of repositories

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. of course, fact definitions are dictionary specific, so why not version dictionaries instead? of course you also use a particular dictionary to make the changes, but obviously you want to make sure you keep a clear track of what version of a repository works with what version of the application. and of course you are using some proper source control system like subversion to manage you configurations, right? right! and as that system probably is file based, you want the dictionary to be in a file you can put under version control, obviously.

so what i do is that with every change (or set of changes) i make and that have been properly tested, i make an export of the rules repository and commit that to the repository of the version control system together with the corresponding sources (xsd's or java classes).

and business rules as usual.

a question on otn was of how to implement the af:poll component so that it frequently checks and updates a table binding. in this blog entry i share a working solution with you that not only polls for new data but also ensures that the currently selected row remains selected after the poll - and [...]