Rule Feeder weirdness

[7Zark7]

Hi All,

I have a feeder which will only work when I go into the rule and say enter a "space" or hit the enter button somewhere in the rule,
to i guess emulate that i have made a change to the rule. When I then go to the save the rule, it then feeds the cells i want to feed.

Is there an explanation for this sort of behaviour? I know the cells are feeding since the values are naturally consolidating to a total i expect.

Can anyone kindly shed some light on this?

Cheers

Zark

[rmackenzie]

Yes, the behaviour of the advanced rule editor is only re-compile the rules (and feeders) when you make a change. Your question is a bit ambiguous as it is not clear when your feeder isn't working. Or rather, the question should be, when do you suspect it stops working; you mention it does work when you manually force the rules to re-compile (by inserting the space and re-saving). It's always a good idea to provide a sample of the code. Also, so others can have a chance of providing a meaningful suggestion, could you provide a bit of context into the type of calculation you are trying ensure consolidates properly.

[7Zark7]

Hi There,

Yes, it does work when I manually force the rules to re-compile (by inserting the space and re-saving). Basically, trying to pull a "Anticipated Sales ($m)"
values across from the "Forecast Assumptions" cube ( which works, i can see the values populating in my view with zero suppression off). But the feeder from the
"Forecast Assumptions" cube will not feed the calculated cells, unless i open up the "Forecast Assumptions" rule file insert a space and then re-save the rule. At the point the cells are then feed and my consolidated value calculates.

I am using TM1 9.5 Cognos Express.

Kind of lost here, behaviour seems really weird. I have no idea what to do next.... Is this a bug???

Simple Rule per Below:

# Calculation #
['Orders' ] = N:
DB('Assumption Forecast', !Currency,
!Period,
!Version, !Location, 'Business Unit', 'No Activity Code', 'Anticipated Sales ($m)')*1000;


# Feeders from "Assumption Forecast"cube #
['Anticipated Sales ($m)']
=>DB('Orders', !Currency,!Period, !Version, !Location, 'No Channel', 'No Segment', 'No Activity Code', 'No Customer', 'Orders');

[rmackenzie]

Your rule and feeder seem OK (you're mixing up Forecast Assumptions and Assumption Forecast in your post, but I guess they're the same thing) and they are working for you, at some point. However, what I'm not clear on is the order of events. Are you saying this happens:

1. Boot up the server
2. Open the cube view with the 'Orders' measure and notice the values don't consolidate
3. Open the rule file for Assumption Forecast, insert a space, save the file thereby re-compiling the rule
4. Re-fresh the view from step (2) and observe that the values are now consolidating

If 'stuff happens' between steps (1) and (2) then obviously there's more to the story than meets the eye... For example, it may be that your Assumption Forecast rule didn't compile when the server started (missing element perhaps?) but after you ran some TIs during the day (inserting the missing element perhaps?) then when you got round to re-saving/ re-compiling the Assumption Forecast it no longer generated an error meaning that your 'Orders' measure consolidated properly... you can check tm1server.log to see if this, or something like it, may be the case.

If nothing happens between (1) and (2) then this would be quite weird and I would be stripping down both the Assumption Forecast rule and the entire data model so I could bounce the server a few times to see why the rule wasn't working in the first place.

[7Zark7]

Thanks Mate. You must be a mind reader ,steps 1 to 4 are correct. Unfortunately nothing happens between 1 and 2.........
The crazy thing is, is the numbers are coming through but are not being fed until i execute step 3..... darn it!

I have deleted the rule and then recompiled it with the same behaviour taking place. Any other ideas?????

Cheers

Zark

[rmackenzie]

I would strip down the Assumption Forecast rule file to contain only SKIPCHECK, FEEDERS and the feeder statement in question. Then I would reboot and check tm1server.log to see what is happening when it loads the Assumption Forecast rule. If they are loading without error then there should hopefully (this is CX so not entirely sure) be a line like:

Code: Select all

77928   INFO   2012-03-19 00:51:25.176   TM1.Server   TM1CubeImpl::ProcessFeeders: Done computing feeders for base cube 'Assumption Forecast'.

In the cube with the Orders measure, remove all the lines apart from SKIPCHECK, FEEDERS and the rule in question and check to see if the problem still exists.

<edit> do all the rule-stripping-down, in both cubes, before the re-boot - to be sure they aren't other rules/ feeders clouding the waters.</edit>

[7Zark7]

Hi There,

I have completely stripped out all the rules except the ones in question there is what i have found:

This is what i can find in relation to the cube i am interested in: The only line that appears different and is unique is the last line "TM1.Cube.Dependency"
Have not seen that one before. But based on what is coming through all appears ok..... also the same strange behaviour still remains in getting the cells to feed,
i need to go into the rule and enter a space then save the rule for the cells to feed.


4408 INFO 2012-03-22 05:48:23.190 TM1.Server TM1CubeImpl::ProcessFeeders: Computing feeders for base cube 'Assumption Forecast'.
4408 INFO 2012-03-22 05:48:23.190 TM1.Server TM1CubeImpl::ProcessFeeders: Done computing feeders for base cube 'Assumption Forecast'.
4408 INFO 2012-03-22 05:48:23.190 TM1.Cube Done loading cube Assumption Forecast

4408 INFO 2012-03-22 05:48:34.972 TM1.Server TM1CubeImpl::ProcessFeeders: Computing feeders for base cube 'Orders'.
4408 INFO 2012-03-22 05:48:34.972 TM1.Server TM1CubeImpl::ProcessFeeders: Done computing feeders for base cube 'Orders'.
4408 INFO 2012-03-22 05:48:34.972 TM1.Cube Done loading cube Orders

1584 INFO 2012-03-22 05:48:45.643 TM1.Cube.Dependency Adding cube dependency: cube "Orders" depends on cube "Assumption Forecast"

[rmackenzie]

Yes, this is puzzling. Perhaps your tm1s.cfg file is set to use persistent feeders, but your .feeders file does not contain the relevant feeder data to feed the Orders cube, until you physically re-save the Assumption Forecast cube rule?

[7Zark7]

Yes, its really bizzarre. I am tempted to blow up the cube completely and then reload the data and re-attach the rule ( maybe there is something in the back end that is out of whack).Pretty strange, that in order for it to feed I must go into the rule myself and hit the space bar for it to emulate a rule save.

I'm out of ideas. Thanks for your help.

[7Zark7]

Noticed the last line 'Adding cube dependency" How does this get added? Is this something that is enabled by default? This may be what is causing me greif. Is there a way to get rid of this ( if this is indeed the conflict???????????)

Cheers

Zark

[lotsaram]

Noticed the last line 'Adding cube dependency" How does this get added? Is this something that is enabled by default? This may be what is causing me greif. Is there a way to get rid of this ( if this is indeed the conflict???????????)

Cheers

Zark

No. Adding cube dependency is not causing you any grief. This is just the server registering that because the Assumption Forecast cube feeds the Orders cube that therefore the Orders cube is dependent on the Assumption Forecast cube. In this case all the cube dependency does is prevent locking in other cubes while a view in the Orders cube is being calculated.

[Steve Rowe]

Just noticed that you have put "Simple Rule" before you list the rules.

Is this the exact rule that you are having an issue with or is the issue with some more complex version of the rules?

Is 'Anticipated Sales ($m)' a ruled value or an input? If it ruled can you give the rule and feeder for that too?

[7Zark7]

Hi Steve,

The values are inputted and not rule driven......its a table with some data in it and nothing more. It does not make any sense. Going to rebuild it in a seperate TM1 environment on a seperate TM1 instance to see what happens, with the 2 cubes in question to see whether I can isolate what it could be. Really cannot think of anything else that will fix the issue. The only thing i can do to get it working is to pull the assumption data into the order cube and perform the caluculations within the orders cube as a work around...........

[7Zark7]

Hi Guys,

Noticed something strange. The cube rules donot get evaluated on bootup. When i viewed the log the last 3 lines were missing. When I then went into the rule and triggered the feeder it then added the last 3 lines below when i looked in the log file after i had triggered the event. The server for some reason is ignoring the rules on these 2 cubes on boot up of the server. What could be preventing the rules to be read during bootup of the tm1 server??

2496 INFO 2012-03-23 04:17:46.929 TM1.Server TM1 Server is ready
2496 INFO 2012-03-23 04:17:46.929 TM1.Server Notifying the Admin server
5044 INFO 2012-03-23 04:19:16.137 TM1.Server TM1CubeImpl::ProcessFeeders: Computing feeders for base cube 'Assumption Forecast'.
5044 INFO 2012-03-23 04:19:16.137 TM1.Cube.Dependency Adding cube dependency: cube "Orders" depends on cube "Assumption Forecast"
5044 INFO 2012-03-23 04:19:16.137 TM1.Server TM1CubeImpl::ProcessFeeders: Done computing feeders for base cube 'Assumption Forecast'.

Thanks again lads ( hoping for some more insight). As you can see this is clearly bugging me ( no pun intended )

Zark

[Michel Zijlema]

Yes, this is puzzling. Perhaps your tm1s.cfg file is set to use persistent feeders, but your .feeders file does not contain the relevant feeder data to feed the Orders cube, until you physically re-save the Assumption Forecast cube rule?

Hi Zark,

Did you check your tm1s.cfg file as in the question above? Is your server setup to use persistent feeders?

Michel

[7Zark7]

Ok got it working. Firstly thanks to rmackenzie for helping work through my issue, the TM1cfg file gave me the clue as to what was going wrong.
TM1.Cube.Dependency was the key to me figuring out what was going on. I had a period slider rule in an attribute cube that was giving me grief.
The forecast assumption cube was depending on my period attribute cube to for this piece of information to derive a value. Because of this error, it esssentially
killed my feeder.

Within my period dimension my period slider rule would work out the a dynamic period string, but it was also conflicting with existing elements within
TM1 i.e( elements :'m+1'='may 2012' but also 'may 2012' = 'may 2012' [RHS being the attribute value] ). So in essence i had 2 attribute values that
were the same ( the conflict). So after deleting the rule it all worked. Interestingly i was able to set the attribute value, but by creating a period_slider dimension in
another dimension and reference it externally via a rule and then it worked.

Cheers
Zark

[tomok]

Ok got it working. Firstly thanks to rmackenzie for helping work through my issue, the TM1cfg file gave me the clue as to what was going wrong.
TM1.Cube.Dependency was the key to me figuring out what was going on. I had a period slider rule in an attribute cube that was giving me grief.
The forecast assumption cube was depending on my period attribute cube to for this piece of information to derive a value. Because of this error, it esssentially
killed my feeder.

FYI, you should avoid setting string attribute values via a rule, especially if those attributes are used in another cube rule. This is because those string values are not cached. So, every time your cube rule fires, the attribute rule has to re-evaluated. If you don't believe me, test it yourself by opening and calculating a view in the affected cube. Do it several times and time. Now, hard-code the attributes in question and re-time.

[7Zark7]

Thanks for that Tomok, didn't realise that was the case. Only issue here is that a TI process would have to be executed everytime the global month parameter is changed to rebuild the
attributes values. Cheers mate.