• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

Should I be using Business Rules?

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Greetings!

Recently, my boss asked me to check the possibility to port one of our systems to be supported by a business rules manager (ILOG JRules, Blaze Advisor, e.g.).

The system basically has to classify different types of checks depending on their origin and destination and assigns them an identifying key (for example:

If the check is from Chicago and
the check is directed to "Mary Jane"
then set the check's key to 245

Currently, this is implemented with just a table containing Place, Recipient, and Keys, so a sample row would be something like (Chicago, Mary Jane, 245). I'm not particularly sure why this is not a good approach. I mean, if the mappings are going to grow, you can always just add new rows. Plus, the mappings are really straightforward, so I don't see what benefits we could achieve by switching it into rules. They're actually around 1500 of rows, so having 1500 of those rules seems a bit far fetched to me.

Am I missing something?

Thank you very much Happy coding.

Eumir Mtz
[ June 26, 2006: Message edited by: Eumir Martinez Palacios ]
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Welcome to JavaRanch!

For just the scenario below as you describe it, the table works fine and a rule engine would be overkill.

But you might imagine a scenario where you start to get new rules that add new "columns" to the table; adding a column can be very expensive since someone has to decide what to enter for each row. And you also might imagine a situation where the "if" parts depend on dynamic things like whether Mary Jane is on vacation, or if the payer has bad credit, or complex logical things like doing something on weekdays and something else on weekends, but only for some payers... Then it becomes very hard, if not impossible, to use a single table, and you have to use multiple tables and relational joins, plus some procedures to update those tables based on the HR database and other information. It's at this point that a rule engine will simplify matters.
 
Those who dance are thought mad by those who hear not the music. This tiny ad plays the bagpipes:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic