Friday, July 30, 2021

EAS Console, EPM 11.12.4.x, and Java

One of my colleagues hit the following issue in his Hyperion / Oracle EPM system earlier today, and reached out for help.  We got it fixed in just a few minutes, and here's the fix.

Root cause:  You've just patched your Essbase Suite to, uninstalled your EAS Console and installed the new one.  The EPM servers themselves are still running and an older version of Java.  The issue described herein doesn't apply to EPM 11.2.x.

Symptom:  On a server (we often test directly on the servers), we double-click the EAS Console thick client launcher, and see a message that looks like this:

You are using older java version 1.7.0_***
Install JDK8 and set JAVA_HOME variable to JDK8 installed location

Depending upon the status of your EPM system, that first line will say either 1.6.0_updatelevel or 1.7.0_updatelevel.

I advise against following some of the blogs and tutorials online concerning this issue.  Here's why:

The blogs and tutorials are essentially telling you to use the Windows Control Panel to set a JAVA_HOME variable that points to the parent folder of a Java 8 "\java\bin" folder.

Don't do this on an server! isn't fully certified for Java 8.  Setting a JAVA_HOME variable that's pointing to a Java 8 could spell disaster the next time you start up Hyperion services or run Hyperion tools.  This entirely depends upon how your EPM system is setup.  Some EPM Infrastructure consultants can get... creative.  In some cases, the WebLogic scripts and other EPM software check if a JAVA_HOME variable is already set, and if so, it sets the variable for the process being started to whatever \Oracle\Middleware\EPMSystem11R1\common\config\\setJavaRuntime.bat defines.

I'd need to spin up one of my mothballed sandboxes to see if this situation breaks the system or not.  As I'm focusing exclusively on EPM 11.2.x now, I might not have time for this.  Perhaps others can test and comment below!

I'm also concerned about other software IT or anyone else may have installed on the server.  They might not like a JAVA_HOME pointing to a Java 8.

Quick Solution: Download a Java 8 from Oracle Support.  EAS Console doesn't require a JDK to function, so you can grab your choice of either JRE 8 or JDK 8.  Install it and let it go to the C: drive using the default suggested directory location.

Again, let it install to the C: drive.  Don't be tempted to overlay the jdk in your \Oracle\Middleware folder.

Now launch Windows Explorer and navigate to the Java folder you installed on C.  Copy the complete folder path to your clipboard, such as C:\Program Files\Java\jdk1.8.0_xxx

Now the final step.  Edit the EAS launcher script.  By default it would be 

Look for these lines:

    set PATH=%JAVA_HOME%\bin;%PATH:)=^)%

Immediately before this, add 1 new line like this:

SET JAVA_HOME="C:\Program Files\Java\jdk1.8.0_xxx"
You need those double quotes due to the space in your path.

Save the script and you're ready to rock & roll.

No messing around with global environment variables, potentially interfering with other apps.  Congratulations, you've just fixed your EAS Console!

Addendum: if on a client workstation, be very wary about installing Oracle Java there.  There's a chance one could run afoul of an Oracle Java license compliance audit, especially if the end-user starts using that Oracle Java for non-Oracle products.  As a workaround for this, Red Hat OpenJDK8 is an acceptable solution.  As OpenJDK is open source and legally free to distribute, you won't run into license compliance issues on non-Hyperion servers.  

I'm no lawyer and cannot speculate on how an end-user's workstation would be treated.... the user is accessing a properly-licensed Oracle product, EAS Console, so there ought not be an issue here.  But again, you don't know what'll happen on that workstation after you walk away!

No comments:

Post a Comment

Thank you very much for your interest in this blog! I hope you're finding it helpful.

Please keep comments relevant to the topic in the post, as this blog is not a free-for-all substitute for Oracle Support or traditional consulting. If you have many questions unrelated to the specific topic at hand, consider contacting me on LinkedIn ( so we may discuss the possibility of consulting.

Commenting on posts older than 90 days unfortunately goes into moderation, thanks to spammers who've been hitting this blog. Please have patience, and thanks for your understanding!

Comments including URLs linking back to gambling or other things unrelated to Oracle EPM will be deleted on sight. If you're an EPM consultant and are offering me constructive criticism or a tip, go ahead and DO link back to your blog or firm's website if you so desire.

Thanks again for reading!