I did a near-full stack implementation in a sandbox for Oracle EPM/Hyperion 126.96.36.199 in Red Hat Enterprise Linux (“RHEL”) 7. Essbase, Planning, CalcMgr, Foundation, and EAS all seem to be working fine. HFM, of course, is not available for Linux at this time.
FDMEE, however, has multiple issues and does not work. Clarification: this post is about the Linux edition only. The Windows edition does not have these issues.
A patch also needs to be issued for Analytic Provider Services (“APS”). I managed to get it to work by copying over aps.ear from my 188.8.131.52 sandbox. Unfortunately, this solution won’t help you if you didn’t grab 184.108.40.206 from Oracle eDelivery before it was removed. So, Oracle will need to issue a patch for 220.127.116.11 APS as well.
I’ve downloaded 18.104.22.168 for Windows and will check if that version also has the same issues.
Here’s the initial symptom with respect to FDMEE:
I had deployed it to WebLogic and started it. It binds to port 6550 as it should:
Digging deeper, I found multiple problems behind the scenes. The problems are in two major areas:
- The FDMEE database schema is incomplete; All of the SNP_* tables are missing.
- The WebLogic configuration is completely messed up where FDMEE (“ErpIntegrator” as WebLogic calls it) is concerned.
I had to do quite a bit of “surgery.” At this point, two of three problems as previously reported by the validate.sh utility are now fixed.
So how did I manage to get to this point? Hours of troubleshooting and experimentation.
Let’s first address fixing the lack of SNP_* tables in the FDMEE database schema. When we run the “Configure Database” task for FDMEE, here’s what happens behind the scenes. We can reproduce the issue at will by running the back-end utility manually.
Side note: I edited the utility to add echo statements for “Finished XYZ” so I could see which step was throwing the Java stack trace error.
The assertion that the supervisor password is blank is not true. The script follows the same format used in 22.214.171.124, whereby Supervisor’s userid and password are encrypted and hard-coded within the script.
This is not an issue in 126.96.36.199, 188.8.131.52 and 184.108.40.206. While 220.127.116.11 and 18.104.22.168 are no longer available for download from Oracle eDelivery, I downloaded both releases when they were available, and I have an 22.214.171.124 sandbox online for reference purposes.
In crawling through the various jar files in 126.96.36.199, I found the offending class oracle.odi.setup.suppoort.MasterRepositorySetupImpl is located within Middleware/odi/sdk/lib/odi-core.jar.
When comparing 188.8.131.52 Linux vs. 184.108.40.206 Windows, I found size and timestamp mismatches between the two systems:
- 2.1.0 Windows: 29,222,611 bytes dated Feb 1, 2020
- 2.2.0 Linux: 29,032,586 bytes dated Aug 22, 2017
So, I backed up Middleware/odi/sdk in 220.127.116.11 and then copied over the whole directory structure from 18.104.22.168. I reran the utility in my screenshot above, and now all of the SNP_* tables are present.
So, in the EPM 22.214.171.124 Linux installer, the subdirectory “odi” is apparently packaged incorrectly and we need a patch for that.
Part 2 will address issues uncovered within WebLogic.
Cross-posted from EPM On-Prem Pro. Read the original post here.
Subscribe to Our Blog
Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.
EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.
Curious about Oracle’s new Enterprise Data Management Cloud Service? Get the full scoop in Datavail’s latest blog post.