Intercube feeders with different level of detail

[simontanguay]

We currently have 2 cubes which are nearly identical with the exception of one dimension. One cube uses a dimension "year_week" and the other use a dimension "month". You can see out it look in this image:




Currently, the cube VENTES_PERIODES is populated using a process with the data from the cube VENTES. This works so far as only the data of the current week needs to be copied. We got a new measure for which this method is appropriate as historical data could be updated. We are considering using a inter-cube feeder for this measure.

We never used intercube feeders so we are hesitant in this approach, beside the fact we don't even know if it could work. In this case, we needs to copy the consolidated data in the cube VENTES (ex: F2016 P12) into the leaf of the same name. The name of the Period (F2016 F12) is also available as an attribute (fp) in the element of the dimension year_week.

Is it something that can be done with intercube feeders? If so, can do we have to rely on the consolidation or the attribute (if both are possible, which is better?).

Our understanding of intercube feeders is next to non-existant so we are simply at the stage of figuring out if it's possible, but a general idea of what the syntax would look like is also welcome.

[tomok]

It's pretty simple. In the cube VENTES_PERIODES put the following rule:

['Name of your measure'] = N:
DB('VENTES',!Produits,!Routes,!Rabais,!client,!BalType,!Version,!banner div,!Months,!Mesures);

Don't forget the feeder which should go in VENTES:

['Name of your measure'] =>
DB('VENTES',!Produits,!Routes,!Rabais,!client,!BalType,!Version,!banner div,!year_week,!Mesures);

[Andy Key]

You don't say at what level you are storing your attribute. But assuming that the value 'F2016 P12' is repeated for each of '2016.48' to '2016.53' then you need to use this attribute in the feeder. Rules are happy to use C level elements as the source of data if the names match, but Feeders only work from the N level. (You can use a C level in a feeder, but this is only a shorthand way of specifying all the N levels underneath it, and it is the N level element names that will be used when trying to match across dimensions.) As this means that you need to feed from '2016.48' etc. to 'F2016 P12' there needs to be some way to link the N level of year_week to the N level of Months, and this is what the attribute will give you.

So, same rule as Tomok suggests for VENTES_PERIODES.
['Name of your measure'] = N:
DB('VENTES',!Produits,!Routes,!Rabais,!client,!BalType,!Version,!banner div,!Months,!Mesures);

But for the feeder, in VENTES:
['Name of your measure'] =>
DB('VENTES_PERIODES',!Produits,!Routes,!Rabais,!client,!BalType,!Version,!banner div,AttrS( 'year_week',!year_week,'fp'),!Mesures);

You could use ElPar in the feeder, but if you have multiple hierarchies in your dimension you can't guarantee which hierarchy ElPar is going to be looking at.

[simontanguay]

You don't say at what level you are storing your attribute. But assuming that the value 'F2016 P12' is repeated for each of '2016.48' to '2016.53' then you need to use this attribute in the feeder. Rules are happy to use C level elements as the source of data if the names match, but Feeders only work from the N level. (You can use a C level in a feeder, but this is only a shorthand way of specifying all the N levels underneath it, and it is the N level element names that will be used when trying to match across dimensions.) As this means that you need to feed from '2016.48' etc. to 'F2016 P12' there needs to be some way to link the N level of year_week to the N level of Months, and this is what the attribute will give you.

So, same rule as Tomok suggests for VENTES_PERIODES.
['Name of your measure'] = N:
DB('VENTES',!Produits,!Routes,!Rabais,!client,!BalType,!Version,!banner div,!Months,!Mesures);

But for the feeder, in VENTES:
['Name of your measure'] =>
DB('VENTES_PERIODES',!Produits,!Routes,!Rabais,!client,!BalType,!Version,!banner div,AttrS( 'year_week',!year_week,'fp'),!Mesures);

You could use ElPar in the feeder, but if you have multiple hierarchies in your dimension you can't guarantee which hierarchy ElPar is going to be looking at.

Thanks to both of you!

I tried this syntax and it worked right away. It allowed me to figure out some basic principles behind inter cube feeding. My code as it stand right now look like this:

VENTES_PERIODES (destination):
['BB$'] = N:DB('VENTES',!Produits,!Routes,!Rabais,!client,'Bkd', 'Réel',!banner_div,!Months,'BB$');
['BB$ Deb'] = N:DB('VENTES',!Produits,!Routes,!Rabais,!client,'Bkd', 'Réel',!banner_div,!Months,'BB$ Deb');
['BB$ Calc'] = N:DB('VENTES',!Produits,!Routes,!Rabais,!client,'Bkd', 'Réel',!banner_div,!Months,'BB$ Calc');

VENTES (SOURCE):
FEEDERS;
['BB$'] => DB('VENTES_PERIODES',!Produits,!Routes,!Rabais,!client,'Bkd', 'Réel',!banner_div,AttrS( 'year_week',!year_week,'fp'),'BB$');
['BB$ Deb'] => DB('VENTES_PERIODES',!Produits,!Routes,!Rabais,!client,'Bkd', 'Réel',!banner_div,AttrS( 'year_week',!year_week,'fp'),'BB$ Deb');
['BB$ Calc'] => DB('VENTES_PERIODES',!Produits,!Routes,!Rabais,!client,'Bkd', 'Réel',!banner_div,AttrS( 'year_week',!year_week,'fp'),'BB$ Calc');


We are not feeding all elements so I put some restriction ('Bkd', 'Réel'). I replaced !Measures by the name of the measure being feed, but it seems unnecessary. As I understand it, it take the context of the destination if we leave !Measure. It just seems more intuitive that way. What is the best practice?