This content has been marked as final. Show 5 replies
Current Date is got from the system clock when a session is created. Unfortunately there is no easy way to simulate a different time without changing the system date of the operating system.1 person found this helpful
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.1 person found this helpful
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.
thanks for your comments Matt, this is a good best practice.