Special uses for Life Cycle Management (LCM)

In my previous post, I showed how to use LCM to back up or copy an entire planning application environment.  Here I’ll expand on that subject a bit by showing some other uses you may find handy.  This is by no means meant to be an exhaustive collection – just a few suggestions you may find useful and which may provoke ideas for other uses.

Copy single dimension from one app to another

This can be done for any dimension, including the standard planning dimensions.  Here, to expand on the subject we are also going to export from the “Organization” dim in one planning app & import to the “Entity” dim in another.

Select the artifacts to export (no harm in copying everything).

Click thru the next screen to this one.

Since we need to change the dimension name, we must export to files, not directly to the other app.

Then click thru the remaining screens to execute the migration.

After the export finishes, go to the \Hyperion\Common\Import_export directory. Under the Username@Directory folder find the files you exported.

In the “info” directory, edit “listing.xml” changing all instances of “Organization” to “Entity”.

Now find the XML file for the dimension to be migrated with name change.

Rename to the target dimension name.

Now edit the file to change “Organization” to “Entity”.

In Shared Services->Application Groups->File System, open the extract and select the (newly renamed) Entity dimension.

Define Migration…

…and click thru the remaining screens to execute the migration.

Lights-out Operation

In Shared Services select the artifacts to be backed up and define migration.

We need to back it up to files so type in a folder name…

…and click thru the remaining screens until you get here.

Now, instead of clicking the Execute button, click “Save Migration Definition.”

You will get this screen…

…click “Save.”

Shared Services wants to save “MigrationDefinition.xml” where you tell it to.

You can name the file any name you want (I suggest using naming conventions to differentiate the operation being saved) and anywhere you want.

After saving the file you will get this…

…click “Close” and the backup definition will be saved.

Now look in the Automation folder where the xml file was saved.

The file has everything Shared Services needs to run the backup from the command line utility except the USERID and PASSWORD.

Edit in TextPad or other text editor and type in a Userid and password.

After running the job the password is automatically encrypted.

The job is run from an Oracle supplied process, “utility.bat.”

…and you pass the path information to the migration definition file you created above.”

You should channel the output to a log file so you will have a record of success or failure.  The following message is an excerpt from that log which, in turn, lists the detailed log location & name and whether the process was a success or failure and it will also tell exactly where any failure occurred in the process.

I hope I’ve shown you enough to get you started using LCM.  It can certainly be a valuable tool, whether you want to do one-time tasks or perform lights-out operations such as regular backups.  The important thing to remember is to test it and see what, if any, problems you will have and either fix those or work around them.

Using Oracle’s Hyperion® Life Cycle Management

What is LCM?

LCM (Life Cycle Management) is a tool which can be used to migrate Hyperion applications, cubes, repositories, or artifacts across product environments and operating systems. It is accessed through the Shared Services Console.

Does it work?

After using LCM at a few clients I think the answer is a definite YES, but there needs to be a realistic setting of expectations:  Yes, LCM has some very good and handy uses; but NO, it is not necessarily going to be a painless, simple answer to your migration and/or backup needs.

What can I do with it?

You can use it for migrations:

  • One environment to another
  • One app to another (same SS environment)
  • Selected dimensions or other artifacts

And for backups/restores, including keeping two separate environments synchronized:

  • Selected artifacts
  • Lights-out

Products which can be migrated are:

  • Shared Services
  • Essbase
  • Planning
  • Reporting
  • HFM
  • The dimensions housed in EPMA

This blog is going to concentrate on using LCM for planning application migrations although, as you can see from the list above, it can also be used for other products as well.

First I’ll show how a migration is done, using screen shots, to give a detailed look.  Then I’ll point out things to look out for including things which will cause the migration to fail — with work-arounds where possible.

To migrate an entire Planning application, you will need to copy (4) areas:

  1. Shared Services
  2. Essbase (For Planning, only need the Essbase Global Variables.  All App/DB specific variables are migrated with the Planning Application)
  3. Planning Application
  4. Reporting and Analysis (if applicable)

The order in which you export these is not important but when doing the import, the order is very important.

Some important considerations:

  • Target app can have different name from source
  • Source and destination plan types must match
    • Can be changed by editing the files
    • Target plan types must be in same order as source
  • Start year must be the same
    • Number of years doesn’t need to match
  • Base time period must be the same
  • Target app’s Currency settings must match Source
  • Standard Dimension names must match
    • Can be changed by editing the files

When exporting any application it is advisable to just export everything.  If necessary you can be selective on the import side.

Start the process by opening the Shared Services console and go to the Application Groups –>Application (in this case – Shared Services under Foundation).

In the lower part of the screen, click “Select All” and then “Define Migration”

Now go through the screens:

Leave each field with an * and Choose “Next”

Type in a file name for the export.  It is advisable that you use a naming convention for this since you will end up with (possibly multiple) files for each application.

Review the destination options & click “Next.”

Finally, review the Migration summary and click “Execute Migration.”

NOTE:  If this process is going to be re-run in a lights-out environment you should instead choose the “Save Migration Definition” button.  I’ll discuss this more fully later on.

You will get this information screen.  Click Launch Migration Status Report to actually see the migration progress.

As long as the migration is running you will get a status of In Progress

Click Refresh to keep checking status (if desired) until you get a status of Completed or Failed.

All of the other applications can be exported this same way, each with slightly different screen sequences but generally the same process.

The primary differences will be for Planning and Essbase where, if there are other applications in the same Shared Services environment, they will be offered as possible targets for the export, in addition to the File System.  Selecting one of these will cause a direct migration from the source application to the selected target application.

After the exports are finished the LCM export files can be copied to the target server environment, if needed.  These export files can be found on the Shared Services server under \Hyperion\common\import_export\username@directory.

Copy the entire directory (in this example, Essadmin@Native Directory) to the Hyperion\common\import_export directory on the target server.

The import side is where things are more likely to be tricky.  Here you will reverse the process, selecting the export files in proper order (Shared Services, Essbase, Planning & Reporting) and importing them to whatever target is appropriate.

Start the process by logging in to the Shared Services console as the same username you used in the export process.  Under Application Groups–>File System, find the appropriate export files and click “Define Migration.”

Click through the screens, including the SS screen selecting the target application to import to.

On the destination option screen select Create/Update and increase the Max errors if desired (default = 100)…

…and run the migration.

For the Planning import select all to begin.

Click through the screens and select the planning application to import to.

And click through the remaining screens to execute the migration.

The Reporting migration is similar.  Select all the artifacts you want to import.

And go through the remaining screens to execute the migration.

In many cases, especially where you are keeping two identical environments in sync, these migrations should go smoothly and complete without error.  However, at other times, especially when doing an initial migration or one where the security will be much different from one to another, you may have to make several passes at the migration.  When even one item fails to migrate successfully, LCM will send back a status of “Failed”.  Click on that link in the status report and LCM will tell you what items failed to migrate.  All other items will usually have migrated successfully.   You will then have to figure out why the item failed and either fix the problem, work around the problem or ignore it and migrate the item another way.

Here are some things I’ve found which will cause you problems in using LCM:

  • In exporting a planning application with many substitution variables, the EXPORT failed – refusing to export all of the variables.  This was worked around by exporting only the variables and then exporting everything except the variables.
  • OR, you can play with the group count/size settings as well as report and log files location within the migration.properties file.
  • Default settings usually are:
  • grouping.size=100[mb]
  • grouping.size_unknown_artifact_count=10000
  • Using “All Locations” in HBR will cause failure for those forms.
  • Essbase server names—if not same in source & target, you will have to modify the import files for target name.
  • Report Name Length is limited to 131 characters less folder name.
  • Dim members “Marked for Delete” won’t migrate.  You will have to delete them using a SQL query if you want them migrated.
  • Form folders may get re-ordered on migration.  You can work around this by manually adding the folders to the target application in the proper order.  LCM will not reorder existing folders.
  • Doesn’t support parentheses ( ) in form names.  You won’t get an error indication in the export/import – the forms just won’t be there in the imported app.  You’ll have to rename the forms to get them to come over.
  • Member formulas need to be in planning – if just in Essbase they don’t come over.  If this is a one-time migration you can use the EAS migration utility to bring the outline over after the LCM migration.
  • You must manually delete Shared Services groups in the target app if you deleted them in the source app (or they will remain).
  • Reports – you must manually update the data source in the target.
  • Members don’t come over with certain special characters.
  • Doesn’t support Clusters; must use the outline as HBR location.
  • Global Variables with limits in their definition don’t work.

Well, now you should be able to use LCM and judge for yourself whether it is right for your application.  In another BLOG I’ll show how to run LCM in a lights-out mode and also how to do some modifications to the export files so you can do things like sharing dimension detail between planning applications.