Hyperion Essbase 11.1.1.0 – Transparent Partition – Using BSO as Partition Targets – Write-Back Partitions on ASO – Part 2

Hyperion Essbase 11.1.1.0 – Transparent Partition – Using BSO as Partition Targets – Write-Back Partitions on ASO – Part 2

In the last blog entry, i had given a brief on how Transparent partition works on ASO targets. One of the major drawbacks of ASO targets is that, they cannot be used to store local data. Today we shall see the advantages of using BSO cubes as transparent partition targets. The major advantage of using BSO as a transparent partition target is that, it provides the capability to do write-backs on ASO (more of a workaround). Lets take at a simple use case today. We shall be using the same GlobaASO cube as our ASO source. Lets look at this ASO outline first.

        

As you see, we have 4 analysis dimensions and one accounts dimension. This ASO cube stores only actual units sold. Lets assume that we have end users who do active planning/forecasting on the number of the units sold. And they need to have the capability to store the forecasted data directly into the cubes. Typically they do the forecasts along the product dimension. Lets also assume that forecasting is typically done for the last 6 months after looking at the 6 months of Actual units sold. So, in order to facilitate this, lets create a BSO cube as shown below.

        

As you see, this BSO outline has only 3 dimensions. So, any user who would be involved in forecasting would be looking at the actual units sold for the first 6 months and then would be doing the forecasts accordingly for the remaining 6 months. Also this outline has one extra account called as Forecast Units which would hold the Forecast Data. Now lets create a transparent partition with the ASO cube as the source and the BSO cube as the target.

        

        

The important point to note while creating a partition is the fact that we do not have the same set of dimensions in the source as well as the target. So for all the dimensions that do not exist in the target, just include the topmost member (dimension member or the member that you feel has the relevant data stored for forecast). The source partition area would look like the one shown below

        

As you see, i have chosen the topmost member(in the source) for the non-existent dimensions in the target. The target partition would look like the one shown below

        

Now, if you validate the partition you would get an error stating that the number of dimensions in the source and the target do not match.

        

To bypass this, go to the mappings tab and map your non-existent dimensions in the target from the source as shown below

        

This will validate your partition. Now go to excel-add in and query on the new BSO cube.

        

Now as an end user, i would typically look at Q1 and Q2 actual numbers and based on that i would be forecasting for the remaining 2 quarters across multiple products. Of course, there would be a lot of other factors coming into play while forecasting, for simplicity purposes i would just multiply the Q2 actual numbers by 1.3 for Q3 and Q4 forecast. You should be able to do this directly from excel-add in. Though you might be getting warnings on the write-back going against ASO(as long you are sure that the particular cell that you have locked is not part of the transparent partition you should be good), you should still be able to writeback. Essbase performs a partition area check based on the members chosen in Excel and not on the cells locked. Hence you might get warnings even if you have locked the correct cell.

        

Posted in All Posts, EPM, Hyperion Essbase | Leave a Comment »

Hyperion Essbase 11.1.1.0 – Transparent Partition – Using ASO as Partition target – Part 1

Posted by Venkatakrishnan J on March 19, 2009

In the last blog entry we saw how a Transparent partition works. Today we shall go more into detail on what this partition does and how it works on BSO and ASO cubes. To demonstrate this, i would be using a nASO cube as the partition source. Both ASO as well as BSO would be used as partition targets. This would let us understand the differences between ASO and BSO while using them as Transparent Partition targets. Lets start with a Global ASO outline as shown below. This would act as our transparent partition source.

        

Now, assume that we have 2 partition targets. One in ASO and the other in BSO. As a thumb rule, for partitioning to work, the number of dimensions in the source and the target should match. But the dimensions would typically be a subset of the source partition. The outlines of the target ASO and BSO cubes are provided below.

        

Lets create a partition on the source ASO cube. There are 4 main steps while creating a transparent partition

1. Assigning a target ASO/BSO database
2. Assigning security
3. Assigning Areas
4. Creating mappings between the source and target.

The first 2 steps are self explanatory. In our first case, we shall use ASO as a target.

        

        

        

Once the security and the target have been assigned, the next step is to define the area. The area definition (basically this defines the slices of the source and target databases) should follow certain rules.

1. Number of cells chosen in the source and the target should match
2. When the source and target dimension members match, just include them in the area definition and there is no need for additional mapping.
3. When the source and target dimension members do not match, mapping editor should be used to map the individual members.
4. If a dimension is not chosen in the area, then the partition inherently assumes that the dimension has a one-to-one match between the source and the target.

In our case, since we have the same dimension member names, we shall map just a single level-0 dimension member combination of the source with the target as shown below.

        

Since we do not have any Customer dimension mapping, the partition assumes that every member in the source Customer dimension and the target customer dimension match. Now, lets load some data into the source.

        

And lets try to view the data in the target.

        

As you see, we are able to query the source from the target. This is straight forward. Now, the next step is to define another area like the one above. This time map the Apr-99 member from the source to the target. The basic reason for doing this is to understand whether the target does a dynamic aggregation based on multiple partition/multiple areas within a partition.

        

After doing this lets validate the partition and verify the data from excel add-in.

        

As you see, the target is able to do an aggregation from 2 different areas of the partition dynamically. This is the value add of a transparent partition.

One of the major differences between ASO and BSO transparent partition targets is that, ASO does not support local data. Even if one loads data into the unmapped regions of the partition target, this would not be recognized by the ASO target. To validate this lets load the data in the ASO target for the Month of Jun-99.

        

After loading this data validate the partition.

        

As you see, the warning message clearly states that local data is not supported. Even when we query from the excel add-in we would not be getting the local Jun-99 data.

        

In the next blog entry we shall see how a BSO cube behaves when it is used as transparent partition target. I would also show how a BSO transparent partition target can be used for Custom ASO writebacks.