The way the SLA Engine processes the data of a Task SLA (stage field, timing fields etc.) is strictly related to the historical updates made on the related Task record. There are many documents explaining the process of the SLA Engine (SLA documentation).
As part of an enhancement to provide advanced SLA condition operators (changes, changes to, changes from), a new utility API called HistoryWalker has been released to generate historical versions of a given record. There are a few settings, included in the HistoryWalker API, that affect the structure of the returning walked GlideRecord (or walked GlideRecord copy).
In this document, the use of the withVariables setting will be discussed, in particular, which variable types are not supported by the HistoryWalker API. This document also applies to the SLA Engine, specifically to use cases were the variables are being used in the condition of the SLA Definition.
The HistoryWalker evaluates historical updates taken from the History Line/Audit of a record, the same shown when clicking the context menu History > List from the record form. Differently to normal fields, the variables are stored in the History Line/Audit via their display value only. Therefore, HistoryWalker takes the variable display values and tries to calculate the correspondent database value, however the unsupported variable types, below listed, might have incorrect data:
- Lookup Select Box
- Lookup Multiple Choice
- List Collector
The reasons why the above variables types might be incorrect vary according to the type. The walked GlideRecord (or walked GlideRecord copy) created by HistoryWalker can be described as a virtual GlideRecord object, since it does not contain data of a record stored in the database, it just contains data built up by fetching the historical updates in the History Line/Audit.
Variable types referencing to another table (such as Reference, Lookup Select Box, Lookup Multiple Choice and List Collector) might suffer the issue of a record not being referenced anymore.
As simple example, let us assume to have a Lookup Select Box variable that is configured to reference to the User [sys_user] table and filtered to reference active user records only.
The list of active users is periodically altered since user records become inactive under certain circumstances. In this example, Abel Tuter has left the company, resulting the record of Abel Tuter (inactivated) being inaccessible from the virtual GlideRecord object built up for an historical update although the display value “Abel Tuter” is actually shown in the History Line/Audit.
There are also other known reasons for which HistoryWalker cannot support the above types; e.g. duplicated display values would cause ambiguity and cannot be properly differentiate in variables referencing records of another table.
Other types (Date/Time, Duration, Masked) are affected by the impossibility of converting the display values to the correspondent database value.
SLA Definition Conditions
Although HistoryWalker tries to populate variables of the above types in the virtual GlideRecord object, there is still a number of cases, some explained above, where these variables might contain incorrect data in their historical versions. This can consequentially cause unexpected behaviour if any of these variables is being used in the condition of an SLA Definition.
Specifically to the SLA Engine, when processing the updates of the parent record synchronously, the way HistoryWalker evaluates the variables would be correct for all the variable types.
When processing the updates asynchronously (i.e. when the system property com.snc.sla.engine.async is set to true), and also when repairing SLA or showing the SLA Timeline, SLA Engine might encounter potential issues if the unsupported types are used in the condition of the SLA Definition.
Why is the live synchronous update not affected?
The reason is that there is no need to check historical updates when modifying a record synchronously as all the data needed by the SLA Engine is stored in the objects current and previous.
Why are cases of async engine, Repair SLA and SLA Timeline incorrect?
The Repair SLA feature works by deleting the current Task SLA(s) and then processing Task SLAs from the first historical version of the given record to the last one. In the same way, “SLA Timeline” evaluates the historical versions and format/show them in the related Gantt chart. While applying the SLA Engine asynchronously instead, the object previous is known to be not available, therefore the need to run HistoryWalker.