TM1 Forum

Is it possible to dynamically create a view, then use that view within the same TI to transfer data, then delete the view at the end?

I already have the code to create the view and It's easy enough to delete the view but where Im struggling is in how to use CellPutN in a TI where I have selected no datasource.

Does it take two TI's? One that creates the view, one that uses the view and then deletes it? Wouldn't this TI not like it if I opened it and the view didn't exist?

Thanks

Once you have created the view in the Prolog then you will have to instruct TM1 to use the new View as the DataSource. You can use the following statements to do that: and then in the Data tab you can use CellPutN() or CellGetN() statements.

How do I get variables for the dimension elements though? When you use the GUI it assigns variables like V1, V2 etc for each dimension.

You will have to create View and Subsets in the Prolog tab. See ViewCreate(), SubsetCreate(), ViewSubsetAssign() in the Manual.

What I meant was what do I put into the CellPutN formula for the variables?

PlanningDev wrote:What I meant was what do I put into the CellPutN formula for the variables?

You put the Value to put, Cube name and the Dimension Element names which defines the intersection.

example is:

CellPutN(Value, Cube, Dim1, Dim2,....DimN);

where Value is a numeric value

What do I do when I want all elements from one dimension? How do I have avariable for that? Or do I just list the dim name? In other words, I need tobmove data for multiple elements

When I want to have influence on the shape of view I want to iterate through in a TI process, I do the following:
- Create this view (usually I create the view via another TI, so I could name it with the '}' at the beginning, I also attach subsets with the same name with '}' at the beginning)
- Put it manually as a source of my TI process (even if later on I want to change it, this way I get all the variables defined in the Variables tab and know exactly what variable names I should use in my CellPutNs, CellGetNs etc., I usually switch in the variables tab from "ignore" to "other")
- Change the subsets in the Prolog Tab if needed (I can delete all elements from the already attached '}' subsets, and add elements I needed - all or part of it) - here you can put more or less elements for any dimensions you need.

HTH

PlanningDev wrote:How do I get variables for the dimension elements though? When you use the GUI it assigns variables like V1, V2 etc for each dimension.

I think we need to go back a few steps and explain a few things.

Firstly and most importantly when assigning a view dynamically the process needs to be set up as a VIEW source process not a NULL source process. Otherwise you won't have any variables and no access to write code on the meta data or data tabs. The variables are assigned as per usual and any CellPutN and other statements to do with the data source records also as per normal go on the data tab. As the view you can use any view from the cube - remember as long as you set DatasourceCubeView in the Prolog then the view you select in the data source tab won't actually ever be used by the process at runtime. If you want to you could also even set DatasourceNameForserver and change the cube on the fly not just the view, however if you do this then you need to make sure that the cube being swapped to has the same or less dimensions than the cube used for the "mock view" setup of the variables.

Thank you for the in depth explanation. The part I needed was the part about needing to use a view of some kind in order to get the variables to be used in the CellPutN function.

What it means is that I can't really clean up the views unless I borrow the default view then swap the view over to the one I created, then delete it in the epilog.

Thanks for the help!

To reiterate (partly), I always:

- create an easy view manually (not with a } at the beginning because I think that this is destined for control objects pur sang). I already take the same name as my temporary view (during the process) will be called.
- use it as the source of the process
- create the view in the prolog, with the same name as above
- delete it in the epilog
- ready !

Creating the view could also be done when selecting the view in the Data source tab. Next to the field for the Data source name, click create, pick the cube and create an easy view.

For these kind of processes, I never use the function DatasourceCubeview and its fellow functions. Simply, because it's not needed.

Wim

Wim Gielis wrote: - create the view in the prolog, with the same name as above

Won't you get an error message if you try to create a view that already exists? Don't you need to test for existence and then delete if found as your first step in the prolog?

Yes, that's what I do too. Indeed, in the beginning of the Prolog tab.

1 VIEWDESTROY statement
x SUBSETDESTROY statements, 1 statement per dimension in which a selection is made for the zero out

This code is useful since it could always be that a process hangs in, say, the Data tab. Launching the process again is valid since the Prolog tab will first remove the existing subsets.

Wim

Wim Gielis wrote:To reiterate (partly), I always:

- create an easy view manually (not with a } at the beginning because I think that this is destined for control objects pur sang). I already take the same name as my temporary view (during the process) will be called.
- use it as the source of the process
- create the view in the prolog, with the same name as above
- delete it in the epilog
- ready !

Creating the view could also be done when selecting the view in the Data source tab. Next to the field for the Data source name, click create, pick the cube and create an easy view.

For these kind of processes, I never use the function DatasourceCubeview and its fellow functions. Simply, because it's not needed.

Wim

Hi Wim,

I would disagree with your last statement. While assigning the data source via code in the prolog may strictly speaking not be necessary this is on the strict precondition that the view you have just created via code is named exactly as per the view manually selected on the initial data source tab. It is at the very least a very good idea to set the cube and view via code on the prolog also (not just a good idea but mandatory for anyone coding on any of my projects.)

For the sake of 2 or 3 simple lines of code why expose your process to the unnecessary risk of breakage at the hands of a TM1 admin who may inadvertently change the view name? Any time you create or modify a view or subset via code with the intention of using the object it is good practice to make sure the object is properly assigned rather than assuming no one has changed any settings. While you can't always bullet proof code to account for all possible sources of human error or stupidity, where it is very simple to do so then you should.

Hello Lotsaram

I do not follow your last post, frankly. I indicated that I always use the same view name in my first bullet point.

Next to that, we are really speaking of temporary objects (views and subsets). They only live for the execution time of the process. In the Epilog they are destroyed.

If naming *exactly* is the issue, well you could use copy-paste to make sure they are the same and do not contain typo's

Hence, I cannot see any risk you run there. (Besides the fact that the chosen name for views or subsets could be used by a user or admin user. But if the name is sufficiently random, that is no issue IMO. For instance, ZZZ_SOURCE VIEW_WIM_PROCESS... or ZZZ_TEMPVIEW_REVENUES or whatever. Your method has this limitation as well.

There are obviously cases in which I used these functions, but not in processes like this.

Wim

Hi Wim,

In a perfectly quarantined model the approach of not resetting the data source might be an acceptable shortcut where you and only you have access to the system. However in any system that is handed over and in production where an inexperienced or careless admin might change the source view it is in my opinion an unacceptable risk. If you know the name of the view (as the name will have been hard coded or referenced on the prolog) that has just been built or modified then it is really no problem to set the data source to be the view just created/modified and avoid the potential risk of corruption the process.

In a closed system this might not be necessary. I think you are running off the assumption of a closed system whereas I am assuming that the system is (or could be) accessible to others.

Hi there,

I see you point of not taking unneeded risks, but there is (according to me) no risk at all. Or at least not a risk that you do not run as well.

The view does NOT exist prior to executing the process, then the process runs, creates the view, does other things, and in the Epilog (or another process you call) the view is deleted.

That is bullet proof, no? Except if:

- the name of the temporary view would already used somewhere on the TM1 server, chances are very low
- users (admin users) start changing in the code of the process itself, then anything (adverse) can happen

Both drawbacks will be there too if you use the extra functions.

Or am I overlooking something here? I don't want to seem thick on this, but I prefer less code with no extra risks due to that.

Wim

Or am I overlooking something here? I don't want to seem thick on this, but I prefer less code with no extra risks due to that.

Maybe. The biggest risk that I see with your approach is one that you have not listed. Namely that an administrator could unwittingly or accidentally change the manually selected data source view. If that happens then the view with your carefully chosen and specified name that has just been created to exact specifications on the prolog won't get used by the process at all. That's not what I call bullet proof.

If DatasourceCubeView is used to set the view then the process is immune to this possibility as the identity of the manually selected view is irrelevant.

I'm not talking about code being deleted or changed. That could potentially break any process no matter how well written so I would discount that.

Ah, now I see what you mean. Yes, that could possibly happen.

I have not come across this issue in the past, but in theory it can occur.

Wim