In this case, the rule outcomes will change, so you need to redo the
reasoning, because there is certain information that couldn't be passed
after the first rule execution.
This implies that you have to keep your rules somewhere and you would need
rule governance to manage versioning problems. You could f.e. make the admin
create a new version of the xls, but based on a previous version. Be very
careful here that he cannot overwrite the previous files.
Alternatively, you could actually save each version of the knowledgebase in
a database, with some time attributes attached. At runtime, you create a
session based on the knowledgebase that has a creation date closest before
the date of the request. This requires a lot of governance as well, as you
have to decide when to save a new kbase, which bases will never be used
again etc.
I would try to avoid the last alternative, but it is the only thing that I
can think of to achieve your requirement.
Regards,
Frank
Riyaz Saiyed wrote:
The idea is to store these price rules as xls decision table.
The admin (non technical guy) will periodically update the xls just to
change the price.
For example for the same date range - 1-Jan-2011 to 31-Mar-2011, price can
be increased of decrease depending on the volume of requests. So creating
multiple version (more entries in xls) may be time consuming for him. He
will prefer to do "find and replace" to update the price.
--
View this message in context:
http://drools.46999.n3.nabble.com/Drools-Decision-Table-tp2830218p2833742...
Sent from the Drools: User forum mailing list archive at
Nabble.com.