[rules-users] Options for rule versioning

[Ansgar Konermann]

Hi Rob,

another approach we're considering to version rulesets used to perform
mortgage risk assessment looks roughly as follows:

- each of the rulesets is versioned as a whole (i. e. compile all *.drl
pertaining to a ruleset into a *.pkg file and give this *.pkg a version
number).
- the scoring service is aware that rules evolve and selects the ruleset
which fits the "processing date". the processing date is part of the
scoring request we send to the service
- scoring service loads selected ruleset and performs risk assessment,
sending back risk indicators

We don't like the idea of time-dependent rules very much, as this
introduces *versioning* into the rule source code itself, which is
additional complexity we'd like to keep out of the *.drl files. We want
to be able to drop old rules from the source code once they are not
valid any more, but still have them compiled with a version number
somewhere in a repository, just in case a mortgage application needs
re-scoring based on an older version of the rules. We can afford this
rather "static" approach as our rules don't change too often (like a few
rules every week or two).

Best regards

Ansgar


Am 24.08.2011 21:42, schrieb Rob Fisher:
> Looking for best practice recommendations around the versioning of a
> rule.  Our application will have 50-60 rule sets comprised of up to 70
> rules each.  The activation of many of the rules will be based on a
> processing date (inserted fact attribute).  The application processing
> date can be prior, equal, or after the system date.
>  
>  
> For example, 2 rules, with slightly different logic
>  
> Eligibility rule version 1
> //to be potentially activated  for application processing time period
> prior to 2011
> When
>      Car(color = "blue")
> Then
> Terms(eligible = "yes")
>  
> Eligibility rule version 2
> //to be potentially activated for application processing time period
> 2011 and forward
> When
>    Car(color = "blue", type="coupe")
> Then
>   Terms(eligible = "yes")
>  
> We've come up with a couple of different ways to handle this:
>
>    1. Add Date logic to LHS of the rule . i.e add
>       "Control(processingDate < '01/01/2011')" to 1st rule and 
>       "Control(processingDate >= '01/01/2011')" to 2^nd rule. First
>       rule would activate with processing date = 12/31/2010 and 2^nd
>       rule would activate with processing date = 07/31/2011.  When
>       originally authored, first rule would be written without date
>       logic.  When 2^nd rule is authored, data logic will need to get
>       added to both.
>    2. We explored a way of setting the session clock to the processing
>       date and using the 'date-effective' and 'date-expires'
>       attributes to do the filtering.  i.e. 1^st rule is effective
>       until 12/31/2010 and 2^nd rule is effective from 01/01/2011 to
>       12/31/9999.  However, we could only figure out how to do this
>       with a stateful knowledge session.  Is it possible in a Stateless?
>    3. We added metadata to the rules (@EffectiveDate and
>       @ExpirationDate), and using agendafilter, we compared processing
>       date to the metadata and return true or false dependent on
>       comparison.
>
>  
> What are your opinions on these three methods?  What are other options?
>  
> Thanks
> Rob
>  
>  
>  
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110824/1c4352b9/attachment.html