Problem with Feeder Processing in PA

[PavoGa]

Since we upgraded to 2.0.9.1, we are seeing some issues with feeders.

Code: Select all

# test.Feeders.RUX

SKIPCHECK;


[{'202101', '202102', '202103'}, 'ClosedFlag'] = N:['OpenFlagConstant'] * 1;

[{'202101', '202102', '202103'}, 'PlanCalcFlag'] = N:['OpenFlagConstant'] * 2;


FEEDERS;

# 1
# does not feed PlanCalcFlag
[{'202101', '202102'}, 'OpenFlagConstant'] => ['ClosedFlag'], ['PlanCalcFlag'];

# 2
# this feeds PlanCalcFlag
['202101', 'OpenFlagConstant'] => ['ClosedFlag'];
['202102', 'OpenFlagConstant'] => ['PlanCalcFlag'];

# 3
# this feeds ClosedFlag, but not PlanCalcFlag for 202103
['OpenFlagConstant'] => ['ClosedFlag'], ['PlanCalcFlag'];

# 4
# This feeds both measures for 202103
['OpenFlagConstant'] => ['ClosedFlag'];
['OpenFlagConstant'] => ['PlanCalcFlag'];

Have also used fully qualified elements (ex: ['measure':'ClosedFlag'], ['measure':'PlanCalcFlag'] ) and it does not work either.

Additionally, CubeProcessFeeders does nothing to alleviate this. Is anyone else seeing problems with feeders in this version?

[tomok]

I wasn't aware you could list more than one element in the same dimension on the right-hand side in a feeder and have it work. I have always created a C element for those situations and fed that.

[PavoGa]

Set MTFeeders=F and MTFeeders.AtStartup=F and the feeders worked as expected using the #3 option.

[PavoGa]

I wasn't aware you could list more than one element in the same dimension on the right-hand side in a feeder and have it work. I have always created a C element for those situations and fed that.

Until now, have never ever had a problem with that. To be sure, it is not a set {elem1, elem2, ...}, but separate items [elem1], [elem2], ...

Actually, this is recommended in the Bedrock White Paper on rules and feeders.

[PavoGa]

Updated the original post. We are not in .3, but .1

[Wim Gielis]

I wasn't aware you could list more than one element in the same dimension on the right-hand side in a feeder and have it work. I have always created a C element for those situations and fed that.

I have always used the notation like ty showed it.
It seems like a normal way of writing it.

[Steve Rowe]

It sounds like this should be raised as a defect if multi-threading the start-up is not coping with standard syntax.

[lotsaram]

I agree. If you have a reproducible test case then raise as a defect. There's no way this shouldn't work for MTFeeders.
(and this is how I write my feeders).

[PavoGa]

I agree. If you have a reproducible test case then raise as a defect. There's no way this shouldn't work for MTFeeders.
(and this is how I write my feeders).

We intend to raise the issue with IBM asap. We think we've skated by until now because of persistent feeders, but our model uses a continuous timeline and had just added the periods for another fiscal year when this manifested itself in testing some new functionality.

Continued testing this issue yesterday and here are some more observations. Not conclusively proven to the Nth degree, but I want to get this out in case people start running into feeder issues in their models with this version. Important to note, we do not have this problem in cubes where the calcs are fed from user input cells and MTFeeders=F.

We see this work:

Code: Select all

# [B] & [C] are fed if [A] is not rule driven and MTFeeders=F
[A] => [B], [C];

This does not work now:

Code: Select all

# cube1 feeder
[A] => DB(cube2, elem1, elem2, [B]);

# cube2 feeder
[B] = N:DB(cube1, elem1, elem2, [A]);

FEEDERS;
# [C] gets fed. [D] will not be fed.
[B] => [C], [D];

# [D] gets fed if the feeders are structured this way:
[B] => [C];
[B] => [D];

# oddly enough, this appears to work:
[B] => DB(cube2, !elem1, !elem2, [C]), DB(cube2, !elem1, !elem2, [D]);

It does not matter if MTFeeders=F or T. Fully qualifying the elements with dimension names makes no difference.
Running CubeProcessFeeders does absolutely nothing. Server restarts, removing and resaving the rules, or making a new entry into [A] accomplish nothing. Zero, zilch so far. Only splitting the feeder, or possibly switching all internal feeders to DB(), resolves it.

Das ist schlecht.

[PavoGa]

Well. Today, everything I described above as failing is now feeding correctly. One of the other team members was investigating this further and reported the problems were no longer appearing.

Multiple targets, shorthand notation, chain feeder (A => B => C) and (A => B => C, D): all working.

MTFeeders=T or F, works fine now. I did restart my instance since the failed tests the other day. And had removed persistent feeders as well so the feeders were recalculated in full.

Don't know what could have happened here. Several members of our team witnessed the failing behavior, at different times, in different instances, and had seen it in our primary D, Q and S environments, all on separate VMs. All 2.09.1. Not only that, we were able to repeat it. If anyone else sees this behavior, would sure like to know.

Not afraid of feeders. But I do fear magical feeders. Heck, it's 2020. As good an explanation as any, I guess.

[PavoGa]

Additional information with more testing to come:

In the initial testing, the dimensions involved had alternate hierarchies. In the second round of testing with the feeders working as expected, the dimensions did not.

Added an alternate hierarchy to the measure dimension with a single leaf element. Multiple target feeding halted. Removed the alternate hierarchy, leaving the leaves hierarchy in place. Still failed. However, in this scenario, this structure:

Code: Select all

# [A] is a user input cell
[A] => [B];
[B] => [C], [D];

Both B & C were fed.

Additional testing to come, but right now it seems that alternate hierarchies are wreaking havoc on time-tested feeder syntax.

[PavoGa]

Once last comment. It appears that alternate hierarchies on dimensions other than the measure (or last) dimension in the cube do not break shorthand multiple target feeders.

Add an alternate hierarchy to the measure dimension, however, and feeders will have to be examined. We have submitted to IBM.

[Steve Rowe]

Thanks Ty, great work on narrowing this down and reporting back. Pretty challenging space to work in...

I'm assuming it is the last dimension in the built order rather than a re-ordered to last dimension?

[PavoGa]

Thanks Ty, great work on narrowing this down and reporting back. Pretty challenging space to work in...

I'm assuming it is the last dimension in the built order rather than a re-ordered to last dimension?

Thanks, Steve. Yes, it appears to be that dimension only.