I just got back from an on-site visit with one of our customers in the USA, a major insurance company. The customer is using JRules 6.6.x for commercial property insurance underwriting. The trip was very interesting as we were able to get hands-on with their large rule project for 3 days -- approximately 40,000 rules. We gained some fascinating insights into their development challenges and in exchange we performed an audit to ensure they were getting the most out of JRules. I came back with a couple of bugs to fix and a headful of ideas for enhancements.
One of their major challenges is that they simultaneously work on 3 versions of their platform -- a 3 month major release (2.0 say), a 1 month minor release (1.1) and a weekly "patch" release (1.0.5). The patch release is edited in Rule Team Server by business users while the other two releases are edited in Rule Studio by Java developers with JRules training. Due to this rolling release schedule they version the rules in a source code control system (using branches) and have to perform regular merges of the changes coming from RTS into RS.
The RTS repository does not support branches. This was a conscious limitation when we designed RTS as we believed that branching and merging would be problematic for a business user. The development process we therefore recommended is to treat RTS as a satellite user of the source code control system.
- For each branch in the source code control system an RTS instance is created, which could be just a table space in a database rather than a new application server install.
- The business users collaboratively edit the rules within RTS. When they are ready they request that the changes be moved into the system of record -- the source code control system (SCCS).
- A RS user updates their workspace from SCCS and then synchronizes with the appropriate RTS instance. The RS user resolves any conflicting changes and commits everything to SCC.
- The RS user then uses the SCCS merge tools to merge the contents of the code branch with the next branch. For example versions 1.0.5 might be merged into the branch for versions 1.1.
- At a later checkpoint the 1.1 branch will be merged with the branch for version 2.0
As you can see one of the RS users essentially "proxies" the changes coming from RTS into her local workspace.
Due to the textual nature of BAL rules (if-then-else) merging them is relatively straightforward. Decision Tables and Trees are more problematic as they are persisted as complex XML documents. We spent some time discussing the APIs that we provide that might enable a graphical merge capability for Decision Tables.
We also spent quite a bit of time optimizing the RS build time for these large projects. Here is a checklist:
- Check RS JVM heap size. For large projects allocate as much heap as you can, typically around 1.2 GB on 32-bit Windows.
- Use the latest patch level of the JVM and JRules. Both are constantly evolving and usually getting faster!
- Switch off as many semantic checks as you can to save time during the build. The settings can be found on the Build preferences page. The checks are useful of course but some may be time-consuming, particularly static rule analysis.
- If you are using Decision Tables switch off the semantic checks for each table. For large decision tables this can result in significant time savings during builds. You may want to leave the checks enabled while you edit the table and switch them off just before committing your changes.
- Keep your vocabulary "lean and mean", as a bloated vocabulary makes the rules slower to parse. Only verbalize BOM elements that you plan on using in your rules.
I hope these tips will help as your projects get larger. Rest assured that we take real-world feedback sessions such as this one very seriously and we are constantly trying to stay one step ahead in the race for better performance.