Oracle EPM 11.1.1.3 - Life Cycle Management - Part1 - Essbase Migration

One of the major issues that i commonly encountered while doing 9.3 based essbase implementations was the fact that there was no built in utility within the Hyperion stack that could migrate various applications from a Development to a Test/Production machine(not essbase alone but also other related components like Shared Services etc). I still remember a big rollout almost a year back, wherein we had to document a whole list of steps (manual as well as automated ones) just to migrate a set of BSO & ASO cubes (along with some HFR reports) from one machine to another.

The biggest compelling feature, in my opinion to upgrade from 9.3 to the EPM 11 release is the inclusion of the new Life Cycle Management utility which makes the process of migration from one machine to another all the more smoother. Not that this utility works perfectly or isnt without bugs, it is nevertheless a significant leap from the older 9.3 release and can drastically reduce migration times/effort involved.

The 2 common issues in the 9.3 release was

1. There was no automated way of migrating shared services users/groups/provisioning information from one machine to the other. There did exist a CSV/XML import-export utility but it was never straight forward to use. Just to work around this we had to build a custom JAPI based User/Group extractor.

2. There was no automated way of migrating Essbase artifacts without doing copying from the file system (Outlines, rule files, calc scripts etc). EAS does provide an option to copy applications across multiple servers but unfortunately cannot be automated out of the box. Even if we can somehow automate it by reusing the EAS Jars, we cannot reuse the same scripts without modification across environments.

Now only if we could have a similar such utility in BI EE, it will make the process of migration all the more smoother. Anyway i am digressing. Today, i will demonstrate how this utility can be used to migrate Essbase applications from one environment to another.

LCM Utility supports 2 kinds of migration

1. Application to Application Migration - If you have multiple instances of Essbase registered in a single shared services instance, then this migration automatically migrates the Essbase Application & Database Artifacts to the other Essbase instance through the common Shared Services CSS.

2. Application to File System Migration - This is the most common case. If you have multiple instances of Essbase registered in different shared services instances then this utility migrates all the necessary artifacts on to the file system. Then we need to move the extracted artifacts to the target machine and then run the utility again which will reimport the application in the target machine.

I will demonstrate the 2nd type of migration for Essbase as that is the most commonly used one. We start with migrating a very simple database Sample->Basic. The migration can be executed directly from shared services or can be remotely executed using the LCM utility. But for either of them to work, we will need something called as a Migration XML. This XML basically defines the source and target artifacts that we will be migrating from/to. This XML is created from Shared Services by navigating to the corresponding Application Group that we would like to migrate

In the screenshot above, we have basically chosen all the artifacts corresponding to the Sample->Basic database. One very good thing about this is, it migrates the security & Substitution variables(which are not stored as separate files but are created through MaxL) as well. All the major artifacts are identified using the file extensions. This does not support data migration i.e if your cube has data in development, the LCM utility will not migrate the data to the test/prod machine. We will have to do that manually. Also, Partitions will have to be recreated manually in the target instance using MaxL. Once the artifacts are chosen, we need to click on "Define Migration" to specify how we would like to migrate the Sample->Basic database artifacts.

We shall choose the file system migration for the Destination as shown above. We can specify any folder name here. This will in turn create a folder under {HYPERION_HOME}\common\import_export&lt;user>@<Directory>&lt;foldername>. The folder will be created only when we execute the migration. Currently we are just defining the XML for the migration. Once we have defined the destination options we need to save the MigrationDefinition XML

<Package name="web-migration" description="Migrating Product to File System">
    <LOCALE>en_US</LOCALE>
    <Connections>
        <ConnectionInfo name="MyHSS-Connection1" type="HSS" description="Hyperion Shared Service connection" user="" password=""/>
        <ConnectionInfo name="FileSystem-Connection1" type="FileSystem" description="File system connection" HSSConnection="MyHSS-Connection1" filePath="/SampBasic"/>
        <ConnectionInfo name="AppConnection2" type="Application" product="ESBAPP" project="Essbase:oraepm2.venkatlap.com:1" application="Sample" HSSConnection="MyHSS-Connection1" description="Source Application"/>
    </Connections>
    <Tasks>
        <Task seqID="1">
            <Source connection="AppConnection2">
                <Options/>
                <Artifact recursive="true" parentPath="/Databases/Basic" pattern="*"/>
            </Source>
            <Target connection="FileSystem-Connection1">
                <Options/>
            </Target>
        </Task>
    </Tasks>
</Package>

Once the migration is complete you will notice that all the Essbase artifacts will now have been copied over to the File System directory we specified before

To migrate this to another Essbase instance, we can zip the entire File System folder that was created and then move it over to the target machine. We also will have to copy the Migration XML as well. To complete the migration we will have to modify the XML a bit to cater to File System to Essbase migration. The modified XML is given below

<Package name="web-migration" description="Migrating File System to Essbase">
    <LOCALE>en_US</LOCALE>
    <Connections>
        <ConnectionInfo name="MyHSS-Connection1" type="HSS" description="Hyperion Shared Service connection" user="" password=""/>
        <ConnectionInfo name="FileSystem-Connection1" type="FileSystem" description="File system connection" HSSConnection="MyHSS-Connection1" filePath="file:/u01/app/SampBasic"/>
        <ConnectionInfo name="AppConnection2" type="Application" product="ESBAPP" project="Essbase:oraepm2.venkatlap.com:1" application="SampLCM" HSSConnection="MyHSS-Connection1" description="Source Application"/>
    </Connections>
    <Tasks>
        <Task seqID="1">
            <Source connection="FileSystem-Connection1">
                <Options/>
                <Artifact recursive="true" parentPath="/Databases/Basic" pattern="*"/>
            </Source>
            <Target connection="AppConnection2">
                <Options/>
            </Target>
        </Task>
    </Tasks>
</Package>

Remember you will have to modify some of the config files(sourceInfo.xml etc) in the extracted files to support target updates. To import the Sample->Basic application we just have to call the LCM utility directly from command line. This facilitates integration with external schedulers so that we can do the migrations at regular intervals. Also supported is a Java API, so that external applications like ODI etc can call this.

This is pretty straight forward and works pretty well too. But the actual interesting part is in migrating shared services users/groups. This is where it can become tricky. In a couple of my installs, the exports worked absolutely fine but the import process corrupted the entire shared service instance. I observed this on a couple of my OEL-EPM-Weblogic instances. I might have to log this as a LCM bug. But i will cover a workaround in my next blog entry and show how users/groups can be migrated from one instance to the other.