Cell Security with TM1 10.2.2

[holger_b]

Dear all,

there is a change in my biggest client's reporting structure which will make Cell Security necessary, actually there is no way around that. The cubes we are talking about are really vast, like up to 1.2 billion elements in the products dimension, quite a few hundred reporting units, just any measure one could ever think of and so on. So performance is a big topic here.

I am forced to produce at least a rough concept within just a few days, so there is not much time left for testing. Therefore my question: Could someone let me participate from his experience? For example, how is your experience with rules in Cell Security cubes - would you say I should rather fill the security cubes with a TI process, or is it worth a try? Did you see any performance improvement between earlier versions and 10.2.2? How did you solve it, and was it a good choice? I thought I might want to have one group per user so to have maximum flexibility (which would make around 500 groups), would you say this is feasible or not?

Any advice is most welcome.

Thank you
Holger

[paulsimon]

Hi Holger

I have used rules in CellSecurity cubes on some pretty big cubes without issues. Cell Security used to be one to avoid because of poor performance, but IBM improved the performance around version 10.0 I think it was, so I don't think it is such an issue.

I would actually recommend that you use rules rather than TI to populate the cube. If you physically populate the cube, then it is likely to get very large. However, if you use rules, as they are string rules, they don't need to be fed.

Bear in mind that you may still need to implement ElementSecurity to limit the list of values that a user sees, even if the CellSecurity will still stop them inputting into an invalid combination.

Regards

Paul Simon

[qml]

Paul is generally right, surprise, surprise. However, recent versions of TM1 have introduced a change to the cell security cubes such that they do not have to have all the dimensions of the main cube anymore (plus }Groups). If your cell security is based on only one or two (or more, but small) dimensions then populating the cube using TI becomes a very good option as the cell security cube can still be small, but you have the added benefit of not having to calculate the security rules on runtime (they are not cached, so need to be recalculated every time).

I think this is a game changer and it's made cell security much more useful. I can vouch for it based on the results I've seen in my last two models. Bottom line: cell security does not have to be a performance killer at all if used right and should not be overlooked. In some very specific cases it's the only option left, so some developers don't like it (who doesn't like to have options?) but I'm not one of them.

I can't comment on your particular scenario as you haven't given us too much information to go with, but if your security is not based on your humongous product dimension then a rule-less cell security cube can be an option. Otherwise, you might still get away with rule-based cell security. It's probably at least worth exploring.

[lotsaram]

qml makes some excellent points. (It's just a shame that to create the new cell security cubes you have to use Performance Modler - correct me if I'm mistaken.) and PM may well choke trying to load your model if it has dimensions of that size!

Although I only use cell security when I have to I have never found it to be a performance killer. Even with rules (in fact I have never implemented cell security NOT using rules). The thing about cell security is that it is evaluated on the fly as the user makes the request. So assuming the cell set isn't too big (which is a generally safe assumption for a UI query) then the overhead is low and hence the performance impact to the users response time generally minimal or not noticeable.

Normally the killer from a performance PoV is element security on really large dimensions. Be interesting to hear what you find out. I think you are more than likely on the leading/bleeding edge on this one.

[qml]

It's just a shame that to create the new cell security cubes you have to use Performance Modler - correct me if I'm mistaken.

<shivers at the sheer thought of having to use PM for something like this> Luckily it's not the case. It's enough to use the new TI function CellSecurityCubeCreate. Its second argument alows one to specify (in a slightly clunky but effective way) which of the dimensions of the main cube should be included in the cell security cube.

I've had the opportunity of using it a few times already and I think whoever at IBM thought of adding a real feature like this (instead of just the mostly useless fluff being added recently) deserves a crate of their beverage of choice. And a hug.

[lotsaram]

I'll have to try that the nex time I need cell security. Another nice new feature is the cube and dimension name localization which works and is a great feature but even more clunky to set up, ... and although there is (some) documentation it remains well hidden.

[holger_b]

Thanks a lot everyone for your advice! I will take some time for prototyping and performance tests during the next couple of weeks, and I will post my findings here.

Holger