Reasons Slalom Scope may be different than PSL
Document ID :
Last Modified Date :
Show Technical Document Details
CA Business Service Insight
CA Business Service Insight:OBLCRE
What are some reasons that a metric calculation may be different in Slalom Scope than the results calculated by PSLwriter?
There are several possible reasons for this. They include:
1) Slalom scope doesn’t 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:
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.
You can run the scope:
Past the effective date of the contract
From before the contract is created.
Into the future (i.e. later than now).
These are all things that will give you results in the ‘scope that you can’t 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". This is an older type of calculation which is not supported by ACE2 and is usually not used in newer implementations. It is discussed further in the documents about migrating to ACE2.
7) The Scope doesn’t 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 T_SLALOM_OUTPUT. The PSL 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.
There are also a number of bugs discovered in older versions of the product which could cause this but at the time this is written (and for the past few years), they are all fixed and there are no known issues reported with the calculations of either Scope or the PSLwriter. So for this reason it's usually safe to assume if there are differences in the calculation results it is due to one of the reasons mentioned above.
So, how can you account for many of these possibilities? If you can afford the time and resources needed for a recalculation, then if you follow techdoc KB000010171 to clear all previous results and empty the current slalom table then you 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
Was this information helpful?