LCM offers a means of migrating Planning applications. When these Planning applications are managed in EPMA, both the Planning tier and the EPMA tier of each application must be migrated. This document explains how to do this, and how to avoid issues caused by dependencies between objects.
This guide assumes that you are migrating applications from one environment to another which is the same version. If that is not the case (e.g. migrating an application from an 11.1.1.0 environment to an 11.1.1.3 environment) then LCM is not supported.
A workaround for such situations is discussed in Note 1187985.1.
How to Migrate an EPMA Planning Application Using LCM
Overview
To migrate a Planning application using LCM, three distinct sets of artifacts need to be exported and imported:
- The application metadata as it exists in EPMA
- The provisioning for this application defined in Shared Services
- The artifacts (forms, task lists, etc) which exist in Planning
Migration of Essbase data is not covered in this article. Data in Essbase cannot be migrated using LCM, and must be exported and imported in the same way as in earlier versions. See the Essbase documentation for more information.
The application must be migrated following a certain sequence, because of the dependencies between each set of artifacts. For example, the application metadata in EPMA must be imported, and the Planning application deployed, before the Planning artifacts can be successfully imported.
I. Exporting from the source environment
- Export the application metadata from EPMA to the file system:
Application Groups > Foundation > EPM Architect > Application Metadata > Planning Applications > Check box for application > Define Migration > Name export file (e.g. ‘EPMA_tier’) > Execute Migration
- Export the application’s provisioning from Shared Services to the file system:
Application Groups > Foundation > Shared Services > Native Directory > Assigned Roles > Planning Application Group > Check box for application > Define Migration > Name export file (e.g. MyProvisioning) > Execute Migration
- Export the Planning artifacts (web forms, security, etc) to the file system:
Application Groups > Planning Application Group > Application Name > Check boxes for all artifacts > Define Migration > Name export file (e.g. ‘Planning_tier’) > Execute Migration
Exports are saved to: %HYPERION_HOME%\common\import_export\\
II. Importing to the destination environment
A. Import EPMA application metadata
The name of the Planning application is embedded in the export files. You cannot change the application’s name during import.
If the application does not exist in the EPMA Application Library in the destination environment when the import is run, it will be created. If the application already exists, you are offered the choice of merging or replacing the existing dimensions with those being imported.
Note that all imported dimensions will be imported as Local dimensions, even if they were Shared in the source environment. See Appendix B below for more details.
- If this is a new application in the destination environment, create a data source so that the application can be deployed to Planning after being imported to EPMA.
- Copy the exported folders from the source environment to the destination environment. Place them in:
%HYPERION_HOME%\common\import_export\\
If you are migrating a Planning Workforce application see Appendix A below before proceeding further.
- In Shared Services, import EPMA metadata from the file system to EPMA:
Application Groups > File System > ‘EPMA_tier’ > Check box for Application Metadata > Define Migration
At this point you can choose to merge or replace existing dimension, decide whether to immediately deploy the application and Rules to Planning after import, and so on. Select the desired options and click Next > Execute Migration.
- The application should now be imported to EPMA and be visible in the EPMA Application Library. If you did not choose to deploy to Planning immediately after import, do so now. Validate the application and deploy. If this is a new application, use the data source created in step 1 above.
B. Import Provisioning
- In Shared Services, import the provisioning for this application:
Application Groups > File System > ‘MyProvisioning’ > Check box for Native Directory > Define Migration
- At this point you can choose to create or update existing users/groups/roles. Select the desired options and click Next > Execute Migration.
- Once the migration is complete, check in Shared Services to make sure that users have indeed been provisioned for the application. If they have not then Planning security (access rights to members, forms, and task lists) cannot be imported correctly.
- Log in to the Planning application and navigate to Administration > Manage Database. Check the “Security Filters” option and click the “Refresh” button. The refresh will synchronize the list of provisioned users and groups in Shared Services (imported in the previous step) with the list of users and groups in the Planning relational database. This will allow migration of Planning security in the next step.
C. Import Planning artifacts and security
- In Shared Services, import Planning artifacts from the file system to Planning:
Application Groups > File System > ‘Planning_tier’ > Check all boxes > Define Migration
- Select your destination Planning application from the list of available destinations. Click Next > Execute Migration.
- Log in to the Planning application and confirm that security has been correctly migrated.
- To confirm that EPMA, Planning and Essbase are all in sync, deploy the application again from EPMA, refreshing the outline in Essbase as part of the process. If this is successful, the application should be fully migrated and working.
Appendix A – Workforce Applications
If the Planning application being migrated is a Workforce application, you may be unable to validate and deploy the application from EPMA in step A-4 above, and receive an error “unable to find members”. This problem does not always occur, and is most common when the Workforce application has been extensively customized.
In such a situation, the migration fails unless a Workforce application with the same properties (Plan Type names, calendar settings, default currency, start year, etc) is already present in EPMA in the destination environment. The workaround is therefore to create such an application. There are two ways to do this.
Workforce migration workaround – Option 1
- Create a classic Workforce application in the destination environment with the same properties as the source application using the classic application creation wizard. Refer to the application in the source environment when selecting the options during application creation, so that you create it with the same options. If you do not have access to the source environment, you can examine the metadata export files (called ‘EPMA_tier’ and ‘Planning_tier’ in the steps above) in a text editor. The metadata is exported in XML format and contains the application properties
- Once the application has been created, log into it and initialize Workforce
- Using the Application Upgrade wizard (in Workspace, Navigate > Administer > Application Upgrade), upgrade the classic Workspace application to EPMA
- Continue from step A-3 in the instructions above, choosing to replace the existing metadata in EPMA.
Workforce migration workaround – Option 2
- Create an EPMA Workforce application in the destination environment with the same properties as the source application using the EPMA application creation wizard. Refer to the application in the source environment when selecting the options during application creation, so that you create it with the same options. If you do not have access to the source environment, you can examine the metadata export files (called ‘EPMA_tier’ and ‘Planning_tier’ in the steps above) in a text editor. The metadata is exported in XML format and contains the application properties
- The newly created Workforce application will then be deployed
- Continue from step A-3 in the instructions above, choosing to replace the existing metadata in EPMA.
Appendix B – How to make Local dimensions Shared
As noted above, all dimensions in an EPMA application that have been migrated using LCM are imported as Local dimensions in the destination environment, irrespective of whether they were Local or Shared in the source environment. This is by design, and cannot be changed. However, there is nothing to prevent you sharing these Local dimensions again once they have been imported. To do so, follow the procedure below:
- Edit the application in the EPMA Dimension Library
- Right-click on the Local dimension in the application > Share Dimension
- In the options screen, choose to “create a new shared dimension” if the dimension does not already exist in the Shared Library. Choose to “merge as shared” if the dimension already exist in the Shared Library and you want to merge it with the newly imported dimension. Choose to “replace” if you want to replace the dimension in the Shared Library with the newly imported dimension.
Oracle EPM/BI 