Migrate Substitution Variables

We can migrate substitution variables from one environment to another by using the EAS console. Say for example, that you want to copy substitution variables from Development to Production environment.

These are the steps that you can follow:

1         Log in to EAS.
2.       On the navigation panel, expand Enterprise View > Essbase Servers > Server_name (for example EssbaseCluster-1, or whatever server name you have).
3.       Right-click the Server > Edit > Variables.
4.       On the right, you will see a list of all the Substitution variables in the environment. You can see columns – Application, database, variable, Value.
5.       Choose the one(s) that you would like to migrate. You can make use or CTRL / SHFT key to make multiple selection.
6.       Click the “COPY” tab.
7.       A “Copy Substitution Variables” window pops open.
8.       Choose the following

a.       Under Essbase Server, choose the target Server from the drop-down.

b.      Under Application, choose application from the drop-down.

c.       Under Database, choose database from the drop-down.

d.      You can see check boxes under the “COPY” column.

e.      Check the ones that you want to COPY.

f.        Check the “Overwrite existing variables” check box if you want to overwrite the existing variables.

g.       Click OK.

h.      You are all set. Check and verify that the variables have migrated and are available in the target environment.

Deprovision users using LCM

If we come across a situation where we have to deprovision users in Hyperion Shared Services, we can use the LCM tool to do so. If it is a matter of deprovisioning only one or two users, we can do it manually, however, if it has to do with a lot of users, the LCM deprovisioning comes in pretty handy. It works the same as regular LCM, however, with the DELETE option while importing provisioning.

Here is a step-by-step guide to deprovision users in a planning application in bulk.

In source EPM environment, log on to Shared Services.

Perform an LCM export >

Application Management

                Foundation

                           Shared Services

                                    Native Directory > Assigned Roles > Planning > Application (check this)

Execute Migration to a File System. Name it “SAMPLE” (just an example)

The Migration Wizard box (as shown below) has several steps such as Source, Source Option, Destination Option, Summary, etc. Fill them out as per requirement.

The execution of Migration exports the migration file to the Import-Export folder. If you navigate in to the Import-Export folder, you can see a folder which looks something like "USER@NATIVEDIRECTORY" or "USER@ACTIVE_DIRECTORY_NAME," etc. The export folder is created under the "user" who performed the migration. Same holds true in target environment.

We can view "Migration Status Report" under "Administration" in the menu bar in order to check the status of migration.

Open the file that is created after the export process. I prefer MS Excel for this.

Modify the file such that you will have only rows containing the users that you want deprovisioned. It means you need to delete the rows that contain the users/groups that you still would like to be provisioned after the process.

Save the file.

Move the file to the Import-Export folder in the target server, ie., where you have Shared Services installed. The path is usually "\oracle\Middleware\user_projects\epmsystem1\import_export" however, you may have different path as per your organization policies or whoever installed EPM in your organization.

Log on to Shared Services in target environment.



Perform LCM import from the File System by choosing “SAMPLE” from under File System in Shared Services. 

SAMPLE is created after the LCM export that you have performed earlier. If you do not see it, click “REFRESH” just below “File” on the top left corner of the screen/HSS menu.

On the right, expand “Native Directory” till you get to the application name. Check.

Click “Define Migration” and keep going.

On the “Migration Wizard” window, under “Destination Options” you will see “Import Operation Type” followed by a drop down. Choose “Delete” and click NEXT.

Execute Migration.

Log on to Planning, and refresh security filters.

The users you wanted deprovisioned should be gone by now.

How to rename PlanType (database) name in Hyperion Planning

Say you have a Hyperion Planning application “Candy” with Plan Types “PlanType2,” “PlanType3,” and your main database “NYC.”

However, you need are told to rename “NYC” to “Handy” so that the App-DB name would be Candy-Handy.

This is how you can achieve this.

Before making any changes, however, make sure that you have stopped all the Services on the app server. Not doing so may lock tables.

After stopping the services, log on to Oracle SQL Developer (I have Oracle 11G and SQL Developer). You log on to what DB you use.

Find the HSP_OBJECT table for the Schema User used for the Application Candy. Mine is called Candy_adm. So, I choose the HSP_OBJECT table under user Candy_adm.

In the HSP_OBJECT table, under column OBJECT_NAME, find the old database name that you want to rename. In this case, since, I have three plan types (NYC for PlanType1, and PlanType2 and PlanType3), they fall under column OBJECT_ID – 100, 101, and 102.

Rename NYC to Handy as you want the new database to be Handy. Save

Now, open table HSP_PLAN_TYPE.

Rename NYC to Handy. Save.

If you already have the old database (NYC) created in Essbase, go to EAS console and rename the name of the database as well.

Start EPM services in the app server (the ones that you had stopped).

Open the planning application Candy. You should be able to see the Handy database name instead of NYC.

Refresh DATABASE so that you have it in Essbase as well.