TM1 Forum

Hi Guys

We have certain views used in Tis and want to prevent users from deleting them.

Any idea how to achieve this?


Regards
Chris

Only admins should be able to delete public views anyway.
That being said the safest way to prevent issuez with view datasources (including but not limited to them cluttering up the server) is to create and scrap them as part of the TI.

chewza wrote:Hi Guys

We have certain views used in Tis and want to prevent users from deleting them.

Any idea how to achieve this?


Regards
Chris

I can only echo what Declan said. DON'T use saved public views as data sources for TI processes. Any TI process using a view as a data source should be defining the data source on the prolog and deleting it on the epilog.

I second what the guys are saying about creating and destroying source views dynamically. Having said that, there is one trick that can be used to prevent users from deleting public views (even if they have admin access to the cubes in question). Any cube view whose name starts with a '}' character cannot be deleted (or created) from the GUI, only using TI.

qml wrote:I second what the guys are saying about creating and destroying source views dynamically. Having said that, there is one trick that can be used to prevent users from deleting public views (even if they have admin access to the cubes in question). Any cube view whose name starts with a '}' character cannot be deleted (or created) from the GUI, only using TI.

Good call; I have used these extensively but did note that in one particular version (of I think 10.1) it caused the client to crash if you tried opening a subset that had been prefixed with a } using the GUI.

You would however hope that Admins can be trusted not to delete things that are needed...
If they delete views without a seconds thought they could just as easily delete processes, cubes, dimensions etc.

Hi Guys

Sorry but I have to disagree. As I understand it the current IBM advice is to avoid creating and deleting Views as this causes locking.

I generally use a test to see if the View doesn't already exist, and if so then create it, and the same for Subsets. However, if the View does already exist, then I just modify the subsets using SubsetDeleteAllElements and the SubsetElementInsert, as required. This effectively changes the View. I don't delete the View or Subsets in the Epilog. (Obviously if you don't delete the View, you cannot delete the Subsets).

This approach results in the least requirement to create and delete Views and Subsets, which apparently reduces locking.

The fact that the View and Subsets get created if they don't already exist takes care of the case where a View gets accidentally deleted. Although I can't think of any cases where this has happened, as TM1 Admins don't tend to delete Views without thinking. Like many other developers I have seen, I always adopt the standard of naming Views that are used in Processes with a z_ prefix so that they all appear together at the bottom. Developers and users then know that these are system objects.

The more likely scenario is where a Process is promoted from the Dev environment to UAT and the first time it is run in UAT, it needs to create the Views as they don't already exist in that environment.

I am not a fan of starting any objects with a '}. I prefer to be able to rely on things starting with a '}' being real system objects. It does certainly reduce the risk of accidental deletion as these Views can then only be deleted by a Process. However, that can be a double-edged sword. A system I worked on recently caused Perspectives to crash every time someone double clicked on a SUBNM formula or the Subset Editor on a certain Dimension. Curiously it was a little slow but OK in Architect. When I investigated I found that the processes were constantly creating Subsets with a timestamp appended to the name and not all of them were deleting the subsets. When I investigated, I found that that the Dimension had over 11,000 subsets. The system administrator had been reluctant to delete them because of the need to write a process and he was not confident about doing that without the risk of deleting other items that might be needed. I deleted the } Subsets and suddenly the Dimension could be used in Perspectives again.

Regards

Paul Simon

Hi
I agree with Paul in terms of locking. When I was working with 10.1.1, I also tried not to delete views and subsets in the prolog to avoid locking. I have not had the chance to test this extensively in 10.2.2 yet (consequences of ViewDestroy, SubsetDestroy), I can imagine it might work better now.

paulsimon wrote:Sorry but I have to disagree. As I understand it the current IBM advice is to avoid creating and deleting Views as this causes locking.

That is true but I find if you separate the view/subset creations to a master process then call the data transfer TIs via TM1RunTI - you limit the impact of the lock to be negligible, get the benefit of being able to move your data in multiple TIs in parallel (saving extra time) assuming your task permits (e.g. not requiring iterative processing) and you then get the benefit of being able to tidy up all the views/subsets afterwards as not to clutter the GUI which I find provides a better UX.

That being said; like everything in TM1 it is horse for courses and all depends on the task; I try and do everything possible via moving data in parallel running TIs which means that I have naturally had to evolve my process writing to avoid locking regardless of whether there is high user activity at that time or not. An easier approach would certainly have been to keep all the views and subsets on the server but my first thought is always about trying to make the user interface as simple for users as possible and I personally feel that having a lot of objects they can see but are informed not too interact with just doesn't contribute to that.

declanr wrote:my first thought is always about trying to make the user interface as simple for users as possible and I personally feel that having a lot of objects they can see but are informed not too interact with just doesn't contribute to that.

I also prefer the creation/destruction of objects required for TI processes to keep it cleaner for users but on larger systems with multiple updates during the day, you may run the risk of locking.

Being able to filter out clutter (system objects not relevant to user usage) would be awesome - please see my post and follow the link to the RFE to vote.

Besides having users untick Dimensions/Processes/Chores and creating a useful Application structure, being able to select or exclude objects via some kind of expression would be very useful. We prefix our system related objects as I am sure many other developers do. Having some impetus behind the RFE would be greatly appreciated. Thanks in advance.

gtonkin wrote:I also prefer the creation/destruction of objects required for TI processes to keep it cleaner for users but on larger systems with multiple updates during the day, you may run the risk of locking.

This is why I mention breaking out the data processing part of the TI; you find that the actual view creations tend to take less than a second so if all that happens in that TI is the creation and then calls to command line with no wait command - it's all good.

declanr wrote:This is why I mention breaking out the data processing part of the TI; you find that the actual view creations tend to take less than a second so if all that happens in that TI is the creation and then calls to command line with no wait command - it's all good.

Would just like to understand exactly what you mean by "breaking out the data processing part" and if it is what I am doing.
Normally for these processes I would create a wrapper process to call multiple child processes to handle the view creation/instantiation of target, metadata management, data load(s), possible intermediate output and then cleanup.
Am I on the same page as you?

Hi gtonkin

What Declan means by breaking out the process is that his master process calls a process to create the views using presumably the usual ExecuteProcess, or he creates the Views within the master process, but when it comes to the data loading part, he uses TM1RunTI, which effectively starts a separate session. Therefore, locks created by the CreateView statement only persist for a short time, and not for the duration of the data load, as they would if he had used ExecuteProcess to trigger the data load.

Hi Declan

Your approach gets past the locking issue. However, there are different ways of achieving the same thing. My current users either use Cognos BI, which means they don't see TM1, or they use TM1 Web, which, with a config setting you can turn off the ability to see Views, and only give them access to Application Folders. Using Application Folders you can control which Views they see, and you can structure them into logical groups and sequences. A few users do have direct access to Perspectives but these are the power users and I don't get complaints that they see too many views. They just ignore the users that start with a z.

I am a little wary of using TM1RunTI as I did work on a system in the past where a rollback resulted in multiple processes being spawned. However, if it works for you that's good. I just wish that there was better support for this in the core product. If it either released the locks automatically at the end of the Prolog, or there was a commit statement then we would not have to resort to tricky additional processes, etc.

Ultimately some Views have to persist. For example the Default View, and Views used in the application. There is always a risk of people deleting these. One approach is to have a setup process per cube and to create the views in there. I use some macros that can reverse engineer the TI statements required to create all the existing views on a cube and these can then just be pasted in to the setup process which makes it easy to re-create the views if an Admin accidentally deletes them. However, on bigger systems you can also generally re-promote the view from the Dev environment.

A lot of the issues around this come back to a design decision made when version 7 was launched. In version 6 there was both a Query object and a View, and the Query object was intended for data loads. IBM should separate the object types again.

Regards

Paul Simon

Thanks for the feedback Paul - I have stayed away from TM1RunTI as many of our processes take only about 5 mins to load about 7 million records.
Saying this, there is contention and users are often not able to login during this time. I will look at farming out the data load to a TM1RunTI process in the Dev environment to see how it goes. I also need to review other configuration settings on this particular system to ensure that PI is turned on.