Rules for Control Cube

[deepakjain2020]

Hi All,

Why control cubes can't be driven by rules? For e.g. }CubeSecurity.

Ref link below says under topic "Maintaining security metadata in TM1 security objects" that those should be process by TI process, instead of rules.
http://www.ibm.com/developerworks/libra ... index.html



Regards,
Deepak Jain

[Edward Stuart]

Are you looking for elaboration on the explanation given on the link?

If Turbo Integrator is used, a security metadata change – due to, for example, a hierarchy change with corresponding/resulting security changes for parent and/or child nodes or a new element being added to a hierarchy such as a new archived version for which Read access is now to be granted to all applicable groups – will always require running the SecurityRefresh() command in IBM Cognos TM1, effectively rendering all cached security settings invalid and hence renewing/refreshing all security credentials. A security refresh on large models will typically lead to a multi to many minute lock of all user activity due to IBM Cognos TM1 refreshing security access credentials for all active users and groups. If security is manually entered or processed via Turbo Integrator (and therefore directly stored in the corresponding security cube), a security refresh is not necessary for such security changes. The security changes will propagate automatically and with only very short locks.

[qml]

Why control cubes can't be driven by rules?

They most certainly can.

And, like with most things, the full answer is much more complicated and boils down to you having to know what you are doing. Use it when it makes sense and don't use it when it doesn't make sense. The explanation quoted by Edward is broadly correct, but the same document says elsewhere (also generally correctly, but there are exceptions):

IBM Cognos TM1 cell level security is applied individually per cube via the content of a cube-specific cell level security cube with values such as Read, Write and None for the security groups and cube cell intersections and subsections that are to be secured accordingly. The data content is typically also determined via rules in the cell security cube rather than written to the cell security cube using a Turbo Integrator (TI) process. Cell security cube rules are re-evaluated automatically once a user refreshes a query. This is contrary to cube, dimension and element security as a SecurityRefresh() is not required to refresh credentials established by cell security rules.

The reason for not using a TI process is the corresponding data volume would be very high if one were to process cell level security via TI. Also, because all or, at a minimum, a very large number of cells would have to be processed, the TI process would suffer from a very long runtime. More importantly, a security change at the element security level (which typically warrants corresponding changes at the cell security level) would require re-processing of the cell security credentials in each applicable cube, causing long processing times and corresponding user locks after only minor security changes.

So clearly drawing the simple conclusion that you are drawing is not supported by the linked document (or by experience).