Re: [rules-users] Question about timing rules

I've already followed something similar to Corneil's suggestion just by poking around on my own. What I've found is that the timers have to be set up to be checked first, then that caused focus to change to evaluate rules affected by those timers going off. That's at least one way of doing it. I was wondering if others had used different methods. In our old rule engine software, optional keywords could be used to set up what was essentially an interval timer under the hood on a per rule basis. Like this: RULE: "example rule" TIME_INTERVAL: 60; // (seconds) WHEN .... THEN .... So rule activation based on the WHEN criteria only happened at a consistent interval of 60 seconds. It was convenient, very easy to work with, and didn't require creating additional objects that had to referenced in the LHSs of rule writing. So with Drools we're experimenting with analagous ways of achieving the same thing. Allen -----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Scott Reed Sent: Thursday, June 05, 2008 10:35 AM To: Rules Users List Subject: Re: [rules-users] Question about timing rules To parameterize each rule's frequency, you can add an object with a frequency property for each rule or group of rules with the same frequency and check the frequency in the LHS against Corniels proposed timer object. You can then modify the frequency property of these objects and signal the rule engine that the change was made and the new frequency will be be used to trigger the rules. I am not sure you need to fireAllRules periodically. I think you can just update the timer object that Corneil proposes and signal the update to the rule engine and it will reevaluate the rules automatically. Corneil du Plessis wrote: > It should not be an issue to have an object inserted representing the > current time and have rules checking against the object > > ---------------------------------------------------------------------- > -- > *From:* rules-users-bounces(a)lists.jboss.org > [mailto:rules-users-bounces@lists.jboss.org] *On Behalf Of *Bagwell, > Allen F > *Sent:* 05 June 2008 17:34 > *To:* Rules Users List > *Subject:* [rules-users] Question about timing rules > > > Another noob question: > > Is there a generally understood way of implementing the concept of a > time interval rule? > > That is, lets say I have a Drools-enabled client which is constantly > receiving information from outside resources. Most of this data (and > the consequences of its changes) is time sensitive, so I'm calling the > fireAllRules() method in a loop every minute. > > And now, let's say I have a rule that in addition to being driven by > incoming data changes has to be linked to a repeating clock interval > or synched with wall time such that the rule only activates and fires > if the data meets certain parameters AND it's been exactly 1 hour > since the last check or that it will fire at the top of every wall > time hour (1 PM, 2PM, 3 PM, etc.). > > Furthermore, timing may change. A successful rule activation and > firing might do something like "now change this timing so that for the > next 24 hours, this rule must be examined every 30 minutes instead of > every hour". > > My initial reading of the Drools documetation I came across the > Duration, and Date-* keywords. Their descriptions didn't seem to fit > the bill. > > I ask this because our old rules engine software that has been retired > to obsolescence allowed this kind of thing to be easily set up. Coming > at it in the Drools world seems a lot more challenging. > > Thoughts? Examples? > > -Allen > > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users