Traditional relational database backups and routine disk backups / VM snapshots are great things to have automated, but are not sufficient in and of themselves to fully protect your EPM system from disaster.
"Disaster", in the context of this post, is an Administrator or PowerUser doing any of the following:
- Edit the design of a Planning web form, Calculation Manager rule, or Financial Report in such a way that it is no longer usable. Adding insult to injury, the developer doesn't remember which exact changes were made, and there's no Edit->Undo after clicking Save.
- A click-and-drag operation in the EPMA Dimension Library gone horribly wrong.
- Delete a folder hierarchy within Reporting Framework in EPM Workspace. (Yes, it gives an "Are you sure?" prompt, and yes, I've had to do a restore because someone clicked Yes in Production by mistake).
In the case where Reporting Framework is concerned, we additionally need to restore the ReportingAnalysis\data folder on the RAF Agent server, and that needs to be synchronized with the RAF relational restore.
But I digress....
Best practice is to automate nightly exports via Oracle's LCM command-line utility for EPM. If you're unfamiliar with this utility, read LCM user guide Chapter 7.
My personal preference is to maintain multiple rolling rotations of LCM backups. This is because sometimes a problem isn't reported for a few days.
And now we get to the nugget of why I'm writing this post today....
Certain LCM artifacts have extremely deep directory paths. Reporting Framework and Financial Close Management immediately jump to mind. In Windows Server 2008 R2, rotating and pruning the LCM export folders wasn't a problem. But with 184.108.40.206's support for Windows Server 2012, we hit a new issue we didn't have to deal with in the past: Microsoft's deep directory path character limitation.
In Windows Server 2012, try running RMDIR /S /Q on your oldest LCM folder for RAF or FCM. You will likely see a failure message stating the directory path is too deep.
So off we go to our favorite web search engine to find a solution. The 2 most frequently posted solutions are too "clunky" to use, in my opinion:
- Mount a temporary drive to a point in the path before the # of characters reach 255-260. CD to it and delete from there. Then delete the temporary drive.
- Use a tool like 7-zip, which uses a different API and doesn't have the character limitation. You can navigate to the parent folder and shift-delete it, and it is gone.
Create this Jython script:
# rmRotation7.py # # This Jython script removes the oldest LCM backup folder. # We use this technique to work around the Windows Server 2012 # limitation concerning directories containing deep pathnames. # # Written on 11/02/2016 by Dave Shay (Datavail) # Modified on MM/DD/YYYY by Your Name - Briefly list changes import shutil shutil.rmtree('E:/Backup/LCM/Rotation7')
Why Jython? Because that shutil.rmtree function does everything we need with just 2 lines of code, and all modern Hyperion systems have access to Jython!
OK, so how do we invoke it?
Paste these 2 lines of code into your LCM automation wrapper script:
SET CLASSPATH=%CLASSPATH%;E:\Oracle\Middleware\oracle_common\modules\oracle.jrf_11.1.1\jrf-wlstman.jar %JAVA_HOME%\bin\java weblogic.WLST E:/Scripts/rmRotation7.py
The first line is what prepares your DOS shell so that it can run Jython scripts. It does run a little slow and will delay your script for a few seconds. The second line invokes your Jython script and prunes the folder named in rmRotation7.py.
There are other ways to tackle this problem, such as installing 3rd party tools like Cygwin. My preference when working with customers' Hyperion systems is to utilize the framework already available. In my opinion, it makes knowledge transfer and ongoing maintenance a little easier. When we instead install a 3rd party tool, now we've introduced yet another thing we need to potentially patch and maintain.