Contrasting time-qualified rules, DateTime circumstances, and
historical processing
|
|
Process Commander offers three separate features that can cause processing to be dependent on a date or time value. Which of these to apply to best meet an application need depends on the nature of the rules affected and the requirements and environment of the application:
DateTime, and a
constant DateTime value. Such rules support as-of processing, in which
a fact — such as a property value in a work object —
determines a date that determines which rule is applied.Both time-qualified rules and date-circumstance rules depend on a base rule that has the same RuleSet and visible key. When certain conditions are met, the qualified rule is selected for execution; otherwise the base rule applies.
For
a time-qualified rule, the rule resolution process compares the current
system date and time to the Start Date and End
Date values.
For example, assume that the normal service level rule for a retail operation allows four days as the goal time. Management may decide — to accommodate an extraordinary volume crunch in December or January — to create a temporary rule with six days as the goal time. The Start Date of the time-qualified rule can be set to December 1 of a year, and the End Date to January 31. No other changes to the application are necessary; assignments created anytime during those two months have the longer intervals.
You can't have two time-qualified rules (with the same base rule) that have overlapping date time ranges. CLINB 2/22/06
Don't confuse time-qualified rules, which apply
to a single base rule, with the Effective date on the
RuleSet version form, which applies to all the rules in an entire RuleSet
version.
A
date-circumstance rule involves a DateTime property and a
fixed date (or date and time), recorded in a Save As operation. At
runtime, the system compares the value of this property on the clipboard
to the values available in the Date Value field, and
chooses the date circumstance rule (if any) with a Date Value that is
closest, but not later than, the property value.
The current date and time of the server or the user are not relevant.
For example, an annuity is an investment vehicle providing scheduled payments for many years (or in some cases for the life of the investor). A work object supporting annuity processing includes an expiration date (say ExpireDate), such December 31, 2015. If a few processing aspects of the work object depend on this value, they can be derived with a base rule (leaving the Circumstance Date Property value blank), and similar rules where the Date Property is entered as .ExpireDate and the Date Value is entered as 12/31/2005.
The system expects to find the property on the primary page — the page corresponding to the Applies To class of the rule being looked up.
A single rule may contain both a circumstance property and
a date circumstance property. For the circumstance property value, an
exact match is required. For the date circumstance, the Date
Value in the rule must be not later than the clipboard property
date value, and closer than any other qualified rule with the same
Date Property. When all four fields are completed, the
rule is selected only if both test conditions are met. CLINB
2/22/06
Don't confuse date circumstance-qualified
rules, which apply to a single base rule and compare a literal date value
with a property value, with the Effective Date on the
RuleSet version form described below, which applies to all rules in an
entire RuleSet version and uses today's system date for
comparisons.
The historical processing capability applies to an entire RuleSet version, not to a rule. With careful advanced design, this feature allows an application (for the current requestor) to operate according to rules as they were on a specific past date. Such processing is useful to reconstruct past behavior or apply past policies.
Operation depends on the values in the Effective Date field on the Security tab of the RuleSet Version form.
To turn on this feature, a requestor session calls the setRuleSets() PublicAPI function and identifies a cutoff date. Rules in RuleSet versions with an effective date later than that date are thereafter excluded from processing for the duration of the session.
For example, assume that RuleSet version ALPHA:04-15-05 fixes a specific application fault present in version ALPHA:04-15-04 and has October 15, 2004 as the effective date.
A user with access to version 04-15-05 does not experience the fault, before or after that date. But if that user enables historical processing with October 14, 2004 as the cutoff date, all the rules in RuleSet version 04-15-05 are no longer available for the duration of this user session, and the fault may be recreated.
Similarly, consider a sequence of tax rules with corresponding RuleSet versions, each with an effective date. During 2006, taxes can be computed following 2003 rules, by using historical processing. This works only when all the relevant computations are in the RuleSet versions needed.
The current system date and date computations using standard functions aren't affected by historical processing.
Historical processing affects the selection of
rules, but doesn't cause any system date values to be changed. The
history of an object reflects today's date, with no backdating.
|
About
RuleSet Version rules How to enter rule keys using Save As Understanding the Date, Time, and DateTime property types |