2

I am a newbie with the rules engine, so bear with me if this question is very basic. All the tutorials for rules engines have been saying that you can move your business logic outside your code and get it updated by BAs/ end users instead of putting it inside Java code.

I have the following questions

  1. But why can't we write our code to read values from property files and do the same thing?

  2. Also, the rules files seem to have a syntax which is not simply one-liners, compared to .properties files.

  3. Does putting these rules in Rule engine make the code/app work without requiring an app server restart?

    3a. If it does NOT, then how can we achieve it?

Patrick Haugh
  • 59,226
  • 13
  • 88
  • 96
Spear A1
  • 525
  • 1
  • 7
  • 20
  • 5
    This is the typical justification. cobol, sql, content mgmt systems, and rules engines were all sold with that same line: "this will let users do this function themselves". it never works out that way. – Nathan Hughes Sep 13 '18 at 15:16
  • My common sense makes me agree with this statement! ;) – Spear A1 Sep 13 '18 at 17:43

5 Answers5

1

Had been doing some reading the last few days and I think (it is IMHO), the capacity for allowing business rules to be updated using simple spreadsheets, gives Rules Engines the edge over property files. I can make property files as highly configurable as possible using multiple properties and instructions for modifying rules as comments under each property.

But in a scenario where the business user is able to directly configure the application to apply values based on a "decision table" in a spreadsheet, then that solution will be more desirable.

If any other (budding) developer looking for justification on the for the need of Rule Engines is convinced with this answer, please leave a thumbs up!

Spear A1
  • 525
  • 1
  • 7
  • 20
1
  1. If there's a change in logic, you'll change the properties file and deploy the whole project again. Whereas, if you maintain it using BRMS, you can change & test individually on the BRMS only without needing to deploy the whole project again. Once the testing is done and you finally want to deploy the new rule in place, then also, no need to deploy the whole project in production. If you've exposed your rule as API using KIE Server, redeploying just the KIE server would do.
  2. One can write decision tables in such a way that all the logic is contained in the top rows. Then the developer can lock & hide those top rows and then give it to BA. Now BA doesn't see any logic but knows how to maintain the file. Also, not all logics should be written as decision tables.
  3. As I mentioned above, one can deploy each and every rule as a separate rest API and hence is deployable independent of the rest.

In the end, I'd say the main reason we use Redhat BRMS is, as they mention in their documentation,:

  1. Agility: No need to involve developers for a change request. BA's themselves can change the logic.
  2. Visibility: What you see (in the excel) is what you get.
  3. Consistency: Rules are evaluated the same way every time.
darkKnight
  • 46
  • 3
  • Thanks for your additional inputs @dark. I highly appreciate them. However, I have certain reservations against a few overly used marketing gimmicks. `code`Agility: No need to involve developers for a change request. BA's themselves can change the logic.`code' These are standard sentences that come with BRMS products, but in no way a property file is less readable than drl file. Personally I feel that the decision tables are great way to give your BAs the freedom. I am yet to see any real project that has rules processed over REST api, but I am also thinking that it is very much possible. – Spear A1 Feb 18 '19 at 18:46
  • 1
    Hi, I know these are standard lines and completely agree with the fact that drls are not that user friendly. That's why people use decision tables. I've used BRMS in 3 projects all of which involve majorly decision tables exposed as rest API. If you want to look for some good project examples, please look at https://github.com/jbossdemocentral/bpms-travel-agency-demo – darkKnight Feb 19 '19 at 05:35
1

Rules engines are just algorithms for organizing many rules. See the Rete Algorithm.

Basically, it all comes down to complexity. If you have a few simple rules, of course you can use a .properties file. But imagine if some of your rules are 'chained' - one rule affects some other property, which triggers some other rule, which changes another property... you'd have to scan every rule, every change. For thousands of rules, it would take forever. Hence a 'rules engine'.

There are many articles on why you should or shouldn't use a rule engine. Here is one good example. https://martinfowler.com/bliki/RulesEngine.html

john k
  • 6,268
  • 4
  • 55
  • 59
0

Rules engines are not always the answer. However, they provide, in theory, the advantage that the engine can perform complex processing on a simple rule expression and return a result. Other advantages are visibility to the rules and less code.

Answers to your questions.

  1. You can. In simple cases,using property files makes sense.

  2. Rules need to sufficiently complex to cover the business issues they validate. A good rules engine uses a syntax that is readable, even if it is complicated.

  3. In theory, the rules server could run independently of the app server. In large companies, that is normal. The rules server could allow updates without a restart, or it could be restarted (rippled, if there are multiple instances,) without affecting the app server.

Steve11235
  • 2,849
  • 1
  • 17
  • 18
  • Thanks for doubling up on the explanations Steve. :) Why do you use "could work without restart" , in the context of rule engines? Do we have a list of Rule engines that don't require a restart? – Spear A1 Sep 13 '18 at 22:04
  • Because I'm making a generalization. I'm certainly not going to enumerate rules engines and how they work. – Steve11235 Sep 14 '18 at 18:56
  • No issues Steve. I could not find many articles that address this. – Spear A1 Sep 14 '18 at 18:57
0
  1. Rules engine comes into picture when business users of company want to set certain rules and drive application based on execution results / outcome decisions of rules set. One of examples of such company could be a Law firm or Insurance company where lawyers set rules to drive the quotes calculation for a insurance & rules are subjected to change over period of time. Property file is developer area where business user may not be proficient to make changes. Having separate rules engine tracks the rules and make a business user and a developer work together automating the business seamlessly which could be difficult with properties file.
  2. Rule files syntax is way to convert business rules (verbal) to coding instructions which are executable. Thats where the syntax comes into picture. That way rules engine provide data abstraction to business entities and their relationships.
  3. Integration with rules engine may be done with some broker or a web service or whatever, based on that, server app need rules client jars to make call against. So its matter of deployment and how server picks up changes / hot deploys if rules client jar is updated.
mjs
  • 139
  • 8