Duplicate Hyperion Planning app creation (with a different name) from LCM Backup

Hyperion administrators frequently have to restore a planning application from an LCM backup, but not very often the need arises to create a duplicate application with a different name from a backup. There are no clear-cut processes to do it but there are workarounds to achieve this objective.

In this blog, we will cover the steps to create a new planning application from an existing application LCM backup. As mentioned earlier, it is not a straight forward process, but we can hack some existing backup files to get this done.

Existing Planning Application:

Application Name: TestApp

Datasource Name: FinCon

To Be Created:

Application Name: TestApp1

Datasource Name: FinCon1

Step#1 

Create a new datasource (FinCon1) connection from Planning administration UI. (Request your DBA to create a new database schema if required)

Step#2

 Take LCM backup of the existing application and download it to your computer.

Step#3

Extract the files from the LCM to a temporary folder.

Step#4

Find the file “Import.xml” and change the application name from “TestApp” to “TestApp1”. Save your changes and close the file.

Step#5

Find the file “ApplicationDetails.xpad” and change the application name from “TestApp” to “TestApp1”. Also change the datasource name from “FinCon” to “FinCon1”. Save your changes and close the file.

Step#6

Select all the files in the extracted LCM backup folder and create a new archive/zip file.  This is a bit tricky step as you shouldn’t create zip file from the LCM root folder.

                   

Step#7

Navigate to Shared Services->File System.  Upload the zipped updated LCM backup.

Step#8

Expand the uploaded backup file, select the application folder. In the Artifact List shown in the right pane you may want to unselect Security, User Preferences and User Variables as they are optional and may not be relevant for the new application. Now click on Import to progress with the application creation process

A prompt would show up with the new application name (TestApp1). Click Import.

         

Step#9

Once the import is successful, go to Navigate->Application->Refresh in workspace main menu to refresh the application list. Then, go to Navigate->Application->Planning and open the new application (TestApp1) from the list.

Step#10

You may want to load data from the source application (TestApp) if data is not part of the LCM backup. Once data is loaded, go ahead and run necessary aggregation scripts before releasing it to your users.

Essbase Implied Share

"Implied Share" is a default behavior in essbase database. Basically parent shares "storage" with the child in a few special situations which is referred as "Implied Share". In other words Essbase doesn't allocate the storage to "Parent" but it still retrieves the value of the child.

Here are the situations that would cause "Implied Share" behavior:



(1) "Label Only" parent with one or more children

"Label Only" members are meant for organizing the members by giving some meaningful group names. These members are not meant for reporting or planning. Essbase doesn't allocate memory (storage) to this members. But when a "Label Only" parent member is queried, it returns the first child value.

outline:

Working Scenarios (Label Only)

    |-- Jan Forecast (~)

    |-- Feb Forecast (~)

    |-- Mar Forecast (~)

    |-- ....

    |-- ....

    |-- ....

In the above example, Working Forecast value will be equal to Jan Forecast value as both form an "Implied Share"

(2) Parent of a single Child:

Any parent member with only one child creates an implied share with or without the "Label Only" storage property

outline:

Cost of Goods Sold (+)
    |-- Cost (+)
 

(3) Parent of many children but only one child aggregates:

Discounts
    |-- Buy One Get One (~)
    |-- Dollar 10 cashback for 100 (~)
    |-- 25% Discount (+)
    |-- .Mark Downs (~)
    |-- ...
    |-- ....


In the above example, the member "25% discount" creates implied share with the parent "Discounts"


Advatanges of Implied Share:

Data is not duplicated between parent and child hence block size will be kept low. Cube performance will be high


Disadvantages of Implied Share:

In planning data forms (or Excel Data Sheet),  when a parent is specified below the child, the child doesn't get saved. Because essbase saves data from top to bottom.  So the parent member at the bottom will clear or change the data in the child.


How to avoid "Implied Share"?

there are two ways to avoid it. (1) Tag the member as "Never Share"  (2) Change either server level or application level setting in "Essbase.CFG" file. 

                        IMPLIED_SHARE <ApplicationName> FALSE