Art of BI: Hyperion 11 Lifecycle Management (LCM) in Action – Part 1

One of the smartest tools Oracle/Hyperion ever integrated into its product suite was the migration utility. Overtime this has evolved to the LifeCycle Management utility or LCM for short. Actually Oracle/Hyperion has taken it even one step further by calling its fully integrated migration tool the BI+ Artifact LifeCycle Management utility even though they have retained the same acronym, LCM. I saw a job board posting for a BI+ administrator recently that touted knowledge of LCM as a “must-have”. So, between that and a recent client project request, I thought I would shine some light and/or seek to demystify this tool, LCM.

LCM, has actually been incorporated into the Hyperion suite since Hyperion System 9x. I believe starting with 9.3 which is when I started using it. At that point, it was really just a command-line tool. It was very much a kluge and in my opinion, it still is especially after you do the first migration from dev to prod (or whatever you environment structure looks like). I’ll go into that later.

Why do we need LCM?

Technically you don’t. You can get along without it like we did in the previous versions of Hyperion by copying objects and migrating them individually. One could still use the Essbase “Copy…” command in EAS to get a database from dev to prod and vice-versa with no problem. The same goes with getting security from one environment to another although that’s usually a bit more work that simply moving Essbase objects around.

You could even stick with the old Avalanche Migration Utility under Workspace that many of us have come to love and depend on. LCM doesn’t even provide versioning or anything cool like that. So, do we really need it? The answer to that question really depends on the Oracle roadmap. Ultimately, I think in the next few versions it will be the only acceptable means of migrating objects from one environment to another. It would probably be smart to get on board with it now and hope that they add cool features to it in those future releases.

What’s the benefit of LCM in Hyperion 11x?
The benefit of LCM in Hyperion System 11x is that it is now fully integrated with Shared Services (not WorkSpace) since this is an administrative tool. Keep in mind that you can still launch LCM from the command-line but you really need to be an expert with JDBC, XML, command-line syntax, and other development logic in order to make it work for you. Hyperion 11x definitely simplifies this process.

What are Artifacts?

An artifact by definitionis an object that has been created for a practical purpose.  In this case any pieces of your EPM infrastructure that contain meta-data or data.  When you use the LCM tool you are able to select individual objects or artifacts during the migration. For example, one can migrate a single Essbase database instead of the entire Analytics Server’s database.  However, one cannot move an individual report object via LCM. Like the Avalance Migration tool, it is all or nothing for some of the artifacts.  Of course, with HFR reports and the like we know that using the Workspace export tool for HFR reports works just fine anyway.

How does the LCM utility work?

It’s all XML based. That is to say that once you define your migration (i.e.: select which artifacts are to be moved) an XML, file-system based directory structure is created. It is created under the Shared Services directory on the server for which Shared Services resides. Now, here’s the ugly part which is a bit of a kluge. After you define the migration and your XML-based file structure is created, one who has LCM administrator permissions must then manually move the file-structure from one server environment to the other. That can be done either by copying and pasting or via FTP.

In case anyone asks you, in the previously mentioned command-line version you had one additional option for migration. This other option allows you to push the artifacts immediately to the target system from your source system with no extra steps involved if the target and source are on the same network.

Where are the tools located on my system?

The LCM utilities are just batch files that get called when one wishes to execute the tool for operation. These batch files merely launch the java runtime clients and access some JAR files.

• LCM Launched from Shared Services
• [HYPERION_HOME]commonutilitiesLCM9.5.0.0binhsslcmutility.bat
• LCM Launched from Command-Line – Standalone
• [HYPERION_HOME]commonutilitiesLCM9.5.0.0binhsslcmutility.bat
• WorkSpace “Avalanche” Migration Utility
• [HYPERION_HOME]productsFoundationworkspaceMigrationUtilitybinmigrator.bat

Conclusion

If you’ve been on several EPM projects you will know that migrating from development into QA or PROD for the very first time with LCM is no problem at all. This is where the tool, despite its limitations with versioning and its not knowing artifact dependencies, actually makes migration a snap. Oracle has even put together a few documents on Oracle by Example for the different Hyperion suites. These are great for those who need an introduction and a how-to for the tool.

• LCM for Planning – New OBE Link
• LCM for Reporting
• LCM for HFM
• LCM for Essbase – New OBE Link

Here also is the System 9x documentation (PDF) for the LCM standalone command-line utlity.

I believe that LCM breaks down and needs much more hand-holding when migrating artifacts between environments after the first-time migration status. Once there are objects in production that need to move back down to development for testing which ultimately needs to be moved back to production one will need to be astutely involved and have a solid knowledge of the Oracle/Hyperion EPM tools to pull this scenario off smoothly.