Intercube Feeder causing Server crash

[ExApplix]

I am trying to write a Intercube Feeder and it is causing the Server crash - server RAM goes from 2Gb to 30Gb and then it crashes. I think that I am missing something but not sure what it is. My Source cube and Traget cubes have got some dissimilar dimensions.

Rule in the Target cube looks like:

Code: Select all

['Percent'] = N: DB('Souce_Cube', 'Total Department', 'Total Account', 'Total Position', !Scenario, !Period, !Employee, 'FTE') * 100;

Feeder in the Source cube is:

Code: Select all

['Total Department', 'Total Account', 'Total Position', 'FTE'] => DB('Target_Cube', !Position, 'Total Union', 'Total Grade', 'Total Job', !Period, !Scenario, !Employee, 'Percent');

Can someone please tell me what I am missing here?

[Martin Ryan]

Wow that's a big feeder!

As discussed in various posts using a consolidation is a shorthand for writing out potentially hundreds of feeders. When you say "total Department" feeds to "Total Account" and there are 100 departments and 100 accounts you have just created 10,000 feeders.

Using consolidations on either side of the feeder should be limited as much as possible. I suspect you don't actually need it on the left hand side of your feeder at all.

Martin

[Steve Rowe]

Just to expand on what Martin was saying, it'sthe consolidations on the right hand side of the feeders that will be causing the memory to spike in the target cube. The product of the N levels below these consolidations 'Total Union', 'Total Grade', 'Total Job' will be fed for every number on the left of the feeder. 2GB to 30GB still seems a lot though, one of those consolidations would have to be very big and you'd need a lot of data too.

Don't forget you don't have to feed with the FTE number, if you have some other number in the Target Cube that is populated whenever you want Percent populated then you can feed with that. Since that measure if is already in the Target cube the dimesionality will bethe same so the feeder will be more natural.

HTH.

Cheersm

[ExApplix]

Thanks guys for your time but I am still scratching my head to understand this (sorry). I change the Feeder as follows but still its causing the same memory issue:

Code: Select all

['FTE'] => DB('Target_Cube', !Position, 'Total Union', 'Total Grade', 'Total Job', !Period, !Scenario, !Employee, 'Percent');

Size of Target cube is: 3100 Employees, 1450 Position, 650 Job, 350 Grade, 322 Period, 150 Scenario, 81 Measures (String & Number)
Size of Source cube is: 36500 Account, 3100 Employees, 1450 Position, 322 Period, 150 Scenario, 30 Department, 11 Measures (String and Number)

The source cube does not have the Union, Job and Grade dimensions, that is why I have to use use the Total (Consolidations level) in my feeder. Is there any other way of doing that?

Percent in the Target cube is being used by some other calculations. I have got 50+ rules in the Target cube. If I can grab the missing concept I should be able to write the remaining Feeders.

Please help me in fixing this feeder. Code example will be much appreciated.

[David Usherwood]

It would be worth posting the rules which use the FTE value &/or describing the business problem you are trying to solve. Remember, you don't need to feed a value to use it in a rule - and you don't need to feed all references on the right hand side of a rule.

[lotsaram]

As has been explained to you already, you are still feeding total union, total job and total grade. You don't need to do this nor should you.

If you don't already have attributes in your employee dimension for union, job, grade, department, position, etc. etc. then CREATE THEM as these dimensions are basically dependant attributes of employee as there is (or will normally be) a 1:1 relationship at employee level. If these attributes can change over time then simply hold the values in a lookup cube rather than simple attribute.

Then in the feeder simply nest in an AttrS or DB statement into the main DB inorder to only feed the appropriate point on each dependent dimension for each employee.

I don't think it can be put any more simply than that!

[ExApplix]

As has been explained to you already, you are still feeding total union, total job and total grade. You don't need to do this nor should you.

If you don't already have attributes in your employee dimension for union, job, grade, department, position, etc. etc. then CREATE THEM as these dimensions are basically dependant attributes of employee as there is (or will normally be) a 1:1 relationship at employee level. If these attributes can change over time then simply hold the values in a lookup cube rather than simple attribute.

I also thought about using the Attributes but union, job, grade, department, position are based on user inputs and do not have 1:1 relationship e.g one employee could be forcasted/allocated to different departments.

How can I replace the total union, total job and total grade? Shall I hardcode the N level elements name in these dimensions? If yes, then how it will work. For example I have 650 Jobs - do I have to hardcode all of them but that would be same as using the Total jobs.

It would be worth posting the rules which use the FTE value &/or describing the business problem you are trying to solve. Remember, you don't need to feed a value to use it in a rule - and you don't need to feed all references on the right hand side of a rule.

I have posted my Rule and the Feeder in the first post. I have also disabled all the other rules but all in vain.

Its midnight at my end and I know I am missing some little concept here, so guys please bear with me. Thanks in advance.

[David Usherwood]

Not exactly - you posted the rule _for_ FTE. My challenge is to what you are doing with the FTE in the destination cube - do you need to feed it?

[ExApplix]

Not exactly - you posted the rule _for_ FTE. My challenge is to what you are doing with the FTE in the destination cube - do you need to feed it?

Hi David, As mentioned before I have disabled all the other Rules so the only Rule in the Target cube is:

Code: Select all

['Percent'] = N: DB('Souce_Cube', 'Total Department', 'Total Account', 'Total Position', !Scenario, !Period, !Employee, 'FTE') * 100;

and Feeder in the source cube is:

Code: Select all

['FTE'] => DB('Target_Cube', !Position, 'Total Union', 'Total Grade', 'Total Job', !Period, !Scenario, !Employee, 'Percent');

When I hardcode the Union, Grade and Job as follows it works:

Code: Select all

['FTE'] => DB('Target_Cube', !Position, '01', '05', '123', !Period, !Scenario, !Employee, 'Percent');

but I want this Feeder to work for all the elements in Union, Grade and Job dimensions.

Any help will be highly appreciated.

[David Usherwood]

You_haven't_set_out_the_business_reason_for_feeding_the_value.
Can someone else help me out here?

[lotsaram]

You_haven't_set_out_the_business_reason_for_feeding_the_value.
Can someone else help me out here?

You can only lead a horse to water ...

[Alan Kirk]

You_haven't_set_out_the_business_reason_for_feeding_the_value.
Can someone else help me out here?

If they feed it they can claim a tax deduction for the benevolent relief of starving calculations.

Kinda like donating the leftover food from the staff cafeteria to the local soup kitchen.

Hmmm, possibly not the answer you were after.

I'll get my coat...

[Goatship]

Dear Steve Rowe,

You mean the essence of feeders is to tell if this number exist in the feeding cell, go check the rule of the fed cell.

For example;

A =>B

means
if A = 0, then skip rule checking of B. If A <>0, go perform rules of B

Therefore we can ignore how the rules are written in writing feeders. Is this correct?
If true this would be a lot of help in case the rules are very complex.

Thanks a lot.

[lotsaram]

Dear Steve Rowe,

You mean the essence of feeders is to tell if this number exist in the feeding cell, go check the rule of the fed cell.

For example;

A =>B

means
if A = 0, then skip rule checking of B. If A <>0, go perform rules of B

Therefore we can ignore how the rules are written in writing feeders. Is this correct?
If true this would be a lot of help in case the rules are very complex.

Thanks a lot.

NO.
But you are on the right track sort of. The purpose of the feeder is to tell the consolidation engine which values to aggregate. If you happen to query a specific cell (or a number of cells in a view array) then the calculation engine will still evaluate the indivdual value in each rule defined cell correctly. It is just that without feeders these values will not aggregate whihc leads to incorrect results at higher levels of the hierarchy.

It is true that the feeder does not have to reflect the rule (it is just that most of the time it does.)