Should I be using Business Rules?

[Eumir Martinez Palacios]

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 ]

[Ernest Friedman-Hill]

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.