Unable to run decision table rules for past dates

[Polly D]

Hi there,

While attempting to implement a complex ruleset in drools I have hit a number of issues relating to drools decision table where the requirement is to execute rules in the past. I currently have 3 problem scenarios as outlined below. For scenario 1 and 2 I have not identified any solution and for scenario 3 there is a possible solution using pseudo clock. Any guidance or assistance would be appreciated if you have solutions / suggestions for any of these issues or details of any drools enhancements in the pipeline that may help to resolve these issues

Overall problem code
In the current implementation of drools, when using a decision table with an ‘effective-date’ & ‘expiry-date’, the date used to compare against the decision table rule is defined in the Drools infrastructure and is always set to the current date. Running decision table rules for a past date with an ‘effective-date’ & ‘expiry-date’ does not look to be possible with the current implementation of drools. This also impacts any requirements to running individual rules (not defined in a decision table) in the past with an ‘effective-date’ & ‘expiry-date’ specified.


Drools function - ‘RulesImpl.isEffective’ existing drools implementation showing hard coded current date.

       public boolean isEffective(Tuple tuple, RuleTerminalNode rtn, WorkingMemory workingMemory){
        if (!this.enabled.getValue(tuple, rtn.getEnabledDeclarations(), this, workingMemory)){
            return false;
        }
        if (this.dateEffective == null && this.dateExpires == null){
            return true;
        } else {
            Calendar now = Calendar.getInstance();
            now.setTimeInMillis( workingMemory.getSessionClock().getCurrentTime() );
            if ( this.dateEffective != null && this.dateExpires != null ) {
                return (now.after( this.dateEffective ) && now.before( this.dateExpires ));   // Date always set to todays date
            } else if ( this.dateEffective != null ) {
                return (now.after( this.dateEffective ));
            } else {
                return (now.before( this.dateExpires ));
            }
        }
    }
       
There are 3 scenarios of running rules in the past that I am looking to resolve:


Scenario 1 - Running a rule against the ‘effective-date’ & ‘expiry-date’ for a past date.
I am attempting to use a decision table to hold household size legislation applicable amounts over time. In the current implementation the decision table rule value returned is always for todays date when compared against the ‘effective-date’ & ‘expiry-date’. The requirement here is to be able to provide the date to compare against the decision table ‘effective-date’ & ‘expiry-date’ per individual rule.



Scenario 2 - Running rules against the ‘effective-date’ & expiry-date’ rule over a record period in the past.
In this requirement there is a rule that calculating expenses over a 2-year period but within that 2 year period legislation dates determine when that expense type is counted or not. This information could be stored in a decision table but the value returned is always for todays date. In this case the ‘effective-date’ & expiry-date’ could span all, part or none of that countable period as shown in the following 4 patterns.




Scenario 3 Running all rules against the ‘effective-date’ & ‘expiry-date’ in the past.
The requirement is to run a full set of rules against a past date and against on todays date if the requirement is to validate a set of rules succeeded on a past date that feeds in to the execution of the rules run on todays date. I have a possible solution to this scenario using the pseudo clock but it can only be completed with a statefull session. If this approach is used it was found that a separate path is required in the rules for the second execution for any rule that sets an agenda group focus. Without these separate path rules the agenda groups are not fired and their related rules are not fired. Pseudo clock was not an option for stateless session as there is no access to the session to clear the facts call a second execution on the rules.