Best Practice for Views created within TI Process

Post Reply
tm1expert
Posts: 27
Joined: Sun Aug 02, 2009 2:57 am
OLAP Product: Cognos TM1/Cognos BI
Version: from 9.4 to PA 2.0.9
Excel Version: 2010
Location: Toronto

Best Practice for Views created within TI Process

Post by tm1expert »

Hi,

I have a question about best practices regarding TM1 Views that are used as Data SOurces in order to Extract Data out of TM1 or Copy one Portion of the Cube to another Portion.

Is it beter to always Destroy cubes at Epilog and Recreate them in the Prolog, or to keep these Views so the next time the TI Process Runs the View is there, so the Prolog does not have to recreate it.

Same question goes for subsets used in these views. Is it beter to delete them in the Epilog?

Our model is large and we keep some of these views, which might not be a good thing.

Thank You
Ardian Alikaj
User avatar
rkaif
Community Contributor
Posts: 328
Joined: Fri Sep 05, 2008 6:58 pm
OLAP Product: IBM Cognos TM1
Version: 9.1 or later
Excel Version: 2003 or later

Re: Best Practice for Views created within TI Process

Post by rkaif »

One of the reason we create the Views in Prolog and delete them in Epilog is that when you will run the TI in future you will get the most updated Views. e.g. if there is any change in the dimension you will be able to see that.
Cheers!
Rizwan Kaif
tomok
MVP
Posts: 2836
Joined: Tue Feb 16, 2010 2:39 pm
OLAP Product: TM1, Palo
Version: Beginning of time thru 10.2
Excel Version: 2003-2007-2010-2013
Location: Atlanta, GA
Contact:

Re: Best Practice for Views created within TI Process

Post by tomok »

The most common practice is:

Prolog
1) check for the existence of view and subsets, delete if found
2) create subsets and views

Data
1) do whatever

Epilog
1) check for existence of views and subsets, delete if found
Tom O'Kelley - Manager Finance Systems
American Tower
http://www.onlinecourtreservations.com/
tm1expert
Posts: 27
Joined: Sun Aug 02, 2009 2:57 am
OLAP Product: Cognos TM1/Cognos BI
Version: from 9.4 to PA 2.0.9
Excel Version: 2010
Location: Toronto

Re: Best Practice for Views created within TI Process

Post by tm1expert »

Thank you.

This helps a lot
Ardian Alikaj
tm1expert
Posts: 27
Joined: Sun Aug 02, 2009 2:57 am
OLAP Product: Cognos TM1/Cognos BI
Version: from 9.4 to PA 2.0.9
Excel Version: 2010
Location: Toronto

Re: Best Practice for Views created within TI Process

Post by tm1expert »

I Have one more question regqrdin this approach.

I use these views as data Source in the TI Process, and if I drop the View in Epilog, then the next time you open the TI Process, it gives an error "Cannot find the specified View". How do you fix this?
I'm thinking of creating a dummy view for each cube as save each TI Process with that View as Datasource and then dynamically change the Datasource in Prolog after the Real Data SOurce View has been created.

What approach do you use in this case?

Thank you
Ardian Alikaj
Alan Kirk
Site Admin
Posts: 6667
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: Best Practice for Views created within TI Process

Post by Alan Kirk »

tm1expert wrote:I Have one more question regqrdin this approach.

I use these views as data Source in the TI Process, and if I drop the View in Epilog, then the next time you open the TI Process, it gives an error "Cannot find the specified View". How do you fix this?
I'm thinking of creating a dummy view for each cube as save each TI Process with that View as Datasource and then dynamically change the Datasource in Prolog after the Real Data SOurce View has been created.

What approach do you use in this case?
I take a somewhat different approach to the ones that others here take; a more conservative one. I use four processes; one to create the subsets and view(s) (with the subsets always having a unique name for each execution of the chore; it gets around the situation where subsets may get "locked" because TM1 incorrectly believes them to be still in use by a view), one to process the data, one to delete the views, one to delete the subsets. The last two are separated out into individual processes just in case earlier processes crash.

So what I do in those circumstances is just to manually run the first process which creates my view, then edit my data process(es), then manually run the processes to clean up the views and subsets.

Your approach of using a dummy view (then reassigning the "real" view name in the prolog) would also work, though I prefer not to have any more predefined views lying around than absolutely necessary.

Different horses for different courses...

Bear in mind that unless you need to manipulate the variables, in most cases it doesn't matter if the process can't find the view. You can still edit and save the code anyway.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
Kyro
Community Contributor
Posts: 126
Joined: Tue Nov 03, 2009 7:46 pm
OLAP Product: MODLR - The CPM Cloud
Version: Always the latest.
Excel Version: 365
Location: Sydney, Australia
Contact:

Re: Best Practice for Views created within TI Process

Post by Kyro »

You could have a surrogate view like you said and follow Tomok's approach for keeping the number of TI's Down.

Prolog

(For Aggregate Data Loads)
1a) Check for the existence of view (of the destination) and subsets, delete if found
1b) Create subsets and views (of the destination)
1c) View Zero Out
1d) Cleanup subsets and views

2a) Check for the existence of view (of source) and subsets, delete if found
2b) Create subsets and views
2c) Set Datasource from Dummy to the View that was just made

Data
1) do whatever

Epilog
1) check for existence of views and subsets (of source), delete if found

But add a unique subset/view name each time as Alan does.

If its a simple copy, use Bedrock. If its more advanced - Still use Bedrock to do the Zero Out in a single line.
Post Reply