Slalom Scope different than PSLWriter
search cancel

Slalom Scope different than PSLWriter

book

Article ID: 117284

calendar_today

Updated On:

Products

CA Business Service Insight

Issue/Introduction

What are some reasons that a metric calculation may be different in Slalom Scope than the results calculated by PSLwriter?

Environment

CA Business Service Insight 8.3.5.x and 9.0

Resolution

There are several possible reasons for this:

1.  Slalom scope does not use saved states. If there is a problem with a global variable that is of a type that is not allowed, this variable will be empty when it is loaded from a state. 

2.  The scope is not limited to the dates of the version, so:

  1. If information is passed from one period to the next and the time span requested in the scope is not identical to that on the contract’s dates, the information it starts from will not be the same.
  2. You can run the scope:
    1. Past the effective date of the contract
    2. From before the contract is created.
    3. Into the future (i.e. later than now).

These are all things that will give you results in the ‘scope that you cannot get in PSLWriter.

3.  The Scope runs on the data and the resource structure as they are NOW. PSLWriter runs in cycles, so the data may have changes since the last time PslWriter calculated it.

4.  The scope can run on preliminary versions of either the contract or the modules. PSLWriter only runs on the committed versions.

5.  Event reusability sender metrics must be run manually before the receivers in the Scope.

6.  The Scope does not do "continuous calculations". FYI - this is an older type of calculation which is not supported by ACE2 and is usually not used in newer implementations

7.  The Scope does not care about metric versions.  If you have several non-overlapping versions and you run the scope for the entire range of the contract, only the specified version will be run.

8.  While this may overlap some of the explanations above, another way to explain differences in results is that many business logic scripts write data to the T_SLALOM_OUTPUT table. The PSLWriter calculations are based on the current T_SLALOM_OUTPUT while Scope uses a temporary slalom table which starts with nothing in it. So if a previous month wrote data to the slalom table which is used in calculations and you compare only the current month, there would be obvious differences in results. If you previously wrote data for an event and that event was removed or corrected, there could be obvious differences. 

How can you account for many of these possibilities?

If you can afford the time and resources needed for a recalculation, then clear all previous results, empty the current slalom table and allow the PSLWriter to recalculate. 

Then make sure you run Scope for the same date range on the committed metric version - these results will usually match. If they do not, then this is likely due to one of the other reasons such as metrics generating events which are consumed by the current metric also need to be recalculated (and would need to be manually run in scope first) or you have multiple versions in the contract while scope is only running against the version you specify.