Oracle DRM Blog

Oracle DRM / Hyperion DRM is a pretty good product. It’s mature, it’s flexible and it kicks ass. If you’ve worked with Essbase Outline Editor, it’s the smarter cousin it never had. If you’ve worked with Hyperion Business Performance Architect (BPA), it has much less issues or bugs. Let’s face it, every software product has bugs or opportunities to be better (I like that!). Last week though I managed to find a bug in DRM, reported it and got it confirmed that it’d be fixed. I have not been able to do this for a while and secretly I am rejoicing…yeah I found a real bug. Maybe I have not worked hard at it before or hadn’t the need for it. I’d rather have a bug-free product than sending bug reports everyday don’t you think? I have to praise their support and dev team here because they’re probably one of the most responsive team I have worked with (Thanks Michael for taking my call and my beatings tirelessly). Anyway, let’s get on with it.

Couple of articles ago, we talked about the change tracking properties, how they could be used to highlight who and when changes are made for all the nodes. While I was writing part 2 of the series, I suspected something is wrong on how they handle these properties once a new version is copied. At that time, I simply skimmed over the implications on why you should leave the “Clear Changed Properties” unchecked. I wanted to confirm the facts first. You see, when you leave the “Clear Changed Properties” unchecked, all the change tracking properties and their values are carried over to the new version without modifications. This is great because otherwise, the “Added On”, “Added By”, “Changed On” and “Changed By” properties would be blanked out and you’ll lose very important historical information about each node.

The drawback or shortcoming, though, is that the 5th change tracking property “Node Changed” boolean flag is also carried over as “True” for each and every node. And this is the bug. You see, if all the nodes are flagged as changed, than while the new version is left opened for changes to be submitted, how do you separate those that were changed or not changed. You simply cannot because you started the version with every node highlighted as changed. And if there’s additional changes made that month, they’d also be continued to flag as “changed”. What DRM should have done is to copy the other 4 properties as usual, but it should clear the “Node Changed” boolean to “False (unchecked)”. By clearing the “Node Changed” boolean, when the new version is opened and changes are slowly being made to the nodes, you can simply do a property query to find out the affected master data (nodes).

Nodes where the NodeChanged property equals True.

Now what if you decided to check the “Clear Changed Properties” option when copying to a new version. Well, you’d achieved the objective of clearing the “Node Changed” boolean property. But at the same time, you’ll also have cleared the “Added On”, “Added By”, “Changed On” and “Changed By” properties. And again as mentioned, you’ll lose important information going forward.