Data not Fed

[sfnicole]

Hi all,
I have a problem to feed the data from one cube to another cube which have similar structure but different dimension name. The following is the example:-
Cube A
Dimension Year
Dimension Period
Dimension Dept
Dimension COA
Dimension Measures

Cube B
Dimension Year
Dimension Period
Dimension Dept
Dimension Flat Structure of COA (don't have hierarchy, all are N level even it is C level in COA)
Dimension Measures

In Cube A rule - feeders:
['2011', 'Input']=>DB('Cube B', !Year, !Period, !Dept, !Flat Structure of COA, !Measures);

In Cube B rule:
['2011', 'Input'] = N:DB('Cube A', !Year, !Period, !Dept, !COA, !Measures);


Cube B rule is able to pull the data from Cube A but the value is not fed.

I have tried to create an attribute to store the COA code and use the following method to retrieve data:-
In Cube A rule - feeders:
['2011', 'Input']=>DB('Cube B', !Year, !Period, !Dept, Attrs('COA', !Flat Structure of COA, 'COA_Text'), !Measures);

In Cube B rule:
['2011', 'Input'] = N:DB('Cube A', !Year, !Period, !Dept, !COA, !Measures);

The data is still not fed.

Do you have any solution for it?

Thanks & Regards,
Nicole

[mattgoff]

Your ATTRS in the Cube A feeder should be:

Code: Select all

['2011', 'Input']=>DB('Cube B', !Year, !Period, !Dept, Attrs('COA', !COA, 'COA_Text'), !Measures);

BTW, is there a reason why you have two cubes with the same data and more or less the same dimensions? I think by creating two cubes plus an attribute to manage copying data that you've created a management nightmare for yourself. Also, why are you feeding from Cube B to Cube A? Is there a rule copying data from Cube B to Cube A? It might be worth a rereading the docs on feeders to improve your understanding of their purpose; there's a good chance that feeder doesn't need to be there but is decreasing your performance. You may as well learn it now before you write a bunch of them.

Matt

[mattgoff]

Actually, if the element names are exactly the same between COA and Flat Structure of COA, you could just do:

Code: Select all

['2011', 'Input']=>DB('Cube B', !Year, !Period, !Dept, !COA, !Measures);

Matt

[sfnicole]

Hi Matt,
The purpose of having two cubes that having simillar structure is due to the nature of business logic. The cube with the flat structure of COA (Cube B) is to accommodate for consolidation reporting, and this will have actual figures that loaded from the other system. While Cube A, is for them to do the inputting of Budget and Forecast. Ultimately, those figures also need to flow to Cube B, for consolidation.

I think the given example is a bit misleading. Please refer to below on the sample:-
Cube A
Dimension Version
Dimension Year
Dimension Period
Dimension Dept
Dimension COA
Dimension Measures

Cube B
Dimension Version
Dimension Year
Dimension Period
Dimension Dept-Flat Structure
Dimension COA
Dimension Measures

If I'm doing this way, the data is not fed.
Cube A - feeders
['Budget', '2011', 'Input'] => DB('Cube B', !Version, !Year, !Period, !Dept, !COA, !Measures);

Cube B - Rules
['Budget', '2011', 'Input'] =N: DB('Cube A', !Version, !Year, !Period, !Dept-Flat Structure, !COA, !Measures);

[mattgoff]

It's still not clear to me why you need two cubes. It's pretty common to have budget, forecast, and actuals in the same cube. In fact, it's advantageous to do so. Plus you avoid maintaining two nearly identical dimensions (the only way not to get burned is to have this automated with TI, BTW).

Based on your revised cube structure and the rules/feeders you give, it should work assuming that your "Dept" and "Dept-Flat Structure" element names are identical for the elements you want to copy/feed. Is there a particular reason you're not just posting the actual rules? Typos in feeders often fail silently.

Matt

[sfnicole]

Hi Matt,
Having two cubes are not my choice and it was done by consultant and again, this is the nature of business logic, Which probably you might not have such experience before.

The rule and feeders that I posted, YES, it is working perfectly for N level in Cube A to N level in Cube B. But, it doesn't fed correctly for C level in Cube A to N level in Cube B.

[tomok]

The rule and feeders that I posted, YES, it is working perfectly for N level in Cube A to N level in Cube B. But, it doesn't fed correctly for C level in Cube A to N level in Cube B.

The plot thickens. Now, it sounds like you have C level elements in Dept that coincide with N level elements in Dept-Flat Structure, not just a one-to-one relationship between the N level elements in the two dimensions AND you are expecting to be able to feed from all elements in Dept and for that to take care of Dept-Flat Structure. The problem here is that feeding from C level elements and N level elements do two very different things. Feeding from one N level element to another does exactly what you would expect it to do. However, feeding from a C level element does not just look at the consolidated value of the C and then feed to the N if there is a value, instead it is the same thing as writing a separate feeder statement feeding with ALL THE CHILDREN of the C. If the N level elements of the C you are trying to feed from in Cube A do not match the N level elements in Cube B then it won't work. The N to N feeders will work and the C to N feeders won't.

[jim wood]

The other thing to consider when feeding from a consolidation is that some of the children themselves may be fed. I've always avoided this.

[Terramup]

Would adding this work?

Cube B - Rules
['Budget', '2011', 'Input'] => DB('Cube B', !Version, !Year, !Period, ElComp('Dept', !Dept-Flat Structure, 1), !COA, !Measures);

This would cause the already fed values in Cube B to feed their parents.

[Gregor Koch]

On the discussion about the necessity of the two dimensions:
Although I think that it sometimes can be valid to have mirror dimensions where one only has N Level elements, reasons like, 1. a consultant has done it (not a good reason), 2. this is the nature of the business logic (this doesn't answer mattgoff's question), 3. probably you might not have such experience before (I find this a bit rude in light of that you are asking for assistance and might have way less experience), are just not good enough.
So I actually thought about answering this twice, the other option being leaving you on your own to solve the issue with the given information. Which you could if you have the experience and maybe you have already.

Any ways, here it is. I think you won't get around writing two feeders for this.
One to feed from the N levels in 'Dept' dimension to the N levels in the 'Dept Flat Structure' dimension and one to feed from the 'C Level' (meaning their respective N Level elements as tomok explained) to the, yet again, N Level elements in the 'Dept Flat Structure' dimension (which represent the C levels from the 'Dept' dim).

Although it would work, personally I wouldn't opt for the solution using the Elcomp function as the index of a parent can change when you add more parents to an element, making an attribute that stores the parent the saver option.

The two feeders you need could look something like this:
['Budget', '2011', 'Input'] => DB('Cube B', !Version, !Year, !Period, !Dept, !COA, !Measures);
['Budget', '2011', 'Input'] => DB('Cube B', !Version, !Year, !Period, ATTRS('Dept',!Dept, 'Parenttofeed' ), !COA, !Measures);

Cheers