String Feeder not firing when changed

[PavoGa]

This has me stumped because I've used this a number of times before, but something about this particular implementation is failing...and I cannot see it.

Calc Cube:

Code: Select all

FEEDSTRINGS;
SKIPCHECK;

['Current - Yr X', 'CalcFlag'] = N: IF(!Function @= DB('DLBR Input', !Versions, !Employee, 'Function') &
			!Career_Path @= DB('DLBR Input', !Versions, !Employee, 'Career Path') &
			!Labor_Category @= DB('DLBR Input', !Versions, !Employee, 'Career Level') &
			!Experience @= DB('DLBR Input', !Versions, !Employee, 'Experience') &
			DB('DLBR Input', !Versions, !Employee, 'Effective CS Empl') @= 'Y' &
			DB('DLBR Input', !Versions, !Employee, 'Effective DLBR Salary') <> 0
		, 1
		, 0);

If is fed by the DLBR Input cube:

Code: Select all

FEEDSTRINGS;
SKIPCHECK;

['Current - Yr X', 'DLBR CalcFeederFlag'] = S: DB('DLBR Input', !Versions, !Employee, 'Effective Selection Period') |
	DB('DLBR Input', !Versions, !Employee, 'Career Path') |
	DB('DLBR Input', !Versions, !Employee, 'Career Level') |
	DB('DLBR Input', !Versions, !Employee, 'Experience') |
	DB('DLBR Input', !Versions, !Employee, 'Function') |
	STR(['Effective DLBR Salary'], 7,2);

FEEDERS;

['Current - Yr X', 'DLBR CalcFeederFlag'] => DB(IF(['Effective DLBR Salary'] <> 0, 'DLBR Calc', ''),
	!Versions,
	!Employee,
	DB('DLBR Input', !Versions, !Employee, 'Function'),
	DB('DLBR Input', !Versions, !Employee, 'Career Path'),
	DB('DLBR Input', !Versions, !Employee, 'Career Level'),
	DB('DLBR Input', !Versions, !Employee, 'Experience'),
	'CalcFlag');

The input cube gets the Experience (and Career Path, Career Level from another cube which begets from another cube. Kind of like Old Testament cube design, right? But we have our reasons.

As you can see, DLBR CalcFeederFlag is a concatenation of various string values. If any of those string values change, we expect it to re-evaluate and feed the correct location of CalcFlag in the Calc cube. It is not doing that. We have other cubes where this mechanism works, but everything in those cases occurs within the same cube. This is different in that the strings are being read from other cubes further up the chain.

So when the server is restarted, everything calculates. If we process feeders, it feeds.

Our TM1s.cfg file for reevaluation of feeders:
ForceReevaluationOfFeedersForFedCellsOnDataChange=T

The value for DLBR CalcFeederFlag changes. Experience changes. But the feeder from DBLR Input to DLBR Calc is not firing.

Any guidance here would be much appreciated.

[TrevorGoss]

Hello,

not the most comprehensive response but, have you tried "kicking" the source Cube? You can do this by manually going into the rules file and making an update and saving it or, using the CubeProcessFeeders TI function.

[PavoGa]

Thanks, Trevor.

I have not done that, but processing feeders and restarting the servers makes it fire. I'll do that but expect the feeders to fire in that case. I've NOT tried as yet because I've set the experience value back to the original when tweaking the rules to try and make it fire when the value is changed.

I've even tried changing one of the values that is controlled within the DLBR Input cube (Selection Period) to see if that would fire the feeder as it is directly in the cube itself. That did not work either. Something is blocking that feeder code from reevaluating and feeding.

[TrevorGoss]

The Feeder..

Code: Select all

['Current - Yr X', 'DLBR CalcFeederFlag'] => DB(IF(['Effective DLBR Salary'] <> 0, 'DLBR Calc', ''),
   !Versions,
   !Employee,
   DB('DLBR Input', !Versions, !Employee, 'Function'),
   DB('DLBR Input', !Versions, !Employee, 'Career Path'),
   DB('DLBR Input', !Versions, !Employee, 'Career Level'),
   DB('DLBR Input', !Versions, !Employee, 'Experience'),
   'CalcFlag');

is conditional, and it may well be the case that it needs kicking one the condition has been met.

[gtonkin]

AFAIK, if you change the value of a cell that contains strings and this is referenced in feeders, it will not feed on change of the cell value you expect to "kick" the feeder. This also applies to moving an element in a hierarchy where you are feeding from a C level and the element move to a new parent which should feed. Attribute values in the right-hand side of the feeder are prone to the same issue when the value of the attibute changes.

On an aside, why would you not move 'Effect DLBR Salary' to the left - removes the conditional - same dimension as 'DLBR CalcFeederFlag'?

[PavoGa]

Trevor,

I was hoping you'd hit on the problem with the conditional part of the feeder keeping it from firing. After all the condition had not changed, just the value that was being used to feed with it in it. So I removed the conditional from the feeder and put in the rule for creating the concatenation of the feeder value. Unhappily, it still did not work. Also, resaving the rule file, surprisingly, did not cause the feeder to fire either. CubeProcessFeeders did fire the feeder 100% of the time on the DLBR Input cube.

Just to clarify, here is what is required:

A value is calculated at a specific intersection in the calc cube. That address is based on entries in several input cubes, which are coalesced into the DLBR Input cube. It is an On/Off value, either 1 or zero based on a couple of conditionals.

We need to feed that on/off when one of the values changes that is used in specifying where the calc cube rule will evaluate to 1.

In this case, Experience in the input cubes relates to an element in the Experience dimension of the calc cube. When the Experience changes, the calc cube does, in fact, calculate the value of 1 in the correct intersection. However, it is not getting fed in spite of the string value used to feed it changing.

gtonkin, I agree with you on that and modified the feeder and rule. However, the results were the same. I was sincerely hoping that was the "duh" moment.

[BrianL]

I'm not a rules expert, but don't you need to feed

Code: Select all

['Current - Yr X', 'DLBR CalcFeederFlag']

too?

Unless I'm missing something, changing experience doesn't feed that calc, so that calc won't in turn feed the calc cube.

[PavoGa]

BrianL,

Yes, it has to be fed and I left that out of my discourse. I have tried:

Feeding internally in the cube with Experience
Feeding from the parent cube with Experience

Also tried feeding the calc cube on/off flag directly from experience just to test and that did not work either.

The [DLBR CalcFeederFlag] is fed.

[tomok]

If any of those string values change, we expect it to re-evaluate and feed the correct location of CalcFlag in the Calc cube. It is not doing that. We have other cubes where this mechanism works, but everything in those cases occurs within the same cube.

Sorry, I'm not buying that. It has been my experience that string-based conditional feeders do not refire whenever the string changes, only when the string goes from nothing to something, much like numeric feeders. You likely fed the cell with something else, either intentionally or unintentionally, and thought your scheme was working.

[PavoGa]

Sorry, Tomok, I'm not selling it, but stating it as a fact, we have it working and have just setup the same methodology in this case where it works. I believe there are numerous postings on this forum explaining that changes in string values causes feeders based on those values to fire again and I use that method all the time.

This:


Cube1:Experience is user input
Cube1:Experience => Cube2:Experience

Cube2:Experience = Cube1:Experience
Cube2:Experience => Cube3:Experience

Cube3:Experience = Cube2:Experience
Cube3:FeederFlagValue = Cube3:Experience | OtherStringValues
Cube3:Experience => Cube3:FeederFlagValue
Cube3:FeederFlagValue => Cube4:CalcFlag

Cube4:CalcFlag = IF(something, 1, 0);

Does not work when Experience changes.

HOWEVER,


Cube1:Experience is user input
Cube1:Experience => Cube3:FeederFlagValue

Cube2:Experience = Cube1:Experience
Cube2:Experience => Cube3:Experience

Cube3:Experience = Cube2:Experience
Cube3:FeederFlagValue = Cube3:Experience | OtherStringValues
Cube3:FeederFlagValue => Cube4:CalcFlag

Cube4:CalcFlag = IF(something, 1, 0);

This works 100% if Cube1:Experience changes. Its seems the change is not causing the feeder to fire again if it goes through intermediaries. I.e., an input value directly feeding the FeederFlagValue will fire, but a rule driven value change to the FeederFlagValue will not. As stated in my initial post, I thought the config value was supposed to deal with feederstring evaluations stopping.

Unfortunately, there is branching in the logic so that feeding from Cube1 will not work correctly because a change COULD occur in Cube 2 for Experience. If someone has had this issue, would really like some insight as to how to work around it without reprocessing feeders.