- First look at JRules 7
- First look at JRules 7.0 – Migration of a project
- First look at JRules 7.0 – Decision Validation Service
- First looks at JRules 7.0 – Rule Solutions for Office
- First look at JRules Scorecard Modeler
I tried a couple of project migrations. Once smaller and simpler, and one that was much larger, and had already gone through 2 prior upgrades of JRules.
To start off, the documentation to prepare and guides users through a migrations is decent. IBM/ILOG provides different typical scenarios of migration which depend on you use of previous versions of JRules and the tools it provided. For the migrations I tried, I was in the simpler migration situation, which is users that use Rule Studio and a source code control to manage the code and rules and who possibly publish to a Rule Execution Server.
The other scenarios, which require updating Rule Team Server, and Rule Scenario Manager are obviously more complicated and people having to go through these migrations may have more work to do than I did.
The migration process itself is a silent migration. There are no messages that come up to tell you the progress or anything to that effect. There is one manual process they encourage you to go through to make sure the migration is completed and that is to open decision tables one by one, introduce a fake change and then save to be converted to the new format. In previous versions of JRules it was possible to do a search of all decision tables using a wildcard, but not in this version for some reason. Luckily, you can work around that by doing a file search of all files ending in “DTA” which is the extension used for decision tables. That way you can double click the results, make the “fake change” and save the file to transform to the new format.
Migration of the simple project
Simple XOM, Simple BOM, Simple Rules results in a simple Migration.
After importing each project in Rule Studio, I was left with only a single warning. There was an empty Rule Task in a Ruleflow. It turns out that although you could use empty rule tasks or empty function tasks to rejoin some of the flows in your ruleflow, that using empty rule tasks now gives a warning. That is an easy fix by simply replacing the empty rule task with and empty function task.
The other piece of the “migration” was that I had to go through was to re-generate the “Client Project for RuleApp” Web Service and to re-modify the code based on the code form 6.7.2. I chose to re-generate and re-modify the code for a couple of reasons:
- I wanted the latest and greatest code generation (turns out not much is really different
- I wanted to get the build.xml files for deployment onto the Tomcat platform as opposed to the JBoss platform
Some of the code I was using in the ExecutionHook.java class I had to re-write based on the refactoring of the API that was performed in JRules 7.0. Nothing major, but it needed rewriting.
That was it! Well not quite. Now on to the complex project migration.
Migration of the complex project
For the complex project, the migration started fairly straight forward. I encountered some warnings in the rules project after the import completed.
It turns out that the Ruleflow editor is more strict than previous ruleflow editors and therefore gives warnings that were not present in the 6.7 version of the editor. In my case it had to do with some empty rule tasks. I mentionned this issue above, but this was different.
The empty rule tasks were actually not visible in the editor itself. It seems that in the years of editiong the ruleflows, possibly copy and pastes, and migrations, some “ghost” rule tasks were left around in the ruleflow, but were not visible in the editor. The only way to remove them was to go into the XML and remove the XML for that task. As a note, I don’t think this situation would be encountered normally, but the history of the project I experimented with had some of these behaviours.
Note: Before doing that, always make sure you have backup up that file because if you screw up your edition you may be losing your ruleflow altogether.
Besides these “ghost” tasks that you need to edit manually out of the Rulflow XML, the migration process is pretty easy and straight forward.
Side notes: The ruleflow editor
I find that the ruleflow editor interface has been improved quite a bit. It is nicer looking than it used to be and the editors for initial action, final action and properties on rule tasks are much better to work with since they are not as limited in size as they were before. The ruleflow itself loses the initial action and final action, but these are moved to the more logical start task and end task properties respectively. Overall a much better interface than in previous versions.
In my next post I will discuss the Decision Validation Service.