Is This a good practise??

[vinnusea]

Hi
I Have written some Control Cube Rules for populating attributes based on some condition.
1. }ElementsAttributes_SKU
And also written some Rules for applying Secuity for Application Dynamicallty in Control Cube }ApplicationSecuirty
All are working good

So my question will be
1. writing the control cube rules is a best practice or i should not be done this.
2. Writing rules in }elementattributes cube is a good practice or i should have read the attribute values in TI process and do my calculation and Put attributes through AttrPut command..... Writing Rule was Much easier but am not sure how good this practice is


Thank you....

[mattgoff]

Rules in control cubes are fine and are considered by many to be a best practice. Don't forget that rules in security cubes require a SecurityRefresh before they become effective; they're not truly real-time like other cube rules.

Matt

[vinnusea]

Thank you for the Quick response .

So i need to add
SecurityRefresh;

before my rule starts
My rule structure will be something like this:

Code: Select all

SecurityRefresh;
FeedStrings;
Skipcheck;
<Rule Lines come here>
Feeders;

Thank you

[mattgoff]

Nope, SecurityRefresh is a TI function. If you're going to use security cube rules, I'd create a chore than runs periodically to do it automatically. You can also run it manually via right-clicking on the server name->Security->Refresh Security.

Matt

[vinnusea]

oh....Ya got you... sorry i forgot this is a TI function..
Yes i will create a chore for refresh security periodically.
Thanks,

[Kaveenga]

Its proven practice to use rules in Control cubes. However, I would caution using rules on the }ApplicationSecurity cube.

Also, creating a standard cube as a clone of the attributes cube is better practice (IMO) when you want to give users access to change dimension attributes. You then rule across the values from the standard cube to the attributes cube.

[vinnusea]

Yes you are right..For User updating the attributes i have created an excel sheet with DBRA formule...
But your approach of clone cube will be much efficient..
Thanks for the advice..

[lotsaram]

Its proven practice to use rules in Control cubes. However, I would caution using rules on the }ApplicationSecurity cube.

Also, creating a standard cube as a clone of the attributes cube is better practice (IMO) when you want to give users access to change dimension attributes. You then rule across the values from the standard cube to the attributes cube.

I don't know, I have had no problems in the past using rules for application security, ... although these days I would favour TI to update any element security since it does away with the need for a security refresh whihc you are stuck with using rule derived element security.

I would also favour using TI to move attribute values from the mirror "control cube" to the atribute cube (mainly because TM1 never caches rule derived string values). One word of warning though on using rules in attribute cubes, NEVER use a rule to create an alias as this has the potential to create all sorts of issues.

[mattgoff]

One word of warning though on using rules in attribute cubes, NEVER use a rule to create an alias as this has the potential to create all sorts of issues.

What sorts of issues? I've had rule-created aliases running for years and haven't noticed anything. They are based on another alias, so if the risk is regarding alias duplication (and a paradox if a rule is trying to create it), we're protected from that.

e.g.

Dim: Accounts
Element Names: Account codes
Alias 1: Account names
Alias 2: Account code + account name

Yes, I know this would better be done via TI instead of a rule, it's on my "have nothing else to do" to-do list.

Matt

[lotsaram]

What sorts of issues? I've had rule-created aliases running for years and haven't noticed anything. They are based on another alias, so if the risk is regarding alias duplication (and a paradox if a rule is trying to create it), we're protected from that.

All sorts. Say a model uses a description as an alias without concatenating the principal name or an alternate key (of course it shouldn't but just say it does ....) then if the field where the description string is sourced from is changed ot a duplicate than you get a silent fail as opposed to an overt one. Or if the multiple description fields are cleared and the rule did not have the inteligence to use if blank then principal, else description logic. Or if description fields are changed but there is no meta data change so no forced recompolation of the dimension. In all of these insances I have seen soem really weird behaviour with no alias values actually changing or multiple elements appearing to have the same alias, or aliases appearing to be fine in cube viewer but producing key err when sliced to Excel.

Just easier and safer to set aliases with TI since this then never seems to cause any issues and in theory should be lighter and faster for the server (even if it is only 1% of 1%)