Cognos Tm1 testing startergy

wwpsy

Hi All,

Request someone to please share best practices adopted in thier Cognos Tm1 testing startergy.

Regards,
ravi

wkinki

Here are some things to look at.

Change Review:
What is the purpose of the change? How has this been accomplished in TM1? Does this make sense?

Code Review:
Check the Rules and TIs. Are they coherent, do they perform the actions required? Check them against best practice standards such as, having clear well-commented code, limiting hard coded elements in Rules (use rollups instead).

Performance Review:
Turn on Performance Monitor. Take snapshots of cube memory and disk memory consumption as-is. Implement the changes, Save Data, and compare the difference. Is this reasonable?

caoshuo594

Christopher, I'm somewhat bemused by

"limiting hard coded elements in Rules (use rollups instead)"

The left hand side of a rule _must_ be a specific, named coordinate.

On rollups, I hope you mean that consolidations are much faster than using + in rules.

Otherwise, I'm happy with what you say. I think the main challenge with TM1 testing is the evanescence of the numbers. If you want to compare before and after a code or structure change your options are rather limited - two server instances (if you have the licenses), Excel snapshots as a control. I'd be interested if anybody has better suggestions.

xdd11

Hi David,

I should have been clearer - when applying Rules to elements that belong to the same parent, I have found it better practice to use IF(ELISANC rather than list every element in the Area statement (left hand side). I believe it keeps the Rules cleaner and easier to read.

wanglinyangling

I agree in general. Two further observations:
a    Since elisanc returns 1 or 0 you can avoid the IF test (always good for readability) and just multiply by the elisanc;
b    Elisanc is a fairly greedy function. I have been building a very large modelling app (put it this way, we couldn't fit it into a 128gig server and had to write an overnight batch calculate routine   ) and thus, of course, introduced all the conditional feeders I could come up with. Some of these relied on the dimension structures. Initially I used elisanc in the feeder management cubes, and found it pretty slow. I added a routine which froze the elisanc output into a set of flags. This runs subsecond, and made the main feeders much faster.

libo600

Hi David - thanks for the insights on performance. The flag approach sounds like a great solution - dealing with cubes of that size I'm sure you'd need to be extremely innovative and performance focussed.

jxs0103

Hi All,

Thanks for your inputs.

I have another clarifications - How to ensure that data correct in Tm1 cube.
Means, what kind of test strategy or check list to ensure data is correct in tm1 cube- besically how do we do data validation for tm1 cube.

Regards,
Ravi

亚伯拉汉

I would balance the data back to it's source.

If you are checking rules then normally there is process that currently exists that you are putting in to TM1. Run the 2 inline.

This testing approach for data isn't really specific to TM1. It applies to most software implementations.

yzbboy

ravi wrote:I have another clarifications - How to ensure that data correct in Tm1 cube.
Means, what kind of test strategy or check list to ensure data is correct in tm1 cube- besically how do we do data validation for tm1 cube.

Is this a serious question? ... Assuming that it is ...

As you would need to do with implementing ANY reporting system (or any other system for that matter) data in the new system will need to be reconciled against the existing system and existing reports and signed off by the business as being correct.  This is standard practice, nothing unique to TM1 here at all.

Note however that the main cause or reconciliation issues with new TM1 systems is usually double counting in hierarchies, the base leaf level data is typically fine as a rule.

Things can get hairy when reconciliation issues get traced back to calculation errors in the existing system.  Usually the business owner will agree to take the correct result from the new system however sometimes it is more expedient to not need to restate history and replicate the errors of the old system in the new one and that's when things can start to get difficult.  Again this is not a TM1 issue but a totally generic one.