Update periods

Updating periods is the process of increasing the amount and the frequency of a period bucket.

For the sake of completeness, this also includes updating the value of the standard deviation, when activated. The period to be updated is determined by a transaction timestamp. The Timestamp setting in the calendar configuration determines which transaction timestamp is considered. For more information, see Timestamps in Calendar configuration.

It is possible to either include the currently processed transaction for the calculation of the output attributes or to ignore the current transaction, which will update the periods at the end of the transaction processing. If Include current is selected, the periods are updated with the values of the current transaction. If this setting is deactivated, the periods are updated at the end of the transaction processing process. This fact can be leveraged for the following scenario:

Create a rule R2 that fires when another rule R1 fired within the last 10 days.

To solve the problem with a counter:

  1. R1 sets an MDC-stored boolean attribute B1 to true in its conclusion
  2. Create a counter CTR1 that counts transactions with B1 is true in its evaluation conditions (frequency)
  3. In R2 use CTR1 in a condition: CTR1 is greater than 0

The problem can also be solved with a calendar. This can be useful when the sequence of an index node is extremely deep, and the counter becomes a performance bottleneck. The calendar approach in similar scenarios can generally be considered as superior in terms of speed.

  1. R1 sets a Boolean attribute B2 to true in its conclusion. B2 does not have to be stored, because the fact that B2 was set to true will be captured by the calendar

  2. Create a daily calendar CAL1 with 10 periods. Make sure Include current is cleared. Create an output attribute in the calendar and set the Past calendar periods to 10. The computation has to be set to frequency. Our goal is to count the frequency of transactions where R1 fired. R1 fired when B2 is true. Therefore, the computation condition of the calendar should test if B2 is true, before increasing the frequency. The computation conditions will be evaluated after the rules have been processed. That means that if R1 fired, the calendar will update the current period with this information.

    The following screen capture shows the configuration:

    Calendar definition where Index is account, Timestamp is reference timestamp, Calendar period is daily, and number of periods is 10. Computatoin condition is B2.
  3. Create a rule R2 that checks for Number of R1 fired is greater than 0 in its condition.

Let us simulate this scenario:

  1. Transaction T1 arrives and fulfills all conditions of R1 => R1 fires
  2. R1 sets B2 to true in its conclusion
  3. At the end of the computation process of T1 (after the rules) all calendars (where Include current is cleared) update their periods. CAL1 evaluates its computation conditions and increases the frequency of its output, because B2 is true.
  4. End of processing T1
  5. Transaction T2 arrives
  6. All calendars update their output attributes with the current state of their periods. CAL1 will write 1 to its output Number of R1 fired.
  7. Rule R2 checks if the calendar output value is greater than 0. The value is 1, so R1 fired within the last 10 days
  8. R2 fires

To summarize and for clarity: If Include current was selected for CAL1, the evaluation condition that is dependent on a rule would never evaluate to true. Include current forces the periods to update before the rules are evaluated, in order to include the current transaction’s values in the calculation of the calendar outputs. As a consequence, it is not possible to select an output attribute in calendar conditions, when Include current is selected.

Remark: Final Rulesets are executed after the period update. Conditions that become true in final rulesets will therefore never evaluate to true in the calendars.