Implicit Sharing

Many of us who work on Hyperion Essbase on a regular basis know what “Implied Sharing” is (Interview questionnaire 101 for Hyperion has this as a FAQ…Some of the other questions are dense-sparse, number of blocks and so on…Have been on both sides of the fence so these are the questions we generally use to ease into the abstract world that we inhabit). 

Implied Sharing is when the value of a child rolls up to a parent if:-

• ·         The parent has only one child.
• ·         The parent has only one child that consolidates to a parent.

Implied sharing by itself is one thing…But if you use SmartView along with implied sharing, you can get some very cool results…

I have created the below hierarchy in the Entity dimension to mimic the implicit sharing rollup.

So I have IE11111 rolling up to IE1111 which rolls up to IE111 and so on.

Now, I will do a lock-&-send of dummy data on the level-0 member as shown in the next snapshot. (The number has a significance… Any physics enthusiast will know it right away)

After doing the lock-and-send, the retrieval shows how implied sharing works. So you have the data rolling up till the parent without any consolidation being run.

I now change the data value as shown in the below snapshots to test what happens if I do a lock-and-send on all the cells…If you observe, I have kept all the values different to see which value takes precedence…

After lock-and send and retrieve, you can observe that it took the value of the leaf level and ignored the value of all the remaining members as shown in the below snapshot. ( There is a mistake here… Human error is just as likely… An example of a bad test case, ideally the last value should not be 137, it is actually saving the value of Implicit_Entity to the level 0 member)

 

Now, I do a data input of all zeros into the application as shown in the below snapshot.

After doing a data input of zero, I change one of the upper level members to 137 and do a lock-and-send as shown in the below snapshot.

After retrieval, the value of 137 is now implicitly shared throughout as shown in the below snapshot…

Even if I change at any upper level as shown in the below snapshot, after a lock and send of 0, the implicit sharing will reflect correctly as shown in the below snapshot.

The thing to remember is that, if you have a data grid where you are doing a manual lock-and-send, and it has implicitly shared members as well, you may get different results based on the order in which the members are present.

Check out the below snapshots.

I did a lock and send of 45, 46 and 47 on the Generation 1, Generation 2 and Generation 3 members.

But, it reflects the last value in retrieval i.e. 47 is now shared across the implicitly shared hierarchy.

I reverse the order as shown in the below snapshot and the last row value (in this case, generation 1 value) gets reflected across the sheet.

So, if you have a sheet where you are doing manual lock and send, and it spans thousands of rows, you can get a variance, simply because of implied sharing and the order in which the data grid is created.