For testing purposes, we need to be able to adjust the current date, essentially so that we can test 3 successive months, in about a 15 day duration.
This is for siebel-web-determinations (10.2) runnning under tomcat
Other than changing the server clock or
replacing all instances in the rules where the currrent date function is used with a placeholder attribute such as the "temp current date",
is there any other way to change the current date for testing purposes?
An alternative would be to use the current date function just once in your rules, for example: the date of assessment = the current date.
Then modify the rest of your rules to use the date of assessment instead of the current date. This will work fine in production.
If you set the value of the date of assessment by seeding the date you want to use from Siebel, then the current date function wont be triggered (you are setting an inferred attribute directly, so the rule proving that attribute will not execute).
thanks Anthony - the challenge is that we have probably used the current date in multiple locations and documents. Is there anyway to detemine where these instances might be, other than manually checking all the word documents?
Using windows explorer search functionality across all the rule documents in the folder tree and searching for each of the possible text references (i.e. "the current date", "CurrentDate", etc.) is probably the most thorough approach.
I also wanted to add a broader rule base design recommendation which reinforces Anthony's suggestion for the "fix" ... The rules in a production rulebase should always leverage an attribute (not a server based function) when rules need to reference a relative date or date/time. Any rulebase which relies on automatic system dates / times should carefully consider the impact of the server running in different timezones (i.e. perhaps relative to the user), implications on testing (i.e. for storing and rerunning test cases that may simulate past or future reference dates) and/or implications of trying to preserve justifications in the form of decisions reports, audit trails, etc. This isn't to say that a well-defined "reference date" can't be set, by default, based on the server's system date, but that ideally, a well-defined static reference date attribute should be referenced by all rules so that the source of the reference date can be changed to more easily achieve other objectives. For example, "the date on which an application is submitted" could be referenced by all rules and could be derived from the local date on the server when the transaction was received, could be derived from the date in the user's local timezone at the time the application was first submitted, could be set to an equivalent global date time (i.e. in a pre-determined global timezone), and/or could be artificially set to future dates for testing.