Cloning FDMEE Application by Relational DB copy

This article was **originally published on my LinkedIn Pulse page** on Jun 2016

This article is written to outline steps to clone FDMEE application using alternative method via Relational Database copy which has some advantages over the LCM method.

LCM Clone

To clone FDMEE application, the recommended approach by Oracle is to use LCM (Lifecycle Management). Trying this approach in version 11.1.2.3.500 — for cross environments migration — LCM worked okay with some drawbacks:

1. The database Unique Identifier such as Partition Key and other keys are not going to be identical in the source and target application; making later task such as migrating maps across applications have to involve manual work such as identifying the partition key.

2. The Import format relies on Unique Identifier to define the order and due to the issue mentioned at #1, the dimensions that concatenates multiple columns in the source file will not always be in the correct order.

Relational DB Clone

To circumvent the above drawbacks, I’m going to try the method that I’ve used in the past for FCM Classic by going through Relational Database clone, and I assumed this method would work in FDMEE.

Step 1: Backup the relational DB in the source and the target FDMEE application.

Step 2: Shutdown the FDMEE service hosting the target FDMEE and restore over the source DB to the target FDMEE relational DB. Start the service.

Step 3: Login to workspace and go to FDMEE menu. Go to Setup — System Settings — change profile type to ‘File’. Update the application root folder to the root folder designated to that application (make sure that root folder is granted Read/Write access to ‘Everyone’). You will want to click the “Create Application Folders” if it’s a new location.

Step 4: Still at System Settings, select profile type — ‘ODI’. Change the connection settings for the new FDMEE database. You want to fill-up the red boxes below with the Database name, and DB login information.

Step 5: Do file system copy from the source and new application folder. At the minimum you want to copy the <<Application_Root_Folder>\data\scripts to bring over the scripts from the source application to the target application.

Step 6: You may need to update the target Hyperion applications of the FDMEE if you’re cloning the application to target different environment / Hyperion applications. To do this : Access the relational DB via SQL Developer / Management Studio (in my case, I’m using MSSSQL). Find the SQL repository of the cloned/new FDMEE application and go to table ‘AIF_TARGET_APPLICATIONS’. You need to update two columns: ‘TARGET_APPLICATION_NAME’ and ‘APPLICATION_NAME’.

Ready to run FDMEE process?

At this point, I thought everything was done and I could run the integration and things would complete. Nope, apparently trying to run any of the import/validate/export process, the process was stuck in spinning mode with no prospect of completion.

The main difference between FDM Classic and FDMEE is the fact that FDMEE is using ODI at the back end to do ETL processing.

I used ODI Studio to connect to the ODI engine of the cloned application ( Googling-up ‘how to connect to FDMEE using ODI studio’ will show-up couple of articles to do this so I won’t elaborate further ). It soon became apparent that ODI Operator log showed that there was an issue with the connection information supplied to connect to the repository DB in the ODI itself.

Step 7: Update the ODI connection information in the ODI Topology Manager. To do this in ODI Studio, click ODI-Topology manager and double click ‘Microsoft SQL Server’ if you’re using MSSQL Server for your FDMEE DB.

A new window will come up and you will need to supply the JDBC connection information.

Step 8: Rerun your FDMEE processes, it should run successfully now.

Round-up

Copying the application using the relational DB method, you will get near identical applications with identical partition keys.

Please remember though, LCM is still the recommended approach by Oracle to do FDMEE application migration. FDMEE security will also still have to be migrated through LCM since it’s now sitting on Shared Services layer. Additionally, I haven’t tested this method in version 11.1.2.4 so if you get a chance, please let me know if this method works.

As usual, please drop me a note in the comment section if you think I’ve missed some steps since I’d like to learn from the gurus out there.