Friday, January 17, 2020

Cumulative Feature Overview - Updated for EPM 11.2

Oracle's Cumulative Feature Overview web page now allows you to compare prior releases against 11.2.

Sadly, when I picked the core modules HFM, Planning and Essbase, I didn't see anything about features removed (Simplified Interface, Workforce Planning, CapEx Planning, etc).

It isn't surprising no changes are listed for Essbase.  Essbase 11.2 is actually Essbase 11.1.2.4.033 under the covers.  (Looking at the Essbase client DLLs tells you exactly this)

I do see a 2 tuning confirmation options mentioned for HFM.  Here's a direct copy & paste:

"Two new configuration settings have been added for calculations.  MaxNumConcurrentCalculations - The maximum number of concurrent calculations allowed per server per application. The default value is 8.
ConcurrentCalculationWaitTimeInSecond - If the maximum number of concurrent calculations are running and a user launches a new calculation, the system will wait until the timeout and log a message in the system log about the timeout with the POV details. The default value is 30 seconds. If the maximum number of concurrent calculations are running and ConcurrentCalculationWaitTimeInSecond = -1, and a user launches a new calculation, then the system will wait infinitely until one of the calculations finishes."
An HFM Task Option feature is also mentioned. Quote:
"In Task Audit, the system now generates entries for Journal Period Opened, Journal Period Closed, Data Locked, and Data Unlocked. Each lock and unlock audit event will have a description indicating which cell or cells were locked or unlocked, including the Scenario, Year, Entity (and descendants if applicable), and Period."
Everything else I noticed pertains to the back-up technology uplift to Ora

Tuesday, January 14, 2020

Windows 7 End of Life is Here

One of my colleagues shared his post about Windows 7 End of Life so I thought I'd mention it here.  I work with some customers who still have Windows 7 in their environment, whether it be physical desktops/laptops or virtual desktops (e.g. VDI).

Windows 7 is due to hit Microsoft End of Life today... January 14, 2020.

No pressure, right?

Fortunately, both Hyperion / Oracle EPM 11.1.2.4 and 11.2 work with Windows 10.  EPM doesn't care which desktop operating system you use if you're only using Oracle SmartView for Office and EPM Workspace.

If you're on EPM 11.1.2.4 and want to migrate to Windows 10, you may want to check out this Oracle Knowledge Base article:

"Enterprise Performance Management 11.1.2.4 Certification for Windows 10 with IE11 (Doc ID 2085672.1)"

I'm not aware of any Windows 10 caveats where EPM 11.2 is concerned.

Wednesday, January 8, 2020

EPM 11.2 References to Java 6 Not Completely Eradicated

In troubleshooting why Planning RMI Registry won't bind to port 11333 and throws a "could not find the service start class" error in the Windows Event Viewer, I did some digging and noticed several places where either jdk160_35 or JRE\Sun\1.6.0 are still referenced.  This might not be my problem, but it led to some interesting research.

Without further ado:

\Oracle\Middleware\EPMSystem11R1\common\config\11.1.2.0\setJavaRuntime.bat

if exist "%EPM_ORACLE_HOME%\..\jdk160_35" (
set JAVA_HOME=%EPM_ORACLE_HOME%\..\jdk160_35
if exist "%EPM_ORACLE_HOME%\common\JRE\Sun\1.6.0" goto okSetJRE160

\Oracle\Middleware\EPMSystem11R1\common\RMI\11.1.2.0\InstallHyperionNTServiceRMI.bat

set JVM_HOME=%EPM_ORACLE_HOME%\common\JRE\Sun\1.6.0\bin\client

\Oracle\Middleware\EPMSystem11R1\products\FinancialManagement\Utilities\MetadataMerge\MetadataMerge.bat

set JAVA_HOME=%EPM_ORACLE_HOME%\..\jdk160_35

-----------------

Now let's pick this apart a little.

%EPM_ORACLE_HOME%\..\jdk160_35 does not exist in EPM 11.2.  The setJavaRuntime.bat script thus fails over to the Sun 1.6.0 JRE instead.

%EPM_ORACLE_HOME%\common\JRE\Sun\1.6.0\bin\client does exist in EPM 11.2.  In the same JRE\Sun folder there's also a subdirectory for Java 8 in 11.2.  In the case of InstallHyperionNTServiceRMI.bat, however, we can't just swap out the reference to 1.6.0 to Java 8, as if you look closely at the script, all it wants from the Sun JRE (I believe) is jvm.dll, which resides within a slightly different subfolder.

For some of my customers, the presence of %EPM_ORACLE_HOME%\common\JRE\Sun\1.6.0 will present a problem.  Their IT shops run vulnerability scanners that seek out all occurrences java.exe considered to be vulnerable.

It ought to be OK to swap out the references to jdk160_35 with jdk1.8.0_181, but I haven't had time to fully regression test this.  In 11.1.24, we'd swap jdk160_35 with a generically named jdk7, so as to reduce further script maintenance when the quarterly Java patches come out.  I'm inclined to do the same thing for jdk8, but there are many other things to look into before I pull the trigger on that (Windows Registry, deployment scripts, etc...)


Saturday, January 4, 2020

EPM 11.2: Got it Online!

After taking some time off for the New Year, I finally had time to sit down and research why things we're looking quite right.

The Death Star is now operational!

Now the fun really begins... working through application migrations from an Oracle EPM 11.1.2.4 instance to an Oracle EPM 11.2 instance.

At first glance, Essbase is looking to be a piece of cake.  I need to spend time digging through some of the guides to see how we'll deal with, for example, FDMEE making a big leap from 11.1.1.7-based technology to 12c.

I like how the ODI 12c Console is automatically installed where it is needed. This is nice improvement!