Feeder Match based on string input

[PlanningDev]

Im having trouble getting feeders to work correctly in this scenario so Im hoping someone has some information around when feeders are fired.

I have a cube that has a static dimension with lines 1-10 and the time dimension (Jan-Dec) which has also has an extra line for the string input.

IE(string item, Jan, Feb, Mar, Apr, May, etc.)

In another cube I have a dimension that has values in it that may correspond to what a user types into the string item in the first cube.

My feeders should feed from the input cube over to the other cube based if there is a matching string input to the dimension item.

When I first write the feeder it works for existing string inputs. The problem is when another string is input and values are entered the feeder doesn't appear to re-fire and the target cube shows the values as not fed. A trace feeders on the original cube however shows that it is feeding the target cube.

In Cognos Planning this was considered a virtual dimension but due to the length of the dimension I don't want to use a picklist.

Thanks for any help

[Martin Ryan]

Feeders are fired at these times
- when the server is started
- when a rule is saved
- when the user types in a piece of data that is used to feed another cell
- when you use the TI command "ProcessFeeders"

Number three could be expected to work on your scenario except that it only applies when a number on the left hand side of the feeder is updated. E.g. For the feeder statement ['Qty'] => ['Sales']; the feeder will fire when you type in a number against Qty.

In your example you have a feeder like ['Qty'] => DB('MyCube', !Dim1, !Dim2, db('LookupCube', !Dim1, 'StrValue'), 'Sales'); This feeder will still only automatically fire when the Qty field is updated. It will not fire when the 'StrValue' field is updated.

Hope that clears things up a little bit. As far as solving your problem is concerned you may have to periodically run a TI process that runs "ProcessFeeders". Or alternatively use the string that is being typed in as the source (i.e. left hand side) of the feeder. Though I expect this will lead to overfeeding.

Martin

[PlanningDev]

Hi Martin,
Actually the only time I want the feeder to fire is when data is entered. There isn't really a need to fire it when the string is entered (Except for if it is changed from one to another. Ill work on this one separate.

The issue I have now is that using the same method you show in your post it appears that the feeder is only being evaluated when I save the rule. The second I unload the cube and try to enter a new string value nothing happens.

Any ideas?

[tomok]

I'm about 90% sure that in your scenario, using a lookup cube to determine an element match, that you have to re-process the feeders, either through re-saving the rule or issuing a ProcessFeeders command through TI, in order for it to be dynamic. I have encountered this before and that was the conclusion. I don't know if setting the ReevaluateConditionalFeeders=T in the tms.cfg file will solve that problem or not. I don't think so but it's worth a try.

[Martin Ryan]

There isn't really a need to fire it when the string is entered

The second I unload the cube and try to enter a new string value nothing happens.

I'm a little confused here, because based on your first quote the second quote isn't actually a problem??

[PlanningDev]

I realize now that those statements are contradictory. Yes I do need it to fire for both events but I was hoping to at least get it working for the data entry and if that will work then see about the string input.

[Martin Ryan]

It should just work for data entry, provided your string value is already in and correct.

As I mentioned above the only way to get it running for the string entry is to have it as the source for a feeder or periodically run the ProcessFeeders TI function.

Martin

[PlanningDev]

I have been testing this and it doesn't appear that the feeders are working even after entering data. Not sure why it wouldn't fire after data entry but whats odd is like a said before, the trace feeders from the source cube shows that it is feeding the target cube but when checking feeders in the target cube it shows not fed.

[PlanningDev]

Oddly enough, when I use the string cell to feed over to the target cube it works. Except when I unload the cube while string values exist then its not fed. Only entry of the string cell fires the feeder.

Still tryin to figure this one out! Thanks for your help

[lotsaram]

Oddly enough, when I use the string cell to feed over to the target cube it works. Except when I unload the cube while string values exist then its not fed. Only entry of the string cell fires the feeder.

Still tryin to figure this one out! Thanks for your help

There's not much to figure out, what you are describing is expected behaviour and is simply the way that feeders work.

Numeric feeders fire only when the source cell value changes from NULL to any numeric value. Any subsequent change in value of the cell will not trigger the feeder to be re-evaluated. Hence if there are other changes in source conditions (such as changed attribute values which might affect the definition of the target area to be fed) then the area being fed wil not change unless the rule is re-saved or a ReprocessFeeders TI function is run.

String feeders on the other hand are different and fire on each and every change in value of the source cell.

If the area to be fed needs to change dynamically based on each change in a source value then the best option is to feed from a string cell as only string feeders have the functionality that it seems you are looking for. However do note that although new areas may be fed from a changed input value that areas that were fed by former conditions (but are no longer fed fro the current feeder conditions) will remain fed as once fed a cell stays fed for the duration of a server session (and longer if using persistent feeders, there is another current thread on that issue...)

[PlanningDev]

Thanks for the info lotsaram.

It does appear that using the string to feed is the best option here but I am noticing now that this may need to be in combination with a TI that processes feeders on some interval. The reason being that server startup and cube unloads don't appear to be running the feeders as expected. It seems that processing feeders gets the cubes to the correct starting point.