How do you feed rules with what if statements, since i'm using what if to check the attribute of the cube against the source cube with the same # of dimension only different level.
Its kinda frustrating since I tried everything even Feedstring though I know its morely if the output to appear is a string value. I can't go for taking out the Skipcheck cause the cube is kinda heavy.
Move the test inside the DB reference so it returns the cube name if true and nothing if false. This is the standard way to do conditional feeders.
I've taken your code snippet and butchered it to show this below, but of course you posted the rule not the feeder so it will need changing.
['# of Spindle'] => DB('PRODUCTION_capacity', 'TOTAL YEARS', !base_years, 'TOTAL PRODUCTS', !base_machines, '# of Spindle');
I'm just about to try out you gave to adjust the rules but if adjusted my rules to the format you gave me...would the feeder I created on the ASSUMPTION cube would work?
However, would there any performance difference with the rule format you gave me since so far with the one I got, I'm happy with the performance, its just the values I'm getting from the assumption isn't appearing on the PRODUCTION cube when I suppressed it just to see the rows with values including those assumptions.
['# of Spindle'] => DB(
IF (
ATTRS('base_months_dates', !base_months_dates, 'months')@='December',
'ASSUMPTION_machine_capacity',
#else
''),
ATTRS('base_machines_mc', !base_machines_mc, 'WorkCenter'),
'December', !base_years, '# of Spindle');
You'll need to adjust the feeder you have to work that way. If it's in another cube you need to do it there.
Your present feeder isn't working since the values disappear when you zero suppress.
You need to be carefull with this as I believe it is not going to work as you imagine.
I.e. your feeders will NOT automatically adjust when the value for ATTRS('base_months_dates', !base_months_dates, 'months') changes.
I.e. if it was on november on server start up => no feeders set
When you change the attribute to December (and thus the feeders should be triggered) they will not. Only feeders starting from the attribute cube will be 'reset' in this case.
=> Either use a normal feeder and live with the unwanted feeding
=> Or restart the service / reprocess the feeders whenever the attribute value changes.
=> Or find something else that you can use as a feeder.
Jeroen, this is standard with conditional feeders. Generally I recommend a restart to refire them.
With the new 9.5.1 persistent feeders, if you turn off a block of fed data, you need to delete the .feeders file(s) and let the server rebuild them. It is a new feature, but my experience with it at present is that unless you delete _all_ the .feeders files you don't seem to get the memory benefit. Like to hear how others have found this feature of 9.5.1 .
Thanks guys for your opinions. I guess I'll just have to settle with using TI to transfer the data, however I'm stuck in a dilemma cause I'm try to just create a staging cube just to protect it from any changes .
But how do I define the source cube's specific dimension "base_months_dates" (e.g. Feb-01, Feb-02, etc...) attribute to match my cube source with the "base_months" dimension (e.g. Jan, Feb, etc...)
I just wanted to mention it as it is not something you would expect someone using conditional feeders for the first time to know.
Also, I think your statement is not completely accurate. It is only because the condition is on another cell than the one that is the driver.
If the condition was a string and based on the driver no restart / reprocess would be needed I believe. (Not that that is going to help Appleglaze)
Appleglaze,
not quite sure that I understand your 'new' problem.
One remark though
IF (vmonthattr @= 'January');
CellPutN(Value, 'STAGING_assumption_machine_capacity','January',base_machines,base_years,measures_machines_capacity);
ENDIF;
Since from what I got from people's opinion, its a bit troublesome to do it that way. So I was thinking of creating another cube like the source cube and change the "base_months" to "base_month_dates" so when the rules would flow in easily from this new cube to the destination cube. To get the data from the source cube to this staging cube I was thinking of using TI to get all the data.
I was wondering how do I reference the source cube's time dimension of months (e.g. Jan, Feb, Mar, etc...) to the elements of the destination's cube time dimension of date's (e.g. Jan-01, Jan-02, etc...) using the month attributes of this elements.
This is very common problem and as old as intercube rules and feeders. Not that it makes it easier but people smarter than myself have thought of solutions before.
Let's get to it....
If I look at the part of the rule that actually points to the source cube (ASSUMPTION_machine_capacity)
DB('ASSUMPTION_machine_capacity', ATTRS('base_machines_mc', !base_machines_mc, 'WorkCenter'), 'December', !base_years, '# of Spindle')
I am inclined that your destination cube ('PRODUCTION_capacity') actually uses the 'base_machines_mc' dimension rather than 'base_machines'.
Because if it doesn't the !base_machines_mc should actually throw an error.
It would also indicate that the first dimension in the 'ASSUMPTION_machine_capacity' cube is a 'workcentre'.
Anyways, let's just say you are fine with calculating the the '# of Spindle' for every Product and every day in December (at least if they have that month attribute filled), which is what your rule does, and let's also assume the dimensions you have listed are in that order in the cube, then it would be quite simple to feed all those days in that month from your source cube.
If 'Jan' is an element in the source cube dimension and 'Jan' is a consolidation of 'Jan 01', 'Jan 02' in the target cube dimension it would be
['# of Spindle', 'Dec'] => DB('PRODUCTION_capacity', !base years, !base_months, 'TOTAL PRODUCTS', !base_machines, '# of Spindle');
the !base_months would be the according consolidation in the 'base_months_dates' dimemension which translates into feeding all it's children.
You could take out the 'Dec' on the left side if you need to do it for all months.
Now... my guess is that you want to feed only a specific month (stored in a control cube) or specific dates and/or only specific products. And that is where it would become really interesting (at least for a 'Feeder Nerd') but still doable, without server restart, cubeprocessfeeders and the like btw.
For the former you would need to store the information about the Days and Month in a Cube, for the latter you would need a condition that allows you to identify which products actually were using '# of Spindle' on a day, which ideally would be another measure in your destination cube.
Just recently we have encountered that, for the DB rule which use attribute for an unmatching dimension, feeder did not work.
When we change from Attributes to Alias instead, the feeder work fine.
Try it, you only need to copy the old attribute to a new one defined as an Alias, and alter DB rule to refer to this Alias.
I have asked my senior, and she said every time value in cells change, including when attribute/alias changes, you need to run feeder-reprocess process in order to trigger feeders.
One thing that you can do in certain circumstances rather than a conditional feeder or "semi-conditional"/attribute style feeder is to have a data entry string parameters cube with much of the same dimensionality where the value entered against a string measure corresponds to the identity of the element that you want to feed in the other cube (with the advent of picklists this approach is now much easier to implement and more robust than previously also!). When a string cell is used as a feeder the feeder fires every time the value changes not just once when the cell changes from null to a value. Therefore if you use this approach you don't have to resave the rule, recompute feeders or restart the server in order to have the correct values fed.
Hi
Although I am still convinced that you could find a better condition/driver for this calculation, in particular adding the Machine - Product relationship, as you would always overfeed Products, here is the solution to feeding based on the 'Month Dates Lookup' you use. The key is to make it possible to feed from your condition as well.
To do this you need to first create a cube 'Production Days' which has Year, Month Day and a simple measure dimension with a String Element 'Month Name' which I called 'Month Day Measure'. This replaces the Attribute.
Second you create a 'Machine Period' cube which has Year, Month Day , Machines and the Measures Capacity dimensions.
I have replaced the source and target cube with 'Machine Assumption' and 'Production Capacity' respectively and the dimension name from the original example.
Then you write 3 Feeders.
1. From 'Production Days'
['Month Name']=>
DB('Machine Period',!Year,!Month Day,'All Machines','# of Spindle');
2. From the 'Machine Assumption'
['# of Spindle']=>
DB('Machine Period',!Year,!Month,!Machines,'# of Spindle');
3. From the 'Machine Period'
['# of Spindle']=>
DB(IF(
DB('Machine Assumption',!Year,DB('Production Days',!Year,!Month Day,'Month Name'),!Machines,'# of Spindle')<>0,'Production Capacity','')
,!Year,!Month Day,'All Products',!Machines,'# of Spindle');
The rule in the target cube would be
['# of Spindle']=N:
IF(
DB('Production Days',!Year,!Month Day,'Month Name')@<>'',
DB('Machine Assumption',!Year,DB('Production Days',!Year,!Month Day,'Month Name'),!Maschines,!Measures Capacity)
,STET);
What this will do:
1. Yes it will overfeed the Machine Period by a lot (by Machines and by Dates in a Month) but it doesn't matter as this cube does not get consolidated. It's a pure feeding cube.
2. Yes it will overfeed the Production Capacity by the number of Products but this condition could easily be build in if, as mentioned above, the relationship between Machines and Products would be known.
3. It will fire a feeder when
a) A month is added or changed to the 'Month Name' field in 'Production Days'
b) # of Spindle is added to the 'Machine Assumption' cube
The Product, Machine, Date and Year relationship is basically what Lotsaram is creating in the additional cube. Not saying that this is wrong or a bad approach but again I am sure that your Production Days and Machine assumptions are pretty much set and you are entering/loading a say '# of Machines' by Product by Date in you destination cube anyways. This then can be the basis of the feeder.
