TM1 Forum

Hi all,

Struggling to find the answer to my question in amongst all the feeders questions, so i thought i would simply just ask.

Heres my scenario:

20 Profit and loss lines, i need to Feed into my main cube these P&L lines are named Exactly the same, No calculation is necessary just direct fed.

i would like to create a feeder that is an "if" based on an attribute of the P&L called "Feed" so i do not need to list out all 20 P&ls in feeder lines

so it should be something like this..

if P&L:Attribute Feed = Yes then feed else do nothing.

my questions are:
1) Is this possible?
2) What are the impacts for this approach compared to writing direct links?

thanks guys, My last question i asked on here was brilliantly answered so i have no fear someone will help

so i will say Thank you in advance

(",)

I _think_ I know what you are trying to do, which is to feed matching lines.
You're in luck - since rules (and thus feeder rules) work when the elements match, and fail silently when they don't.
So your feeder would look (a bit) like:

['Source element, not a line'] =>
DB(
'Dest Cube',
!Line dimension in _source_,
<rest of dimensions>
);

The lines which match will feed, those which don't won't, no error.
Enjoy.
(Conditional feeding is another, larger issue, which can be very useful, but you don't need it for what you want to do.)

So running by your set out code it should look like this



[dimension, attribute=yes] => DBS( cube and dimensions)

['profit&loss', feedcore=yes] => DBS(core, profit&loss,,,etc)

This will feed all 20 of my p&l lines in my core cube only with the p&ls with attribute feedcore set to yes? Saving from writing 20 feeders I can just use this one line

I'll try and help a bit more.

David's saying you don't need the attribute since TM1 feeders fail silently when they don't match up. So if you don't reference your account dimension on the LHS of the feeder everything should just work.

This can be a little wasteful though as if you acount dimension is large then you would have a lot of feeders failing, it's difficult to determine exactly what the overhead is to a failed feeder but there must be one.

An alternative would be to create a consolidation of the elements you want to be in the feeder and put this in the LHS of the feeder, since a consolidation is shorthand for all the elements underneath it at runtime this will evaluate to all the elements underneath them,

[ 'Consolidation with all the elements' ] => DB ( etc );

Another alternative is to use the subset construct in the left hand side

[{'e1' , 'e2' , ... , 'e20'}] => DB ( etc);

What you want to do is possibly the worst option, i.e. a conditional feeder.

[ ] => DB ( If ( Attrs ('Account' , !account ....)@='Feed' , 'Cube', '') , rest of DB ref);

This is the only way of doing what you want and you are basically forcing the feeder to fail when the attribute is not feed. This is the same as the first option where you just let the feeder fail but you are expending processor cycles forcing the feeder to fail.

HTH

Cheers

Hi thanks for the advise but im really looking to streamline my feeders, i do not want to do the option of feeding all as the main aim for me doing this is to lower my overfeeding and speed up my cube this option is actually the opposite of what i wish to do,

I would like to simply pick 20ish P&ls based on an attribute on the elements called "FeedCore" if there is a yes there then feed if there isnt then dont.

there is a second reson for my wanting to do this approach is becuase i wish to add more P&L lines in the future without the need to add more Rules. making it easier to administrate.

Darkhorse wrote:Hi thanks for the advise but im really looking to streamline my feeders.

So let me get this straight. You're going to streamline your feeders by adding an unnecessary attribute and then write a conditional feeder rule????? Whatever makes you think this is "streamlining"? All you are doing is adding complexity and creating more maintenance to your model.

Darkhorse wrote:i do not want to do the option of feeding all as the main aim for me doing this is to lower my overfeeding

In most intances the only overfeeding you really need to worry about is feeding cells that don't really contain any values, which results in wasted memory. If you just let the natural JOIN of the two dimensions take care of what to feed then this is not overfeeding.

Darkhorse wrote:there is a second resaon for my wanting to do this approach is becuase i wish to add more P&L lines in the future without the need to add more Rules. making it easier to administrate.

Why do you think you need to add more rules in this case? Quite the contrary. Letting the natural JOIN of the two dimensions do the feeding means it is maintenance-free.

Hi Tomok,

Your quite right on most of your points apart from the second one.. i think,

if you read my origional post i actually was asking 2 questions, 1) how do i go about doing this and 2) what are the impacts of doing this.

and maintenance of an atribute is alot easier to to do than re writing more rules avery time i need to add a new link.

i have over 2k P&L lines currently 20 of them are fed but many more to come presumably. i just want to put a yes in the attribute and it auto feed directly to the main cube.

Agreed after studying the "Conditional Feeding" this will cause me a whole load of trouble interms of multithreading setups we currently have on our servers so my aim now will be to create a subset of the P&Ls and feed based on 1-1 mapping of the subset to the main cube.

Tomok apologies for my noobyness to the approach of Tm1 but i have only really been developing TM1 for about 4 months now, i have a relationship database background not a multidimensional knowledge base so its a little confusing on the approach and best practices at the moment hence me asking here

I think the problem we are having here is that you are using the term "feeder" for the wrong thing. A "feeder" in TM1 is a statement that tells the TM1 rule engine where a value is going to exist in a cube so that it is not skipped when performing a consolidation. It doesn't actually move any numbers anywhere or change any values. It is simply a one-bit marker placed in a cell in a cube. You are using the term "feeder" to reference an actual rule statement that is referencing a rules-based value. In the case of moving a balance from one cube to another you have to do three things: 1) create an inter-cube rules statement in the receiving cube that spells out where in the receiving cube the data will go, 2) specify where in the sending cube the data will come from, and 3) write a feeder statement in the sending cube. If both cubes have the same dimensionality then these steps are easy. When they are different it is a little bit trickier but still do-able as long as there is a natural relationship and you have designed the two cubes properly. Most of the time an attribute is not necessary to accomplish this. I doubt it is in your case either but since you have provided almost no details I can't say for sure.

OK....
a Change the attribute content to be the element to which you are feeding (may be the same as the element you are on)
b Write the feeder as: Where there's a link, it'll feed. Where there isn't it won't.
If you read Steve's post you see he says there is a possible performance hit, but not quantified. I suggest you can live with that for easy maintenance, and it'll only be on startup anyway.
When you change the mappings you'll need to refire the feeders, probably by bouncing the server.

Hi guys, getting a little bogged down from my origional questions really but its not about not feeding or OVer feeding,

I have a Dimension with over 2-3 thousand Profit and loss lines i have to feed 20 of these into my main cube

so my line goes something like

[wages]=> [core,etc,etc,etc,etc,"wages")
and so on till all 20 are done,

in my main cube i have a simple code that looks at the attribute of the P&Ls called "Feedcore" and in this attribute is just "Yes" and i have a rule in Core that pulls this data.

['Base']=
if(attrs('P&L',!P&L,'feedcore')@='yes',
DB(notcore, etc,etc,etc, P&L, etc,Month)
,continue)

this pulls the information correctly into the right P&L's (please ignore rule spelling doctored to suit forum)

but i found that using conditional feeding ruins the multi thread startup issue which isnt of any use to me, so i will have to go down the dynamic subset route.

but can anyone help me with a feeder using a subset from a dimension view rather than doing individual P&L lines.


thanks

You're still a little light on details. You talk about a dimension with 2,000 P&L lines. Is this dimension in sending cube, receiving cube, or both. If not in both, how do you map the P&L lines from the sending cube into the proper P&L line in the receiving cube?

Darkhorse wrote:but i found that using conditional feeding ruins the multi thread startup issue which isnt of any use to me, so i will have to go down the dynamic subset route.
but can anyone help me with a feeder using a subset from a dimension view rather than doing individual P&L lines.

You can't feed using a dynamimc subset or actually any kind of subset at all. You COULD create a node in the P&L line dimension that contains as children the lines you want to send over to the receiving cube and possibly use some ELPAR or ELISANC logic to only feed the children. Since I don't know all the details of your design I don't know how to tell you how to do it.

seriously thanks for the help here tomak,

Ok the two cubes are called :
Pay
Core

the dimension:
P&L

is in both cubes

The P&L dimension has an attribute called FeedCore

and in the attribute to the P&L elements they have a "Yes" if they are to be pulled

the P&L dimension consists of 2-3k P&l lines and these are all in hierarchies of there own.


but to be honest the more i get down to grips with what your all saying there is no smarter way really of feeding the p&ls so the link is live. other than hte normal way, Conditional feeding is out due to slowness, and the fact you cant use a subset to feed isnt possible leaves with no other choice than to have to manually add feeders everytime.

Given these facts the best way to accomplish what you want is going to be to create a rollup in the P&L dimension called "FeedBase" and make it a parent of all the lines you want to feed to the Base cube. You can have multiple hierarchies in TM1 so this won't affect anthing you are doing hierarchy-wise. You can use security to hide this node from users if you absolutely don't want them to see it. Then you write a rule in the receiving cube like:

['Base']= if(eliscomp('P&L',!P&L,'FeedBase')=1,DB('NotCore', etc,etc,etc, P&L, etc,Month),continue);

and the feeder statement in the NotCore cube will look like this:

['FeedBase']=> ['Base',etc,etc,etc,etc,'FeedBase');

This works because feeding from or to a consolidated node has the same effect as feeding from or to all the individual children. No "conditional" feeder is needed. All you have to do maintenance-wise is add new lines to the "feedcore" rollup whenever you decide to have more P&L lines go to the Base cube.

Tomok You legend,

Thats what im looking for, (ok its not typing yes in attributes but as we found thats not viable) and this is definatly the best alternative around,

thank you for you help tomok and others,

I dont normally ask questions in here more Schmooz over other peoples questions for answers but both times i have ive been helped by this community, thanks all, hopefully one day i will be able to return the favour---- Give me 10 years