Subtle bug in Example for Dynamic Dimensions
In the example code for the Dynamic Dimension Service there appears to be a subtle bug which will affect refresh of the dimensions. ReadDynamicDimensionInfo(...) returns DateTime.Now: ' This api m...
Forum Discussion
I don't think this is quiet the "bug" you think it is.
Based on some testing, I have found that if you pass-in DateTime.UtcNow to DynamicDimensionInfo() or DynamicDataUnitData(), OS will trigger refreshes far sooner than you expect. Using DateTime.UtcNow caused it to effectively ignore the 300 sec wait time I had configured.
It would appear DynamicDimensionInfo() or DynamicDataUnitData() DO expect you to pass in DateTime.Now, as OS's code samples show,. Presumably the functions must internally then convert the passed in Time to UTC time.
That does seem a little inconsistent when ReadDynamicDimensionContentTimestamp() ReadDynamicDataUnitContentTimestamp() are both expected to return UTC time. My personal sense is that DynamicDimensionInfo() or DynamicDataUnitData() should both be expecting UTCTime, or have an option to do so.
It could be that it assumes/sets DateTimeKind.Utc internally, just that it's not visible in the BR engine. I could see that it might appear to ignore your wait time depending upon which site of UTC you are on though