TM1 Forum

Hi All,

This is my first post, I've read the terms and guidelines, and will try to provide all the relevant information.
Issue:
Cognos Express 9.5
I've duplicated this issue in Architect and Xcellerator on Windows 2003 and windows 2008 , both 64 bit.
I have this rule:
[{'Forecast Q1'},'Division','60110','local','amount']=N:
DB('Revenue',!Year,!Month,!Version,!Cost_Centre,'Centre',Agent' ,'Channel','Targeting','Revenue');

Using this feeder:

['Targeting','Revenue']=>
DB(
'GL',
!Version, !Year, !Month, 'Local', 'Ninemsn', 'No Function',
'No Location', ATTRS('Common_Site',!Common_Site,'T2_Code'), '60110', 'Amount');

There is a stet that shouldn't effect things, since it is set to 1:
[]=
IF( DB('Global_Variables', !Version, !Year, 'Budget Rules On', 'Number')=1,
CONTINUE,
STET);


I have 2 elements, one had a T2_Code, the other did not. The element with the code was correctly feeding its numbers to the GL Cube, the one without obviously didn't as there was no T2_Code to map to the Element ID in the GL cube dimension. I manually added the T2 code to the second Element, but this did not resolve the issue. I restarted the server and services.
The Elements:
ID T2_Code
Bob and Son 105
Johnson Co 106


When tracing the calculation in the GL cube I get:
Global_Variables(Forecast Q1, 2014, Budget Rules On, Number) 1
[]=IF( DB('Global_Variables', !Version, !Year, 'Budget Rules On', 'Number')=1,CONTINUE,STET);
[{'Forecast Q1'},'Division','60110','local','amount']=N:DB('Revenue',!Year,!Month,!Version,!Cost_Centre,'Centre',Agent' ,'Channel','Targeting','Revenue');
[{'Forecast Q1'},'Division','60110','local','amount']=N:DB('Revenue',!Year,!Month,!Version,!Cost_Centre,'Centre',Agent' ,'Channel','Targeting','Revenue');

The cell that is displaying a value returns the following additional row, there is an F(x) symbol in front of it:
Revenue(2014, Jul, Forecasty Q1, 105, Targeting, Agent,Channel,Revenue)



I have no idea why the one cell is feeding but the other is not.
Please help!

Thanks!

Hi,

Please note that a feeder is triggered when the feeding area changes from 0 to non-zero. This means that the feeder is only re-triggered when the ['Targeting','Revenue'] area changes from zero to non-zero, not when the attribute value changes.
However if the attribute value is changed (pointing to an existing element) and the rules sheet with the feeder is re-saved, I would expect the requiered cell to be fed.

Michel

You might try looking at this configuration option ForceReevaluationOfFeedersForFedCellsOnDataChange which looks as if it designed for precisely your situation. I believe that in 9.5 the equivalent option is ReevaluateConditionalFeeders.

I can't say I've ever used it and it does come with a health warning as feeders will be re-evaluated more often and this could affect performance on data write.

Good point Duncan. I would only enable this if your model is not on the large side. If it's small but complicated you might be ok. Your other option is to look at a slight over feed and remove the conditional feeder.

Thanks guys, I will test these and let you know how it goes!

Michel Zijlema wrote:Hi,

Please note that a feeder is triggered when the feeding area changes from 0 to non-zero. This means that the feeder is only re-triggered when the ['Targeting','Revenue'] area changes from zero to non-zero, not when the attribute value changes.
However if the attribute value is changed (pointing to an existing element) and the rules sheet with the feeder is re-saved, I would expect the requiered cell to be fed.

Michel

So feeders do not get re-triggered if the entire server gets rebooted and the cube is loaded into memory?

ashvds wrote:

Michel Zijlema wrote:Hi,

Please note that a feeder is triggered when the feeding area changes from 0 to non-zero. This means that the feeder is only re-triggered when the ['Targeting','Revenue'] area changes from zero to non-zero, not when the attribute value changes.
However if the attribute value is changed (pointing to an existing element) and the rules sheet with the feeder is re-saved, I would expect the requiered cell to be fed.

Michel

So feeders do not get re-triggered if the entire server gets rebooted and the cube is loaded into memory?

Not if the server you're running is using perstistent feeders. Then the feeders will be loaded from the .feeder files, which effectively will bring back your server to the state before the restart.
A resave of the rules sheet (you need to make a change to the sheet to force a resave - f.i. <Space><Backspace>) will force reevaluation of the feeders.
If you're not using persistent feeders than the server restart should also force reevaluation of the feeders. If this is the case and after the restart the required cell has not been fed than you need to check whether the attribute value points to an existing element name.

Michel

Thanks Michel,

The VPN is down, so it will have to wait till Monday.

Cheers

Update:

Adding the ReevaluateConditionalFeeders or ForceReevaluationOfFeedersForFedCellsOnDataChange, =T in the .cfg causes the Tm1 service to not start.
Adding an empty line in the rules and saving had no effect.
I also tried running a TI process with CubeProcessFeeders(CubeName)

Cell values in the source cube were changed after each test, still no effect.

Any other ideas?

Ash

Ddi you try moving to static over feed like I suggested earlier? Would this be possible? Size of model and impact on performance are the draw backs to this approach.

jim wood wrote:Ddi you try moving to static over feed like I suggested earlier? Would this be possible? Size of model and impact on performance are the draw backs to this approach.

Hi Jim,

Unfortunately this is how they control budgeting, if I remove that conditional feeder, then I would have to manually set and reset security multiple times a day when they are budgeting.

Cheers,

Ash

May be add that manual facility to an excel sheet or something along those lines via an action button and push that back to them?

ashvds wrote:Unfortunately this is how they control budgeting, if I remove that conditional feeder, then I would have to manually set and reset security multiple times a day when they are budgeting.

Whaaaattttt? You are controlling budgeting by choosing to either feed or not feed a leaf element? That makes no sense. What I think you mean is that you are controlling budgeting by updating the T2_Code. That has nothing to do with feeding a rule calculated cell. You don't have to feed based on the value in the T2_Code. As Jim suggested, you can skip the conditional feeder and feed everything as long as you have enough memory. There may be other options but, not knowing anything about your model I don't know what they might be. I think you need to spend some time reading all the documentation you can find about feeders.

Thanks for all the advice guys.
What I meant with controlling the budgeting, is that they essentially use the one cube as a sandbox, and when a budget becomes active, by changing a cell in another cube to 1, that budget is no longer a sandbox, but is fed to the GL cube.
I don't know what this means, but in the end the problem got resolved by exporting the data, zeroing the cube, rebuilding the dimensions, and reloading the data. The cells now feed, but I am still not convinced why they didn't want to feed before!

Cheers,

Ash

Can someone tell me why Applix decided on the terminology "Feeder" to cover the idea of marking calculated cells for the sparse consolidation algorithm? All it does is cause confusion. If I had nickel for every new user that thinks "feeding" is writing an inter-cube reference rule I would have enough money to quit my day job. Why couldn't they have used "Marker", like Palo? It's way more descriptive and wouldn't lead to confusion with writing rules for linking cubes.

Where would the fun be if they made it far to easy? I think it relates to the fact that rules pull, rather than push. A rules pulls the value and the flag is fed so the system knows it's there. I know it still doesn't make complete sense. I guess somebody needs to email Manny...............