Saturday, October 17, 2020

EPM Is Available on Oracle eDelivery

The EPM Certification Matrix has been updated for on-premises Hyperion / OracleEPM

The online Feature Comparison Tool hasn't been updated as of when I checked earlier this morning.  The README, however, lists a boatload of bugfixes.  HFM shops should inspect the README carefully and allow sufficient time for rigorous regression testing.

There's about 2GB remaining in my download queue, and then it will be time to take it for a spin.

Initial observations:

  • Still no certified migration path from and older.
  • The certification matrix says HFM isn't available for Linux 7 yet.  Fortunately, I don't have any customers screaming for this (yet).  I do have customers who've expressed interest in running Essbase on Linux 7 instead of Linux 6.  Linux 6 is a dead product and Linux 7 has faster disk I/O drivers, among other improvements.
  • Installation media is only available for 64-bit Microsoft Windows and Linux 7.  Solaris and AIX ("AIX ain't UNIX") aren't listed.
  • In-place "Apply Updates" upgrade available if you're on on through
  • The LCM bug for Google Chrome has apparently been fixed.
  • The README provides the workaround for Planning RMI not binding to its port.
  • No mention if the FDMEE Linux bugs have been fixed or not.
  • The README explains why I can't login to EAS; an Oracle WebLogic policy update is needed.  The problem may have been introduced in, as my sandbox works just fine.
  • The README has a very important note about LDAP hosted through MSAD; every Microsoft shop will need to get in front of this before Micosoft forces our hand in 2021.

Sunday, October 11, 2020

FDMEE, Linux, and numerous bugs - UPDATE

As mentioned in my previous post, I was able to spend this weekend doing some R&D in Hyperion / Oracle EPM in Linux instead of doing heads-down customer-related work.

One of the items re-visited were the numerous bugs encountered with FDM Enterprise Edition (FDMEE).  These bugs are specific to the Linux edition of EPM; the Windows edition of the same release works just fine.  To see all of the gory details, expand August 2020 on the right-hand side of this page to see my 3-part series about the FDMEE bugs in Linux.  Part 1 of the 3-part series starts here.

If you're impatient and wish to avoid going through all of the error evidence, I can summarize FDMEE's problems in 2 major categories:

  1. When running "Configure Database" for FDMEE, many dozens of ODI tables are missing.  The ODI Agent is thus unusable when FDMEE attempts to invoke it.
  2. When running "Deploy to Application Server" for FDMEE, WebLogic's configuration is incomplete.  The FDMEE process starts and WebLogic says it enters RUNNING mode, but is essentially useless.

Again, for the sake of clarification, the above 2 problems are specific to FDMEE hosted in Linux.

Here is the quick & dirty solution I tested this weekend, and it worked perfectly for me.  I hope this helps you, too!


Create a throwaway virtual machine running Microsoft Windows Server 2016 or 2019.  Download HFM Plus and install it.  You do not need to create a database or run configtool; completing the install for FDMEE is enough.

On your Linux FDMEE server(s), stop FDMEE and rename these 2 things:

  1. aif.ear within the Middleware/EPMSystem11R1/products/FinancialDataQuality directory structure.  It is easy to find if you're not familiar with the back-end filesystem.  Just cd to the folder I just mentioned and type:  find . -type f -name aif.ear
  2. Middleware/odi

Point of clarification: I can't say for sure that aif.ear is contributing to the problem.  I can say with high confidence that Middleware/odi has problems in EPM's Linux edition!

Now grab the same 2 things from your Windows filesystem.  In the case of Middleware\odi, you'll want to zip it up in Windows and unzip it in Linux.  If FDMEE is clustered across multiple servers, do this on each.

Once the above is done, launch in Linux and re-run both Configure Database and Deploy to Application Server for just FDMEE.  Pick all options again even though they have the green checkmark.  When Configure Database asks if you want to Drop & Create or Re-Use, pick the Drop & Recreate option.  If you have FDMEE clustered across multiple servers, do Configure Database on just one of them, and Deploy to Application Server on all FDMEE servers.

Once configtool is complete, check your FDMEE database/schema.  All of the SNP* tables that were missing before ought to be present now.

rm -rf ErpIntegrator*/tmp and ErpIntegrator*/cache

Restart FDMEE and regression test.  Middleware/user_projects/yourinstance/bin/ ought to come back green now where FDMEE is concerned.

If this blog entry does not help, I implore you to open a Service Request with Oracle.  As of this writing, there are still no patches out there for either Hyperion Infrastructure (installtool+configtool) or FDM Enterprise Edition for 11.2.x.  With for Linux being so new, and many companies not having an EPM upgrade budget approved for Fiscal 2020, Oracle may be unaware of this issue.  There will likely be a deluge of bug reports once Fiscal 2021 rolls around!

The 11.2.x upgrades my team & I performed thus far either haven't included FDMEE, or had FDMEE exclusively on MS Windows.  So I could open an SR now about the issue, but the SR wouldn't have the same standing as if the problem were holding up a customer's upgrade project.

Provider Services, Linux, and the WebLogic bug - UPDATE

I posted previously about my adventures working with Hyperion / Oracle EPM in a Linux environment.  One thing that stood out, which I've reproduced and have also received confirmation about from some of my commenters here, is Analytic Provider Services (APS) produces a WebLogic error message during APS's startup sequence.

The error message is hard to decyper, but it essentially complains that something is misconfigured within the aps.ear file.

This error does not happen in the Windows counterpart of EPM

I discovered the following 2 solutions during my regression testing, and wanted to share.  So here goes!

Solution 1

Stand up a little throwaway Windows Server 2016 or 2019 virtual machine.  Install Essbase Plus  In installtool.bat, just pick Foundation and APS.  You don't need to configure/deploy.  Just the install is sufficient!  Once APS is installed, stop APS on Linux and then copy aps.ear from the Windows VM to your Linux server.  Clear AnalyticProviderServices0's \tmp and \cache subfolders.  Then restart APS in Linux and you should be good to go.


Solution 2

APS is actually a patch within the stack.  The patch is over one year old ( or  The Linux version of this specific patch is apparently problematic.  In Linux, download and OPatch a higher series of patches for the Essbase stack, such as or as of this writing.  You will need to patch the entire Essbase stack: Essbase Agent, Essbase Runtime, Essbase Client, APS, and EAS Server.  The APS patch notes tell you which patches are certified for the specific patch version you decide to grab.

Stop the stack, run OPatch for the patches where needed, clear /tmp and /cache for each web service you patched, and restart.  No need to reconfig/redeploy.

My results

I've done both Solution 1 and Solution 2 within different test sandboxes.  Both worked for me.

Take care with respect to Solution 2 if you're running Essbase ASO cubes.  If you read through the patch notes from through, you'll see lots of issues relating to ASO.  I suspect the Essbase developers at Oracle aren't done tweaking ASO yet.