Can this be an alternative to conditional feeders?

[krishnadixit]

Hi All,

I was working on optimizing rules and feeders and thought of this:
Scenario - flowing the data from one cube to another.
Condition - the data of only those versions that are under rollup 'Active Versions' has to be flown.
Possibility - there can be more than 1 version under 'Active Versions' but possibly only 1 version has data in it and remaining have zero data.

Following are two cubes:
test_MasterCube ---> data --> to test_ReportingCube.


I created another cube Feede_Version (actually I misspelled it, wanted to name it Feed_Version). I provide the name of only that version that I want to feed.

Feeders in test_MasterCube:-

Code: Select all

[ 'Amount'] =>
 DB('test_ReportingCube',
      DB('Feede_Version',!Version,'Feed_Version')
  ,!Fiscal_Year,!Period,!plan_chart_of_accounts,'Amount') ;

Is this concept correct? Will this work efficiently? Is this an option to conditional feeder where only those version(s) will be fed that are provided in 'Feede_Version' cube, or its same as conditional feeder and feeders wont be triggered if the value changes.

Or is there any more efficient way to address this.

Thanks
KD

[lotsaram]

Hi Krishna,

At least in my definition you don't need an IF statement embedded within a DB on the right hand side of a feeder to be a conditional feeder and your example is a conditional feeder in my books. I would always do conditional feeders this way with either a DB or AttrS function to encode an element name. If the function returns empty or any string not equal to a valid element name then the feeder will fail and thus be conditional. It is a much better way to do it than IF with hardcoded strings.

But as with all numeric feeders the trigger condition is encoded on the left hand side when the value changes from null for the 1st time. Once the feeding process has been set off from the cell then the powder is done so to speak. If in your example the value stored in DB('Feede_Version',!Version,'Feed_Version') changes then this will not result in the correct cells being fed. This will only happen if CubeProcessFeeders is run on cube test_MasterCube or the server is restarted with feeder files removed.

[paulsimon]

Hi

I am not sure that I understand your situation but if you only want to feed from Cube A to Cube B for the Active Versions then the easiest way to do that is to have a consolidation called Active Versions on the left hand side of the feeder

['Active Versions','Amount'] => ...

There is no need for a conditional feeder on the Right hand side.

Putting a consolidation on the left hand side effectively means feed from all elements below it. If one of the versions has no data then there will be no feeder from it.

Regards

Paul Simon

[qml]

Putting a consolidation on the left hand side effectively means feed from all elements below it. If one of the versions has no data then there will be no feeder from it.

Very true and a valid technique. However, especially in the context of what the OP is asking about, it needs to be said that adding a new component under the 'Active Versions' consolidation will by itself not trigger the feeder statement's execution. Which means that, just like with conditional feeders (both the ones containing an IF statement and the ones using dynamic references), there needs to be a procedural step for reprocessing the feeders added somewhere.

[krishnadixit]

the easiest way to do that is to have a consolidation called Active Versions on the left hand side of the feeder

['Active Versions','Amount'] => ...

@paulsimon - Currently I am doing the same, however, if there are more than lets say 5-6 versions under 'Active Versions' and we want a quick solution of turning of feeders for all versions but one. Just use feed_version cube, make an entry, run a processfeeders TI process and done. This is what I think. Later on, if people decide to apply rules for one more version follow same steps.
I am trying to bridge business user's crude requirement, they need quick solutions, impatient to wait on change request, at the same time, tm1 admin need to work on limited server resources and has to deal with performance of the model.

You know what I mean