Since the release of HFM 184.108.40.206, and its change in architecture, many of the utilities that HFM administrators had come to know and love were deprecated from the product. One of the most popular of these utilities was the standalone Copy Application utility. This utility allowed you to do a direct, DB level copy of an HFM application from one environment to another, regardless of the version (you could upgrade the application after the copy) and DB type (in the most recent versions of the utility). It copied all application table contents between the environments, without a need to reload or re-consolidate data. All you needed were two UDLs created on the server that contained the utility, one pointing to the source HFM DB server and one pointing to the destination HFM DB server.
To compensate for this censure of functionality, Oracle added an “Application Snapshot” artifact to the Lifecycle Management export of an HFM application. The HFM Administrator’s Guide adds this note about this artifact:
Application Snapshot migration requires all users to be logged out of the application. The system logs out all users and shuts down the application if there are no active tasks present for the application. The Application Snapshot is exported at the end of the migration after processing other artifacts. When importing, the Application Snapshot cannot be selected with other artifacts; however, if the application does not already exist in the target, you must include the application definition artifact to create the application shell.
To reach similar functionality as the old Copy Application Utility, the Lifecycle Management export and import process of this Application Snapshot is a bit ‘temperamental’ in my experience with it. The downsides of this Application Snapshot artifact are:
- Large applications require more time to export than you may be accustomed to
- Requires a lot more space on the file system where the LCM export will be exported to
- Requires a second import step that, potentially, could take just as long, or longer than, the export step
I’ve found that the only real benefit is that, since this is an LCM artifact, it is database type agnostic and you can export and import between different DB types (Oracle to SQL or vice versa). Converting applications to use different DB types is not something that happens every day.
With the release of HFM 220.127.116.11 PSU 200, Oracle has added in an “Import Application” program/utility built in to the ‘Consolidation Administration’ screen in Workspace. This new utility returns most of the old Copy Application utility functionality to you. It basically does a straight copy of the source application’s tables, much like the old Copy Application Utility did, and it does work pretty well.
Note: If you are trying to copy an EPMA application, unlike the old Copy Application Utility, you will not receive a warning that you are trying to copy/import an EPMA application. With that, you will need to do the following, much like the old requirements:
- Run the utility, to copy/import the application
- Run the ‘Transform Classic to EPMA’ application wizard from Workspace
- Take an EPMA application LCM export from the source application and import it to the target environment
- Redeploy the application from EPMA, to re-sync metadata
An additional note for those considering using the new utility to upgrade applications from a previous 11.1.2.x release: I did test copying an HFM 18.104.22.168 classic application. It does seem to work fine. To verify that the application was up to date, I ran the ‘Upgrade Applications from Earlier Release’ task from the EPM Configurator on the HFM server. There were no issues. However, I haven’t heard of a stance from Oracle on whether they will support using this methodology for an application upgrade or not, so, proceed carefully.
Here are the procedures for using the Import Application utility, against an Oracle DB. Prerequisite: The Oracle DBA must grant CREATE DATABASE LINK privileges to the HFM schema, in the target Oracle DB. Run the Oracle_Create_ImportApp_package.pck file, delivered with HFM 22.214.171.124.200, once, in SQL Developer:
After successful execution, the new package, HFMUTIL_PKG, will show up under the HFM schema’s available packages, in SQL Developer. If you see the green dot showing on the package, right click and click Compile. If the green dot is not there, there is no need to do this step:
Once properly compiled, the package will appear like this:
Create a database link to the source environment’s HFM schema on the source environment’s DB server, using the following syntax:
Create database link linkname CONNECT TO SourceHFMschemaname IDENTIFIED BY SourceHFMSchemapassword USING ‘//SourceDBHostName:SourcePortNumber/SourceServiceName’;
Upon successful creation of the database link, login to Workspace and go to Navigate -> Administer -> Consolidation Administration, then click on Import Application. The Database link should be available and a dropdown list of the source environment’s HFM applications should be available.
Select the Source Application you wish to copy, then enter the name you would like the application to be named in the target environment, as well as the description. Then select the HFM cluster and the Shared Services project that the application will be placed under. You can then select what data you would like to copy from the source application to the target, including Audit information, All Data or you can choose to filter what data to copy, based on a Scenario and Year combination.
Prior to execution, ensure that the application is in admin mode, and no users are working in the application, and then click ok.
You will then be taken to the Admin Tasks screen to monitor the import process.
Upon completion, the application should be available and be identical in the target environment. Provisioning will then need to be completed, to the application, for the users/groups needing access. (Note: The source application should not have to be HFM 126.96.36.199.200, it can be 188.8.131.52.000 or above.)
Oracle has also made available Patch 22046375, which is a Patch Set Exception for HFM 184.108.40.206.700. This is an updated version of the classic copy application utility which will work with HFM 220.127.116.11, much as in previous versions. This was the interim solution that Oracle provided prior to making this new UI based utility available. The strategic direction of Oracle is to use the new utility, but, the option is there to use either utility, for the time being. How long Oracle continues to support the classic utility remains to be seen, but, with new releases and patch sets coming in pretty rapid fashion, it’s best to be prepare for the future of only having the new utility at hand. Additional enhancements may come, to bring the new UI utility in to parity with the classic utility. If there is something missing from the utility, that you deem as critical functionality, open an enhancement request with Oracle and I’m sure they will look in to it. The uproar from customers, of totally losing the classic utility, prompted the addition of the new UI based utility, so, there is no reason to believe that Oracle would not listen to your request.
Disclaimer: This article is intended to be a resource only and is not intended to be nor does it constitute legal product advisement. Any recommendations are based on our direct experience in this environment during the time in which this was posted.