Problem with Feeder

[kugors]

Hi All,

I have a problem with feeding cube, after change of string element in another cube.
In first Cube i have three dimension ('LineNumber','Version','FlatMesures'). FlatMesures dimension have two string elements with picklist ({'Account','Project'}) and simple elements for months ({'01','02'...) gather in 'Total' consolidation.
Second Cube have few more dimensions ('LineNumber','Version','Project','Months','Account','SummaryMesure'). SummaryMesure has only one element - Value.
I wrote rule on the Summary Cube:

Code: Select all

SKIPCHECK;
[
  'Summary':'Value'
]
=N:IF(!Project@=
    DB('BF Flat Form',!LineNumber,!Version,'Project')

    &!Account@=
    DB('BF Flat Form',!LineNumber,!Version,'Account')

    ,DB('BF Flat Form',!LineNumber,!Version,!Months)

    ,0
     );

And feeder on Source Cube

Code: Select all

FEEDERS;
['Account']=>['Total'] # one of experiments
[]=>

DB('BF Summary',
	!LineNumber,
	!Version,
	DB('BF Flat Form',!LineNumber,!Version,'Project'),
	!FlatMesures,
	DB('BF Flat Form',!LineNumber,!Version,'Account'),
	'Value'
        );

This works fine when I put a new line in Source Cube. I have a problem when I change Account element in source cube. Values are not fed and Consolidations are not count.

I've seen similiar mechanism on IBM training DB, and it's worked just fine. I'm new into TM1, tried to find solution on this forum\web but i have failed (at least i'have learned how this sparse algoritm works).

Anyone could help?

Regards, Kuba

[Steve Rowe]

Feeders only fire when a number on the LHS of the feeder statement changes. ( I believe from 0/null to populated)
References on the RHS of the feeder statement are fixed at their current value when the rule is saved or the server started.

There is a cfg parameter ReevaluateConditionalFeeders (or close) that _may_ resolve your issue. This can have a significant performance impact so you need to test carefully if it does work. (The reason why I say it may work is that I'm not really clear what TM1 definition of a Conditional Feeder is).

Alternative approachs are.
1. Review your feeder logic, consider feeding all projects and all accounts, this approach is only viable if projects and accounts are small dims. say <100 N levels. Again test for performance impact.
2. Review your feeder logic, find something else that is related but easier to feed from. Probably another measure in your summary cube Your feeder doesn't have to be the logical opposite of your rule.
3. Depending on how Project and account are changed you may be able to capture this event and use a TI process to get the feeders for your source cube reprocessed.
4. Review your design, when source is populated could you somehow use this information to work on summary instead?

HTH
Cheers

[kugors]

I read on this forum when feeders are started:
http://www.tm1forum.com/viewtopic.php?f=3&t=5332#p22576

But on the same topic i read about string feeders, thats fires a feeder always when they change value:

http://www.tm1forum.com/viewtopic.php?f=3&t=5332#p22646

I will check this parameter.

Ad1 - No can do - Account is realy big dimension
Ad2 - Because Account is my biggest dimension I must write feeder for this
Ad3 and 4 - This cubes will be used for budget planing. User will entry data in Flat Form and look how it's affecting globals. It will be hard to explain why this not online data.

Regards
Kuba

[qml]

Czesc Kuba.

This cubes will be used for budget planing. User will entry data in Flat Form and look how it's affecting globals. It will be hard to explain why this not online data.

If you don't want to remodel your whole solution then I think you should consider giving your users a button to click and run a process to kick off feeder reprocessing (provided this happens quickly). You don't have to go into much detail, you can just say it's done for performance reasons. It's really not the worst thing that could happen to them.

[kugors]

Czesc Kamil

I'm trying to do this by rules, because users will only have access by Contributor. As I know (i think that I've read this somewhere) TI procesess can't be launched by contributor. Also I have pressure from my boss to do it that way. I will check this parameter from HTH. Also I will recreate my cubes and dimension's on IBM test DB (there is something almost the same working there) to eliminate environmental issues.

Regards,

Kuba

[qml]

I will check this parameter from HTH.

You mean from Steve? HTH in Internet slang stands for "Hope This/That Helps", "Happy To Help", "Hit The Hay", "How The Hell?", "Heart To Heart", or "Hand To Hand". I'm sure Steve meant one of those.

I'm not sure if the conditional feeder reevaluation parameter will help you (as it tends not to work and not many people know what it actually does), but it's definitely worth trying and reporting back to us!

[David Usherwood]

Picklists were brought in to keep the Cognos Planning users happy. They don't combine that well with rules - you have to have an active feeder to all the possible elements to which the picklist might point. The CP community ran solves, which equate to TIs. Explain to your boss (politely) that what he wants doesn't work well.

[lotsaram]

(Paraphrasing ever so slightly)

Picklists don't combine that well with rules - you have to have an active feeder to all the possible elements to which the picklist might point.

David - what exactly do you mean picklists don't combine well with rules? I don't get it. All that a picklist is doing is applying some basic list validation to cell entry. Any rules that are referring to the cell receiving data entry are not affected one way or the other as to how the data was entered via picklist, manual copy/paste (which will override the picklist validation) or DBSS or CellPutS or whatever. I think the picklist is a red herring, but I'm prepared to be enlightened.

(I think picklists are great BTW. Really useful feature for building models and a great thing to come out of the contributor interface.)

[jim wood]

Wow. I'm going to agree with Lotsaram!!

Picklists are indeed very useful and they also (To back up Lotsarams point) come out very well in EV.

Also to backup lotsrams other point I have used rules on picklists and made them variable depnding on conditions. I did however (and I think this is getting back to David's point) avoid using feeders with them. On the picklist cube (where I did the rules) I left skipcheck and feeder out of there.

[Gregor Koch]

Not sure about the pick lists either. Don't think that should be a real problem.

But generally if you want to read about how ReevaluateConditionalFeeders is supposed to work you need to go back to documentation pre 9.5.0 as the references to it don't exist in anything that has 9.5 in it. Why would that be?
Even if you are on 9.4 or before I would be very surprised if the setting would do anything for you. This is not a hunch because the documentation on it has vanished, trust me I tried and it never worked for me as described in rule guides or the .cfg documentation. If you (or anybody willing to come to Sydney) do get it to work as described I would pay for lunch for two (the second person being me).
Bottom line (for me) is, as mentioned above, changes in the RHS of your Feeder statement won't make it re-fire. The key to get conditional feeders working is to get your condition(s) on the LHS without overfeeding your actual summary cube. It is possible and in due course I will put out a primer on feeders in which you just might find the solution.

[kugors]

I have some other work to do so check on IBM test DB will do later, but i have other interesting observation. I was trying to trace / check feeders, and when I change this string, and select Trace Feeders - they are fed. When I look on the destination cube, and select Check Feeders - the same function with the same parameters are not fed. Strange to me, but as I wrote erlier I'm new to TM1 and maybe I doesn't get something. I will provide more details later this week after few more test.

You mean from Steve? HTH in Internet slang stands for "Hope This/That Helps", "Happy To Help", "Hit The Hay", "How The Hell?", "Heart To Heart", or "Hand To Hand". I'm sure Steve meant one of those.

Didn't know that.

[Steve Rowe]

On the trace feeder comment my understanding is that these results are evaluated at the point in time the request is made, so it is more of a "this is what the system would be like if your ran the feeders now" rather than "this is exactly what the feeders are like"

Check feeders does give the definitive results.
HTH

[Martin Ingram]

Isn't this one a simple case of needing to include a FEEDSTRINGS command in the source cube?

[Steve Rowe]

errrr, maybe if Account is a string which seems likely.....

[Martin Ingram]

[kugors]

Isn't this one a simple case of needing to include a FEEDSTRINGS command in the source cube?

As I understand FEEDSTRING, this command is used when you want fed element that is a string. I want to fire feeder when string element change and feed simple element. Also I tried put FEEDSTRING in rule in source and destination cube. Didn't work.

[Gregor Koch]

Hi
Yes, FEEDSTRINGS is to feed calculated string cells not to allow feeding from string cells. The latter works without this statement.

There was an issue (PM02003) with the FEEDSTRINGS statement which was fixed in 9.5.1. This is about the order of the FEEDSTRINGS; and SKIPCHECK; statements.
Just in case your post was not a typo you'll notice that if you use FEEDSTRING; - without and "S" above SKIPCHECK; you won't get an error on compile. I doubt it would work though.

As for your feeder trace and check. My guess is you have changed your condition after the rule compile and are using the trace after you have changed the condition.
In this case the trace will evaluate on the new condition but, and this is your original problem, this does not mean that the feeder has been fired that way.

[Martin Ingram]

I have a model doing exactly (from my interpretation) what yours is trying to do Kujors.

I need to feed elements in a destination cube based on text inputs (from picklist linked to target dimension) in a source cube. I found that cells were being correctly fed when data was entered in the source cube, but if the selection in the picklist was subsequently changed, the feeders were not being updated to point towards the new target.

When I included the FEEDSTRINGS statement the feeders started working properly. I'm on 9.5.2 FP1 and the FEEDSTRINGS statement was included directly after SKIPCHECK

[Gregor Koch]

Hi
If you have look at the PM, that was exactly the issue in 9.4.1. Although the documentation states to put the FEEDSTRINGS statement before the SKIPCHECK statement it would only work if it was put in the other way around. As far as I can see it this was accepted as a program error and fixed in 9.5.1. Haven't tested which way around it works now, maybe on the weekend.

[kugors]

I have done few more tests.

I read about ReevaluateConditionalFeeders parameter, and i don't think that's my situation, but checked it and it doesn't work.

Changing order of SKIPCHECK and FEEDSTRING also doesn't work. I'm on Cognos Express 9.5 and maybe that's the point.

After looking at IBM example, when I was thinking that is working, I found that they overfed calculations. It has also stop working after I corecct feeder, unload and re-open cube.

I think that is an application error, and I have reported this to IBM. If it is related to Cognos version, maybe they have a hotfix or something.

Thanks you all for help.