Contrasting time-qualified rules, DateTime circumstances, and historical processing

PRPC 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:

• Time-qualified rules, also known as temporary rules, can be created during the Save As operation. They contain an absolute date and time in the Start Date field, End Date field, or both fields.
• Date-circumstance rules, also created by the Save As operation, identify a property of type DateTime, and a constant DateTime value. Such rules support as-of processing, in which a fact — such as a property value in a work item — determines a date that determines which rule is applied.
• Historical processing applies to all the rules in a specific RuleSet version for a requestor, and depends on the Effective Date field on the RuleSet Version form. Through careful planning and design of an application, historical processing can allow current work to advance in accord with the past state of an entire application.

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.

More about time-qualified rules

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.

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.

More about Date Circumstances (As-of processing)

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 item supporting annuity processing includes an expiration date (say ExpireDate), such December 31, 2015. If a few processing aspects of the work item 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.

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.

More about historical processing

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 Versions How to enter rule keys using Save As Understanding the Date, Time, and DateTime property types

Concepts