more generic style for rule area
Posted: Tue Jun 26, 2018 5:18 pm
Hello all,
I wrote a rule to set an indicator for changed values in spite of distributing those along their children (a handmade spreading function, finally).
I use the concept to have a N-element outside of the main hierarchy for each C-element I want to be able to be a starting point of this spreading.
The dimension ValueType makes up 3 layers (value: the working layer, change: layer to set flags in spite of deriving a view as small as possible to perform the spreads later, difference: points out the amounts to spread on a flagged C-element to support the spreading later).
For example the Element 8 got a new target value (Element 8_deltaelement to take the value ad interim, bound to its original C-element via an attribute 'deltaelement'): 140/green instead of 120/blue = Changed:1 => Difference=20
My (working) rule for a first testscenario to make BedrockTestDim4 (depicted above) spreadable:
My question about that: Did I oversee a more generic way to achieve adressing the C-elements which are actually named in the area definitions between the curly brackets? Here I have only 6 C-elements, but I doubt how this solution could carry even a system having hundreds of c-elements in a real world application. Is this best practice?
Is it a good style to keep the feeder statements such generic, or should I better narrow them also by a subset expansion?
Any hint is highly appreciated as I hope that I could avoid upcoming rules making real experts getting crazy on first notice...
I wrote a rule to set an indicator for changed values in spite of distributing those along their children (a handmade spreading function, finally).
I use the concept to have a N-element outside of the main hierarchy for each C-element I want to be able to be a starting point of this spreading.
- TM1Forum_1.jpg (127.61 KiB) Viewed 2333 times
- TM1Forum_2.jpg (48.95 KiB) Viewed 2333 times
For example the Element 8 got a new target value (Element 8_deltaelement to take the value ad interim, bound to its original C-element via an attribute 'deltaelement'): 140/green instead of 120/blue = Changed:1 => Difference=20
My (working) rule for a first testscenario to make BedrockTestDim4 (depicted above) spreadable:
Code: Select all
Skipcheck;
['Changed',{'BedrockTestDim4':'All','Element 1','Element 2','Element 3','Element 4','Element 8'}]
= C:IF(DB('RuxCube2','Value',!BedrockTestDim1,!BedrockTestDim2,!BedrockTestDim3,ATTRS('BedrockTestDim4',!BedrockTestDim4 ,'Deltaelement'),!Measures)=0,0,1);
['Difference', {'BedrockTestDim4':'All','Element 1','Element 2','Element 3','Element 4','Element 8'}]
= C:(DB('RuxCube2','Value',!BedrockTestDim1,!BedrockTestDim2 ,!BedrockTestDim3 ,ATTRS('BedrockTestDim4' , !BedrockTestDim4 , 'Deltaelement'),!Measures)
- DB('RuxCube2','Value',!BedrockTestDim1,!BedrockTestDim2,!BedrockTestDim3,!BedrockTestDim4,!Measures) )
* ['Changed'];
Feeders;
['Value'] => ['Difference'];
['Value'] => ['Changed'];
['Changed'] => ['Difference'];
Is it a good style to keep the feeder statements such generic, or should I better narrow them also by a subset expansion?
Any hint is highly appreciated as I hope that I could avoid upcoming rules making real experts getting crazy on first notice...