I am trying to create two independent groups of rules in Drools 6.5 and I can't figure out what's the usecase for the ruleflow-group and agenda-group strategies. They both seem similar.
Reading the documentation ...
2.6.4. RuleFowGroup and AgendaGroups are merged
These two groups have been merged and now RuleFlowGroup's behave the same as AgendaGroups. The get methods have been left, for deprecation reasons, but both return the same underlying data. When jBPM activates a group it now just calls setFocus. RuleFlowGroups and AgendaGroups when used together was a continued source of errors. It also aligns the codebase, towards PHREAK and the multi-core explotation that is planned in the future.
Related
For example, I am load a lot of drools rules to run, how do I know which drools rule now is running? So I can know find out the rule
Assuming you're talking about the right hand side of the rules, you'll want to use an AgendaEventListener. This is an interface which defines a listener that you can create that watches the Event Lifecycle. For more information about the event model, please refer to the Drools documentation.
The easiest way to do this would be to extend either DefaultAgendaEventListener or DebugAgendaEventListener. Both of these classes implement all of the interface methods. The Default listener implements each method as a "no-op", so you can override just the methods you care about. The Debug listener implements each method with a logging statement, logging the toString() of the triggering event to INFO. If you're just learning about the Drools lifecycle, hooking up the various Debug listeners is a great way to watch and learn how rules and events process in rules.
(Also the cool thing about listeners is that they allow you to put breakpoints in the "when" clause that trigger when specific conditions are met -- eg when a rule match is created. In general I find that listeners are a great debugging tool because they allow you to put breakpoints in methods that trigger when different parts of the Drools lifecycle occur.)
Anyway, what you'll want to do is create an event listener and then pay attention to one or more of these specific events:
BeforeMatchFired
AfterMatchFired
MatchCreated
Which events to pay attention to depend on where you think the issue is.
If you think the issue is in the "when" clause (left-hand side, LHS), the MatchCreated event is what is triggered when Drools evaluates the LHS and decides that this rule is valid for firing based on the input data. It is then put on, effectively, a priority queue based on salience. When the rule is the highest priority on the queue, it is picked up for firing -- at this point the BeforeMatchFired event is triggered; note that this is before the "then" clause (right-hand side, RHS) is evaluated. Then Drools will actually do the work on the RHS, and once it finishes, trigger the AfterMatchFired.
Things get a little more complicated when your rules do things like updates/retracts/etc -- you'll start having to consider potential match cancellations when Drools re-evaluates the LHS and decides that a rule is no longer valid to be fired per the facts in working memory. But in general, these are the tools you'll want to start with.
The way I would traditionally identify long-running rules would be to start timing within the BeforeMatchFired and to stop timing in the AfterMatchFired, and then log the resulting rule execution time. Note that you want to be careful here to log the execution of the current rule, tracking it by name; if your rule extends another rule you might find that your execution flow goes BeforeMatchFired(Child) -> BeforeMatchFired(Parent) -> AfterMatchFired(Parent) -> AfterMatchFired(Child), so if you're naively stopping a shared timer you might start having issues. My preferred way of doing this is by tracking timers by rule name in thread local or even a thread-safe map implementation, but you can go whichever route you'd like.
If you're using a very new version of Drools (7.41+), there is a new library called drools-metric which you can use to identify slow rules. I haven't personally used this library yet because the newest versions of Drools have started introducing non-backwards-compatible changes in minor releases, but this is an option as well.
You can read more about drools-metric in the official documentation here (you'll need to scroll down a bit.) There's some tuning you'll need to do because the module only logs instances where the thresholds are exceeded. The docs that I've linked to include the Maven dependency you'll need to import, along with information about configuration, and some examples of the output and how to understand what it's telling you.
I have many rule constraints that can be logically grouped together by "or". For example: 3 rules "r1", "r2" and "r3". I can construct a single LHS as:
(r1 || r2 || r3)
Or I can make each of them a separate rule. I have no critical functional requirement for doing it either way since I can detect their grouping independently outside of Drools.
I wonder if one way is more advantageous than the other from runtime execution perspective (performance, memory, etc.).
A disjunction at pattern level is handled very much like two different rules, so there's not much gained or lost either way.
But from a maintenance and development point of view, two separate rules require two copies of the right hand side, so using a disjunction in a single rule appears to be preferable.
Establishing binding variables used to be a little tricky but I think that recent versions (6.x) of Drools handle that satisfactorily.
Note that disjunctions at constraint level should definitely not be split into separate rules.
How can we generate a decision report in Drools like the OPA Decision Report.
I've tried to check the drools websites and all. But I couldn't find any concrete information regarding this topic.
You'll have to enable all your rules to report that they are fired.
You can do this by adding (e.g.) the output of a log file entry to the rules' right hand side (or even a simple println to some text file).
A more generic way can be achieved by adding an event listener. A "rule fired" event can then access the rule to retrieve a metadata item and write an entry to a log, or file, or store it in a list or whatever. Obviously this is cleaner and safer (you'll detect a missing metadata entry) and more flexible.
My white paper on rules design patterns describes a technique where you write rule to keep track of individual conditions being met by some fact, and at the end of rules firing or not, you can assess what isn't fulfilled. It requires more work than the "all-or-nothing" rule, but it isn't prohibitive (I think).
What is the outcome of several rules having the same salience? Is their order of execution just the order that they're listed in, or is that behaviour undefined - that is, are they checked in arbitrary order? I can't seem to find documentation of how this is handled internally.
The short answer is that you shouldn't rely on the order of rules firing of the same salience - if they are "in conflict" (ie both are eligible to fire). Rules with no salience are just salience of zero, BTW.
Of course it is deterministic - its just that the algorithm is subject to change between versions (not very likely though).
This is under the general area of "conflict resolution" and much has been written about it. I can't find a current article on Drools strategy - but I believe most of it is "recency" - ie the most recently modified/inserted fact "wins" - or rather the rules that refer to the most recent fact will win. If after all that it can't decide - it is usually the order in which they rules are loaded (which usually co-incides with how they are written in the file). If you have to have an order - use salience, or use rule-flow or similar, best not to second guess how it will work.
The Rete algorithm used recency and specificity of conditions.
My experience with Drools 5.1 is that it's last in, first out. That is, the rule defined last in your drl will be executed first.
But yes, relying on such behavior wouldn't be the best idea :)
I would like to design a rules based database engine within Oracle for PeopleSoft Time entry application. How do I do this?
A rules-based system needs several key components:
- A set of rules defined as data
- A set of uniform inputs on which to operate
- A rules executor
- Supervisor hierarchy
Write out a series of use-cases - what might someone be trying to accomplish using the system?
Decide on what things your rules can take as inputs, and what as outputs
Describe the rules from your use-cases as a series of data, and thus determine your rule format. Expand 2 as necessary for this.
Create the basic rule executor, and test that it will take the rule data and process it correctly
Extend the above to deal with multiple rules with different priorities
Learn enough rule engine theory and graph theory to understand common rule-based problems - circularity, conflicting rules etc - and how to use (node) graphs to find cases of them
Write a supervisor hierarchy that is capable of managing the ruleset and taking decisions based on the possible problems above. This part is important, because it is your protection against foolishness on the part of the rule creators causing runtime failure of the entire system.
Profit!
Broadly, rules engines are an exercise in managing complexity. If you don't manage it, you can easily end up with rules that cascade from each other causing circular loops, race-conditions and other issues. It's very easy to construct these accidentally: consider an email program which you have told to move mail from folder A to B if it contains the magic word 'beta', and from B to A if it contains the word 'alpha'. An email with both would be shuttled back and forward until something broke, preventing all other rules from being processed.
I have assumed here that you want to learn about the theory and build the engine yourself. alphazero raises the important suggestion of using an existing rules engine library, which is wise - this is the kind of subject that benefits from academic theory.
I haven't tried this myself, but an obvious approach is to use Java procedures in the Oracle database, and use a Java rules engine library in that code.
Try:
http://www.oracle.com/technology/tech/java/jsp/index.html
http://www.oracle.com/technology/tech/java/java_db/pdf/TWP_AppDev_Java_DB_Reduce_your_Costs_and%20_Extend_your_Database_10gR1_1113.PDF
and
http://www.jboss.org/drools/
or
http://www.jessrules.com/
--
Basically you'll need to capture data events (inserts, updates, deletes), map to them to your rulespace's events, and apply rules.