As someone well versed in scripting languages, I am usually assigned to task of setting up the automated disaster recovery backups of planning applications at clients. Over the last few years I had been primarily working on 11.1.2.3 systems. I recently performed my first automated LCM backup on an 11.1.2.4 system and there was a small, but important difference.
I’ll walk you through the entire setup process, and note the differences for you.
First, you need to perform a manual Life Cycle Management (LCM) export in Shared Services.
Select all items for export, except the Essbase Data (we usually capture this with a maxl level 0 export)
As a practice, we will name these application exports as follows: Use the prefix of “PLN_”, then the application name.
This screenshot shows the LCM backups of GLPLAN and PROJPLAN
Now that we have an all-inclusive LCM defined export, we need to embed the login credentials into the LCM’s export.xml file. With the credentials embedded it will run automatically when called via a command line command, or similar command line call from a batch script.
Oracle supplies a command line utility to run LCM imports and exports, it is conveniently named, Utility.bat.
You can find it in the “D:\Oracle\Middleware\user_projects\epmsystem1_FND\bin” folder on the Planning server. This utility will execute the Export.xml that is found in the LCM root folder (shown here with PLN_PROJPLAN)
To use the Utility:
1. On the planning server, open a cmd window.
2. Change directory to D:\Oracle\Middleware\user_projects\epmsystem1_FND\bin
3. The command to enter is: Utility.bat
For example: Utility.bat D:\Oracle\Middleware\user_projects\epmsystem1_FND\import_export\PLN_PROJPLAN\Export.xml
4. The first time you execute the utility with this Export.xml file, it will prompt you for credentials to run the Utility.
After you have entered the credentials, they will be saved into the Export.xml file.
Here’s the tricky part.
When the migration runs, it overwrites all files in the Migration folder (including the Export.xml file that we just updated with encrypted credentials).
Since the LCM export takes a 20-30 seconds to run, we have time between hitting Enter after entering the password, and the time the LCM Export completes (and overwrites the Export.xml file with no credentials). I have created a QuickCopy powershell script on the Planning server’s desktop to copy the Export.xml file off to a different folder. It’s much easier to press right-click and select “Run with Powershell”, than try to type this entire statement before the LCM export finishes.
This saved off Export.xml will contain the encrypted credentials. The process for running the LCM export via a batch file will be to copy the “saved-off” version of Export.xml (the one with the saved encrypted credentials) into the LCM migration folder, then run the Utility.bat against the migration folder’s Export.xml.
Comparison to 11.1.2.3
The differences between 11.1.2.3 and 11.1.2.4 are as follows:
1. Version 11.1.2.3 would export the LCM as a zipped file in the import_export folder on the server.
- Because of this, you would need to unzip that file in order to run the utility.bat on the unzipped Export.xml.
- The embedded credentials would be saved in the unzipped version of the Export.xml file.
- When you would run it again, you run it supplying the unzipped Export.xml file, but the LCM export would overwrite the zipped file of the LCM migration.
- This left the unzipped Export.xml file intact.
2. Version 11.1.2.4 exports the LCM as a folder structure, unzipped, in the import_export folder.
- Because shared services does not zip the LCM export, and it overlays the defined migration, you need to capture the Export.xml file with embedded credentials before the LCM migration completes (and overwrites your Export.xml file with no credentials embedded).
- With the saved off copy of Export.xml you have 2 choices:
a) either copy it back into the migration folder before you call it (as I have shown here)
b) another option would be to change the filepath property in the Export.xml so it exports to a different location.
That’s all there is to it. Each time you call utility.bat to rerun your migration it will overlay the previous migration of the same name, so if you want to archive more than one version you need to copy it off to a different location. Oh, and don’t forget a maxl script to export your Level 0 essbase data!
Free eBook Download
In the eBook “Having a Conversation with Data”, learn what the current BI infrastructure has been and associated challenges with the traditional approach. How important the user experience is in order to best maximize data’s value (think visualizations!!) to your organization and how to gain a competitive advantage with modern analytics platforms.
