Wednesday, August 30, 2017
This worked in PSUs 184.108.40.206.700 through 220.127.116.11.705.
I've opened an SR with Oracle and will share the solution once it is discovered.
Tuesday, August 29, 2017
Oracle published a workaround for this a while ago, in the form of the ESSCMDQ utility. Once installed and we automate the suggested ASO restructure script, this was a reliable way to avoid the 255 limitation.... until very recently!
A few patches ago, ESSCMDQ started behaving... erratically. Sometimes the restructure script would complete, and other times ESSCMDQ would crash. The crash message would complain about a DLL within the Microsoft Windows version of the 18.104.22.168 Essbase Client, such as ESSOPGN.dll.
It just so happens that Oracle discovered this and published an update, but you have to dig for it within the Knowledge Base!
The Knowledge Base article # on support.oracle.com is "2273191.1". This article acknowledges the bug and includes a download link to a version of ESSCMDQ.exe recompiled for Essbase 22.214.171.124.015 and higher. Unfortunately, this version isn't included on the main download page for ESSCMDQ.
Oracle is issuing patches for on-premises Essbase 126.96.36.199 at the pace of about once every 2 months. Since 188.8.131.52.0 first came out, as of this writing 19 cumulative patches have been issued for Essbase. This means if you are using ASO and are on 184.108.40.206.015 through 220.127.116.11.019, you will want to hit the "2273191.1" article and grab the newer version of ESSCMDQ.
Friday, August 11, 2017
The frustrating thing is the window renders correctly in IE8. What's going on here?
When we migrate a Planning application via LCM from one environment/version to another, the Application Properties are typically included within the migrated artifacts. ORACLE_ADF_UI = false is the culprit here!
"Sherman, set the wayback machine to Hyperion Planning patch set 18.104.22.168.300!"
When Oracle rolled out PSU 22.214.171.124.300 for Planning, they introduced the ADF user interface. This interface is what we know and love today in 126.96.36.199. Back in the 188.8.131.52.300 days, however, some people were still using browsers older than IE9, which couldn't fully utilize ADF. So as a workaround, Oracle documented a method to deliberately disable ADF. By manually adding the ORACLE_ADF_UI property and setting it to false, one could force Planning to behave as it did in releases prior to 184.108.40.206.300.
The problem here is IE11 doesn't know how to render the Member Selection pop-up window when ORACLE_ADF_UI is present and set to false.
A few final notes:
When either deleting this property or changing it from false to true, it is necessary to stop and restart the Planning web service before the change takes effect.
Oracle also advises that once we are running in ADF mode and new Planning web forms are designed, it is not advisable to revert back to non-ADF mode. The forms you built in ADF mode might not render the way you intend when you revert to non-ADF mode.
Saturday, August 5, 2017
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 220.127.116.11'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.
Friday, August 4, 2017
The Observed Symptom
An upstream system automatically provides ASCII text files for FDMEE to load. The timing of the delivery varies from day to day, so a batch process is kicked off by the Windows Task Scheduler to continually check for the files' presence and process them when discovered.
On an intermittent basis, the FDMEE load doesn't properly complete. The files are detected, the FDMEE load is attempted and fails, and then the files are moved into an archive folder by the consultant's DOS wrapper script.
Root Cause Analysis
The consultant setup the FDMEE automation via a Windows Task Scheduler job, which triggered to run "On Startup". The script loops with a 60 second pause. Once files are detected in the expected folder location, the pre-delivered FDMEE load utility is invoked. The files are moved into an archive folder after this runs.
Unfortunately, the FDMEE server was rebooted via Windows Update. Some time after the reboot, the files were delivered and picked up by the automation, but FDMEE has not yet finished its Oracle WebLogic startup sequence.
Plain English: The FDMEE's load utility couldn't process the file, since FDMEE wasn't online.
FDMEE 18.104.22.168 is one of the services that takes the longest to complete its WebLogic start-up sequence. Depending upon the computing resources available, this can require 3-5 minutes or longer.
When FDMEE is fully initialized and ready to accept connections, the system is listening to TCP port 6550 (this is the default FDMEE port unless someone changed it).
We add 1 line to the top of our FDMEE automation wrapper script:
Next, we create the WaitForFDMEE.ps1 script. Here is the script in full:
# This script loops until FDMEE's port is online.
# If you receive a security policy error about “unsigned” Powershell scripts when
# running this process, open a command prompt and type:
# powershell.exe Set-ExecutionPolicy Unrestricted
# Written on 08/04/2017 by Dave Shay (Datavail)
# Modified on MM/DD/YYYY by Your Name - Briefly list changes
$ErrorActionPreference = "SilentlyContinue"
# Loop forever until FDMEE is online
$socket = new-object System.Net.Sockets.TcpClient("localhost", 6550)
if ($socket -eq $null)
write-host "FDMEE isn't fully initialized yet. Sleeping 20 seconds..."
powershell.exe Start-Sleep -s 20
} until ($socket -ne $null)
write-host "FDMEE is ready to accept connections."
Finally, we copy & paste this line to the command prompt. This prevents a Powershell security error. We only need to issue this command one time.
powershell.exe Set-ExecutionPolicy Unrestricted
And that's it! The FDMEE automation wrapper script now sleeps until it detects that FDMEE is online.