Comments for ILOG BRMS Blogs http://blogs.ilog.com/brms Commentary and news on business rule management systems and rules engines Mon, 13 Oct 2008 20:35:01 +0000 http://wordpress.org/?v=2.3.2 Comment on JRules in the Real-World by Daniel Selman http://blogs.ilog.com/brms/2008/09/12/jrules-in-the-real-world/#comment-1234 Daniel Selman Tue, 30 Sep 2008 11:45:28 +0000 http://blogs.ilog.com/brms/2008/09/12/jrules-in-the-real-world/#comment-1234 Fred, Yes, thanks to some of your large decision tables, we found a performance bug using the "otherwise" clause on big decision tables. We'll get a fix for that one into a future version. I am also working on the other performance bug we saw on site -- under some circumstances artifacts get built several times by the RS4J build. This one would have been almost impossible to nail down had we not been on site, as it required using your rules, which are obviously confidential. By debugging on one of your machines, using your rules, I was able to isolate the problem. I am currently developing and testing some new RS4J build code. I hope it will be both faster and more robust when building projects with inter-dependencies. Thanks again for a very productive visit and best wishes to all the team. Dan Fred,

Yes, thanks to some of your large decision tables, we found a performance bug using the “otherwise” clause on big decision tables. We’ll get a fix for that one into a future version.

I am also working on the other performance bug we saw on site — under some circumstances artifacts get built several times by the RS4J build. This one would have been almost impossible to nail down had we not been on site, as it required using your rules, which are obviously confidential. By debugging on one of your machines, using your rules, I was able to isolate the problem. I am currently developing and testing some new RS4J build code. I hope it will be both faster and more robust when building projects with inter-dependencies.

Thanks again for a very productive visit and best wishes to all the team.

Dan

]]> Comment on Document-centric Rule Management by Chris Berg http://blogs.ilog.com/brms/2008/09/23/document-centric-rule-management/#comment-1233 Chris Berg Mon, 29 Sep 2008 17:57:35 +0000 http://blogs.ilog.com/brms/2008/09/23/document-centric-rule-management/#comment-1233 Here is a link to the webinar: http://www.businessrulesforum.com/webinars_active_viewing.php?view=378 Here is a link to the webinar:

http://www.businessrulesforum.com/webinars_active_viewing.php?view=378

]]> Comment on JRules in the Real-World by Fred http://blogs.ilog.com/brms/2008/09/12/jrules-in-the-real-world/#comment-1232 Fred Thu, 25 Sep 2008 19:27:26 +0000 http://blogs.ilog.com/brms/2008/09/12/jrules-in-the-real-world/#comment-1232 Dan, You may want to mention the biggest "no no" of all where a 4,000 cell DT had an row at the bottom which in short crippled RTS from compiling the ruleset. We found that the statement generated a negative version of every row in the table which resulted in a 45,000+ character string. While trying to process this string, WAS 6.1/JDK 1.5 consistently took OOM errors. Thanks for the visit...it was a great learning experience. Fred. Dan,

You may want to mention the biggest “no no” of all where a 4,000 cell DT had an row at the bottom which in short crippled RTS from compiling the ruleset. We found that the statement generated a negative version of every row in the table which resulted in a 45,000+ character string. While trying to process this string, WAS 6.1/JDK 1.5 consistently took OOM errors.

Thanks for the visit…it was a great learning experience.
Fred.

]]> Comment on JRules in the Real-World by Daniel Selman http://blogs.ilog.com/brms/2008/09/12/jrules-in-the-real-world/#comment-1230 Daniel Selman Mon, 15 Sep 2008 21:29:33 +0000 http://blogs.ilog.com/brms/2008/09/12/jrules-in-the-real-world/#comment-1230 Paul, I'm pretty sure that in this case the customer had 40K rule artifacts, not 40K executable rules. As you say, if you include the executable rules generated by DT rows the runtime figure is much higher. When we provide DT and general sizing guidance to customers we usually talk in terms of DT cells, as the *design-time* performance they see correlates very roughly with the number of cells. At runtime of course it's a different story, as the engine does its magic! :-) Take care mate, Dan Paul,

I’m pretty sure that in this case the customer had 40K rule artifacts, not 40K executable rules. As you say, if you include the executable rules generated by DT rows the runtime figure is much higher.

When we provide DT and general sizing guidance to customers we usually talk in terms of DT cells, as the *design-time* performance they see correlates very roughly with the number of cells. At runtime of course it’s a different story, as the engine does its magic! :-)

Take care mate,
Dan

]]> Comment on JRules in the Real-World by Paul Vincent http://blogs.ilog.com/brms/2008/09/12/jrules-in-the-real-world/#comment-1229 Paul Vincent Mon, 15 Sep 2008 13:05:11 +0000 http://blogs.ilog.com/brms/2008/09/12/jrules-in-the-real-world/#comment-1229 Daniel - great post. I think all the major BRE vendors involved in insurance see these large decision tables (and 40K rules = 40 columns x 1000 rows). I wonder if a better metric might be number of decisions (where each decision table or set of related decision tables supports a single decision)? And perhaps we need some other metric for the #rows and #columns (i.e. "dimension" of such tables - e.g. #rows x #columns x %cell-population). Just a thought, as "40K rules" could be construed as 40K "independent inferences", whereas clearly in a DTable the rules are following a common pattern within a tabular template. Cheers Daniel - great post. I think all the major BRE vendors involved in insurance see these large decision tables (and 40K rules = 40 columns x 1000 rows). I wonder if a better metric might be number of decisions (where each decision table or set of related decision tables supports a single decision)? And perhaps we need some other metric for the #rows and #columns (i.e. “dimension” of such tables - e.g. #rows x #columns x %cell-population). Just a thought, as “40K rules” could be construed as 40K “independent inferences”, whereas clearly in a DTable the rules are following a common pattern within a tabular template.
Cheers

]]> Comment on JRules in the Real-World by Daniel Selman http://blogs.ilog.com/brms/2008/09/12/jrules-in-the-real-world/#comment-1227 Daniel Selman Fri, 12 Sep 2008 20:51:32 +0000 http://blogs.ilog.com/brms/2008/09/12/jrules-in-the-real-world/#comment-1227 The SCCS they were using was MKS. It looked decent but I've never got hands-on with it on a project. The SCCS they were using was MKS. It looked decent but I’ve never got hands-on with it on a project.

]]> Comment on JRules in the Real-World by Peter Lin http://blogs.ilog.com/brms/2008/09/12/jrules-in-the-real-world/#comment-1226 Peter Lin Fri, 12 Sep 2008 12:49:36 +0000 http://blogs.ilog.com/brms/2008/09/12/jrules-in-the-real-world/#comment-1226 I hope that customer doesn't use IBM Clearcase with multiple streams. That would result in merge nightmares from Dante's inferno. Thanks for sharing the info. Last year I worked at a large US insurance company. Within just 1 project, there was over 50K rules and that was considered minimal. Other divisions had even bigger rulesets by 3-4x. I hope that customer doesn’t use IBM Clearcase with multiple streams. That would result in merge nightmares from Dante’s inferno. Thanks for sharing the info. Last year I worked at a large US insurance company. Within just 1 project, there was over 50K rules and that was considered minimal. Other divisions had even bigger rulesets by 3-4x.

]]> Comment on This is a Lesson Not a Rule… by Daniel Selman http://blogs.ilog.com/brms/2008/09/08/this-is-a-lesson-not-a-rule/#comment-1225 Daniel Selman Thu, 11 Sep 2008 20:26:05 +0000 http://blogs.ilog.com/brms/2008/09/08/this-is-a-lesson-not-a-rule/#comment-1225 ...or is it a list of things that people shouldn't implement with business rules? What do you guys think? …or is it a list of things that people shouldn’t implement with business rules? What do you guys think?

]]> Comment on This is a Lesson Not a Rule… by Chris Berg http://blogs.ilog.com/brms/2008/09/08/this-is-a-lesson-not-a-rule/#comment-1224 Chris Berg Mon, 08 Sep 2008 22:38:38 +0000 http://blogs.ilog.com/brms/2008/09/08/this-is-a-lesson-not-a-rule/#comment-1224 I believe Dan is commenting on places where rules might be waiting to be liberated.... CCB =) I believe Dan is commenting on places where rules might be waiting to be liberated….

CCB =)

]]> Comment on IDEs and Code Branches: A Cry for Help! by Daniel Selman http://blogs.ilog.com/brms/2008/08/01/ides-and-code-branches-a-cry-for-help/#comment-1223 Daniel Selman Mon, 08 Sep 2008 12:56:12 +0000 http://blogs.ilog.com/brms/2008/08/01/ides-and-code-branches-a-cry-for-help/#comment-1223 James, Thanks for the reply. I've used Mylyn a fair bit and I DO find it useful -- particularly as I spend quite a bit of time sitting on trains/planes with little or no access to our Jira server. Having a local copy of the Jira issues I am working on in the workspace is very handy as are the context switching capabilities. However I have not seen much support for handling multiple code branches. Do you have any pointers to the "higher-order" tools you mention? Thanks, Dan James,

Thanks for the reply. I’ve used Mylyn a fair bit and I DO find it useful — particularly as I spend quite a bit of time sitting on trains/planes with little or no access to our Jira server. Having a local copy of the Jira issues I am working on in the workspace is very handy as are the context switching capabilities. However I have not seen much support for handling multiple code branches.

Do you have any pointers to the “higher-order” tools you mention?

Thanks,
Dan

]]>