The following is a list of events in the system which force the engine to recalculate:
Raw and intermediate data can be added after the actual time they occurred. An example is in a case in which some event source was inactive and did not receive the data. Once the new data is added, the engine recalculates from the timestamp of the added event. For example, the value of the dollar was entered at the end of the month. The entire calculations for that month were based on the value of the dollar at that time. When the engine goes back to the beginning of the month, it recalculates using the new value.
Data can be corrected even after it has already been calculated. Corrections replace raw data.
Note: This situation is not the case with intermediate data, in which corrections cannot be added.
When a correction is added, the engine must find a state before the change occurred. The engine then starts recalculating the metric with the new, corrected data included in the calculation from that point in time.
For example, if a user mistakenly entered the number 5 as raw data last week. The user replaces the 5 with a 3. The engine must recalculate from the date when the 5 was entered. The number 3 is used instead of 5.
NOTE: A correction can be a deletion of incorrect data without replacing it with new data.
Events are received based on the registration to:
When a resource changes, the engine recalculates from the point when the resource changed. An example of this recalculation is when assigning or removing a resource from a resource group or changing the value of a resource custom attribute.
In a case where a list of servers has an ongoing indication of their status, server 3 was taken out for maintenance. Sever 3 was removed without a system notification. The user notifies the system that server 3 did not exist during the maintenance period. The engine goes back and recalculate from the date when server 3 was removed.
When a change is performed in the custom attribute of a resource, the engine recalculates all metrics that are associated with the resource. The metrics are recalculated from the date when the custom attribute changed.
For example, in a scenario in which servers are located in New York, Chicago and Los Angeles. The user decides to include the Chicago servers in the New York group. The manager then decides that the Chicago servers are actually part of the Los Angeles group and changes the status of the Chicago servers. The engine must now recalculate.
Exceptions can be created for defined periods of time. For example, there is a time period that is defined as within normal working hours, but there is an exception due to a power failure. This exception removes the specified time interval from the normal working hours. The events are still handled although they are now considered out of the timeslot. Once this time is differentiated from the normal routine, one can define the out-of-timeslot behavior in the business logic script. However, the user cannot yet define how the engine behaves during the time period of the exception. The behavior cannot be modified from the standard out-of-timeslot behavior. Exceptions can be defined before the actual time period or afterwards. When an exception is added to a timeframe that was calculated by the engine, it recalculates and takes the exception into account.
For example, there is a case in which a power outage notification was made a week ago. The system made calculations up to the present time, without taking into account the power outage. You need a recalculation in this case.
The business logic defined by the user can be created in each separate metric. In addition, if the logic is central and must be reused, it can be placed within a business logic module. This placement allows the user to create the logic once and use it in multiple metrics. However, when the module is changed to correct a mistake in the logic, all the metrics that are linked to the module that was changed. These metrics must recalculate to account for this correction.
For example, if the user has several clients and all of them want a help desk metric. The help desk logic can be placed in a business logic module.
Event reusability is a feature that allows the user to create metrics that use the results of the calculation of other metrics as input. This type of data is known as intermediate data. This data is created by having a metric send events that are similar in structure to raw data. The receiving metric then registers to this sending metric and receives the events that were sent the same way a metric receives raw data events. If the sending metric recalculates, it must delete the events it sent previously and recalculate the timeframe that requires recalculation. This means that the intermediate data that it sent previously is no longer up to date. The metrics that register to receive this data must also recalculate to account for the new data.
When creating a contract version, some or all of the contained metrics are recalculated from the beginning of the contract version. This recalculation is only done for metrics that had some change in them from the previous version. You receive no recalculation if you create a contract version and then commit directly. No recalculation occurs because metrics contain changes.
The following are cases in which there is no recalculation:
A new contract version is considered a calculation, not a recalculation so it does not appear in the recalculation history.
For example, there is a three year contract with ABC Company. You extend the contract for an additional year. This change leads to a new contract version. ACE1 recalculate the metrics from January 1 2005.
No change occurs if you have a contract with 100 metrics and you create a version and change the parameter of ONE of the metrics. The other metrics do not recalculate.
Note: If changes are made in the distant past, it causes a long recalculation. This recalculation takes a long time because affected metrics have to recalculate from the time of the change.
|
Copyright © 2013 CA.
All rights reserved.
|
|