Hi Asgeir,

Please remember that feeders are leaf level only; so only if the names of the leaf-level children of a consolidated element of the dimension in Cube A correspond to the leaf-level elements of the corresponding dimension in Cube B, the feeders will fire correctly. If you make it specific, you basically specify that all leaf-level children of Dim1 element X123 feed element X123 of Dim2 in Cube B. The solution is one of the options below (I suppose you go one level up of that you add a feeder attribute to your elements in Dim1 specifying the element that needs to be fed).

[] => DB('Cube B', ELPAR('Dim1, '!Dim1, 1)); or[] => DB('Cube B', ATTRS('Dim1, '!Dim1, 'Feeder'));

Thank you Luc!

Given that summarizing data in one cube and using it as a leaf in another cube is a very common requirement, I am looking for a generic solution or guidance to address this issue effectively. Could you, or someone at IBM provide a robust approach or best practices for implementing such a scenario?

Hi Asgeir,

Please remember that feeders are leaf level only; so only if the names of the leaf-level children of a consolidated element of the dimension in Cube A correspond to the leaf-level elements of the corresponding dimension in Cube B, the feeders will fire correctly. If you make it specific, you basically specify that all leaf-level children of Dim1 element X123 feed element X123 of Dim2 in Cube B. The solution is one of the options below (I suppose you go one level up of that you add a feeder attribute to your elements in Dim1 specifying the element that needs to be fed).

[] => DB('Cube B', ELPAR('Dim1, '!Dim1, 1)); or[] => DB('Cube B', ATTRS('Dim1, '!Dim1, 'Feeder'));

The generic solution is just as described. When summarizing data and moving data between 2 cubes you should store the source/target information as an attribute (or in another cube if you need more dimensional context). While this can work and scale, there are limits to performance. Which will likely require converting the summarization to a TI. 

For example if you want to summarize data across a location dimension you might do something like this.

#Get Data from Detail cube, using the country dimension to match to consolidations in the city dimension['Summary Amount'] =N: DB('Detail Cube', 'Detail Amount', !Dim2, !Country);#Feeds Leaf Cell to Leaf Cell using attribute on the city to find its country['Detail Amount'] => DB('Summary Cube', 'Summary Amount', !Dim2, ATTRS('City', !City, 'Country'));

Note: You could use a hierarchy reference like ELPAR but that puts a dependency on element indexing which is generally a bad idea.

Thank you Luc!

Given that summarizing data in one cube and using it as a leaf in another cube is a very common requirement, I am looking for a generic solution or guidance to address this issue effectively. Could you, or someone at IBM provide a robust approach or best practices for implementing such a scenario?

Hi Asgeir,

Please remember that feeders are leaf level only; so only if the names of the leaf-level children of a consolidated element of the dimension in Cube A correspond to the leaf-level elements of the corresponding dimension in Cube B, the feeders will fire correctly. If you make it specific, you basically specify that all leaf-level children of Dim1 element X123 feed element X123 of Dim2 in Cube B. The solution is one of the options below (I suppose you go one level up of that you add a feeder attribute to your elements in Dim1 specifying the element that needs to be fed).

[] => DB('Cube B', ELPAR('Dim1, '!Dim1, 1)); or[] => DB('Cube B', ATTRS('Dim1, '!Dim1, 'Feeder'));

Hi Ryan,

asking about your note at the end: You mean it is a bad idea because of hierarchies might change over time but not because it is a performance issue, right?

The generic solution is just as described. When summarizing data and moving data between 2 cubes you should store the source/target information as an attribute (or in another cube if you need more dimensional context). While this can work and scale, there are limits to performance. Which will likely require converting the summarization to a TI. 

For example if you want to summarize data across a location dimension you might do something like this.

#Get Data from Detail cube, using the country dimension to match to consolidations in the city dimension['Summary Amount'] =N: DB('Detail Cube', 'Detail Amount', !Dim2, !Country);#Feeds Leaf Cell to Leaf Cell using attribute on the city to find its country['Detail Amount'] => DB('Summary Cube', 'Summary Amount', !Dim2, ATTRS('City', !City, 'Country'));

Note: You could use a hierarchy reference like ELPAR but that puts a dependency on element indexing which is generally a bad idea.

Thank you Luc!

Given that summarizing data in one cube and using it as a leaf in another cube is a very common requirement, I am looking for a generic solution or guidance to address this issue effectively. Could you, or someone at IBM provide a robust approach or best practices for implementing such a scenario?

Hi Asgeir,

Please remember that feeders are leaf level only; so only if the names of the leaf-level children of a consolidated element of the dimension in Cube A correspond to the leaf-level elements of the corresponding dimension in Cube B, the feeders will fire correctly. If you make it specific, you basically specify that all leaf-level children of Dim1 element X123 feed element X123 of Dim2 in Cube B. The solution is one of the options below (I suppose you go one level up of that you add a feeder attribute to your elements in Dim1 specifying the element that needs to be fed).

[] => DB('Cube B', ELPAR('Dim1, '!Dim1, 1)); or[] => DB('Cube B', ATTRS('Dim1, '!Dim1, 'Feeder'));

Hi Ryan,

asking about your note at the end: You mean it is a bad idea because of hierarchies might change over time but not because it is a performance issue, right?

The generic solution is just as described. When summarizing data and moving data between 2 cubes you should store the source/target information as an attribute (or in another cube if you need more dimensional context). While this can work and scale, there are limits to performance. Which will likely require converting the summarization to a TI. 

For example if you want to summarize data across a location dimension you might do something like this.

#Get Data from Detail cube, using the country dimension to match to consolidations in the city dimension['Summary Amount'] =N: DB('Detail Cube', 'Detail Amount', !Dim2, !Country);#Feeds Leaf Cell to Leaf Cell using attribute on the city to find its country['Detail Amount'] => DB('Summary Cube', 'Summary Amount', !Dim2, ATTRS('City', !City, 'Country'));

Note: You could use a hierarchy reference like ELPAR but that puts a dependency on element indexing which is generally a bad idea.

Thank you Luc!

Given that summarizing data in one cube and using it as a leaf in another cube is a very common requirement, I am looking for a generic solution or guidance to address this issue effectively. Could you, or someone at IBM provide a robust approach or best practices for implementing such a scenario?

Hi Asgeir,

Please remember that feeders are leaf level only; so only if the names of the leaf-level children of a consolidated element of the dimension in Cube A correspond to the leaf-level elements of the corresponding dimension in Cube B, the feeders will fire correctly. If you make it specific, you basically specify that all leaf-level children of Dim1 element X123 feed element X123 of Dim2 in Cube B. The solution is one of the options below (I suppose you go one level up of that you add a feeder attribute to your elements in Dim1 specifying the element that needs to be fed).

[] => DB('Cube B', ELPAR('Dim1, '!Dim1, 1)); or[] => DB('Cube B', ATTRS('Dim1, '!Dim1, 'Feeder'));