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.html Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users