First look at JRules 7.0 – Migration of a project

This entry is part 2 of 5 in the series First Looks at JRules 7

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 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.

First look at JRules 7

This entry is part 1 of 5 in the series First Looks at JRules 7

Well it’s been a while since I posted but I can blame being busy in the non-blogging side of life, time off, and preparing for the conferences in the fall. I’m not done with that last point, but I think it was time for me to have a look at JRules 7 which came out a couple of weeks ago.

This will be the first post in a series that covers my experience with trying out JRules 7. The topics will include simple differences, Migration process, Decision Validation Service and Rule Solutions for Office.

My first impressions: I like it.

The transition to the IBM world is almost seemless. Some of the new components have interesting capabilities, overall a good upgrade.

Differences when compared to previous version

The install of different components is separate as opposed to the single install previous versions had.

  • Rule Studio and Execution Server
  • Decision Validation Service (DVS) (replaces Rule Scenario manager or RSM)
  • Rule Team Server (RTS)
  • Rule Solutions for Office

The default web server that comes with the install is now Apache-Tomcat (so long JBoss!). I had my reservations initially, but everything is working just fine so far. Actually, I don’t exactly know what IBM/ILOG changed, but the starup time of the web server is a LOT faster in Tomcat than it was in JBoss. In my case the load time of the web server went from 1m48s to 21s, that’s basically 5 times faster.

The JVM that comes with the install is probably the “IBM Development Package for Eclipse”. I say probably because the IBM J2SE envrionment is not available for Windows. (J2RE 1.6.0) So it looks liek they did away with the usual Sun JVM. I suppose that is normal since it is now an IBM product.

Rule Studio leverages Eclipse 3.3.1, and now comes with an xml editor that allows easy edition of xml, xsd files. In previous versions, you had to rely on a third party plugin for Eclipse.


The install process is pretty straight forward. I personnaly had some issues when launching the ruleflow editor, but it turned out that the cause wasn’t Rule Studio at all, I needed to upgrade my graphics card drivers. No it wasn’t straight forward to figure that one out. Yes I am glad it is over… 🙂

So far, so good. In my next post, I will discuss my experience migrating a project from JRules 6.7.2 to JRules 7.0.