Sunday, May 16, 2021

Patch 30695700 - Hyperion EPM Architect to DRM Conversion Utility

This post is going to be more painful than the last one I just wrote.

Suppose you are on Hyperion / Oracle EPM or prior, and your metadata is under EPMA's control.  Further suppose you have many applications and converting them all to Classic Mode doesn't suit your business requirements.

You essentially have 2 alternatives to Classic Mode in EPM 11.2.x due to the elimination of EPMA.

1. Switch to the Oracle DRM Limited Use license.
2. Contact Abhi at

That's pretty much it.  If you, my dear reader, have a 3rd option I have not considered for on-premises EPM, please by all means share your solution in the comments!  With upgrades heating up in Fiscal 2021, this topic is going to come up over and over!

What the above out of the way, I'm going to focus specifically on option #1.

There is a patch numbered 30695700.  It is associated with DRM (don't ask me why, as it really applies to an EPM 11.2.x implementation).

This is not a true "Opatch" opatch.  It is a standalone Java utility, and the Java source code is included.

Halt.  Stop right there.  Do not pass Go.  Do not collect $200 USD.

Depending upon which version of EPMA you're coming from, and also depending upon how your multi-line Essbase block storage member formulas are written, the utility crashes within seconds.

Sadly, the README delivered with patch 30695700 contains some rather.... odd... language for a non-certified and unsupported utility.

After the README states the utility is not certified by Oracle and is also unsupported, it includes a prohibition from sharing code modifications/enhancements.

So, I know exactly where in the code the crash issue happens, but sadly I am prohibited from sharing the solution.  I really believe the policy needs to be re-examined by Oracle Support so the EPM community may share knowledge with each other!

Suffice to say, a single-line member formula shouldn't have any problems during the conversion process.  The problem is when a multi-line formula contains empty lines (carriage returns for readability purposes) and the EPMA File Generator _ line continuation character doesn't appear where the conversion utility expects to find it.  That's about all I can say for now.

Quick Tip: Starting OHS 12 in a distributed Hyperion environment

This ought to be a simpler post than what I usually write.

The topic of how to start Oracle HTTP Server ("OHS") 12c in Hyperion / Oracle EPM 11.2.x comes up frequently.  I've previously posted about the little trick, buried within the EPM 11.2.x install/config guide, on how to save the WebLogic password for OHS so you aren't prompted every time you try to start up OHS.

"But hey! Dave, how do we start and stop OHS in a distributed MS Windows Server environment when OHS doesn't have its own Windows service anymore?  The good old NSSM trick we use for WebLogic Admin Server doesn't work for OHS!"

An excellent question.

Login to each OHS host server in your distributed environment as your EPM network service account.  Run the "storeuserconfig" trick to save epm_admin's password in your network service account's profile on the C drive.  Search the install/config guide for the text "storeuserconfig" and it'll take you directly to the needed command syntax.  Every member on your Hyperion support team who wants to start/stop services using their own distinct userID needs to perform this step.  This is a one-time-only step until such time as your security team forces you to change the WebLogic epm_admin password.

Now on your OHS server(s) foreign to where you run your master start/stop scripts from (you are running custom start/stop scripts, yes?), create a simple little DOS batch script like this:

sc start "Oracle Weblogic ohs NodeManager (D_Oracle_Middleware_ohs_wlserver)"  

start "StartOHS" /wait /i cmd /c %EPM_INSTANCE_HOME%\httpConfig\ohs\bin\startComponent.cmd ohs_component

Replace D_Oracle in that first command with the drive letter where you installed.  e.g. E:_Oracle, F:_Oracle or whatever is appropriate.  The drive letter is unfortunately embedded within the Oracle Node Manager 12c Windows service name.

Replace %EPM_INSTANCE_HOME% with the fully qualified path to your Oracle EPM Instance, which is DRIVE:\Oracle\Middleware\user_projects\epmsystem1 by default.

Note: the final line beginning with start "StartOHS" is all one line all the way through ohs_component.  Blogger is linewrapping it in an undesirable way.

Save this script as DRIVE:\scripts\startohs.bat or whatever you want.

Replace startComponnent.cmd with stopComponent.cmd and now you have your stopohs.bat script as well!

Finally, use this to invoke it remotely from your master start/stop scripts:

wmic /node:%FDNHOST2% process call create "DRIVE:\Scripts\startohs.bat"

wmic is a built-in Windows command.  Provided your userID is an administrator on the foreign server, you may use this syntax to invoke any batch file, command, or executable you wish.

Replace the variable %FDNHOST2% with the hostname of your 2nd OHS server that you're clustering for load balancing.  Repeat as needed if you have more than 2 OHS servers.

Simple & easy.  You're welcome!  👍

Wednesday, May 12, 2021

In-Place Upgrade to EPM

The comments section for my prior post about EPM has really lit up with a common theme:

An in-place upgrade from either Hyperion / Oracle EPM or (the only certified paths to get to fails if one applied the OPatch update necessary to subsequently apply the quarterly Oracle Critical Patch Update ("CPU") for Oracle Fusion Middleware - most notably WebLogic and OHS.

The commenter community seems to be in agreement that the best approaches are:
  • If Oracle Middleware, Opatch in particular, has yet to be patched, back it up!  If disk space is available, back up \Oracle\Middleware in its entirety before applying the quarterly Cracle Critical Patch Updates.
  • If the system is unpatched, it is apparently safe to perform the in-place upgrade to
  • If the system was patched, it will be necessary to restore \Oracle\Middleware\Opatch and perhaps \Oracle\Middleware\wlserver and \Oracle\Middlware\oracle_common.  The jury is out on exactly where the bug resides with respect to patching.  All that is known for certain is Opatch is a primary culprit and the Opatch update cannot be rolled back without performing a filesystem restore for the Opatch folder structure.
Additionally, I experienced issues with missing jar files where ODI and FDMEE is concerned.  I have yet to determine if this is due to the issue mentioned above....  an EPM 11.2 customer-facing upgrade that just got handed over from me to the UAT team has eaten up all of my "free time".

I've installed a fresh VM and a fresh/unpatched EPM and will perform the in-place upgrade to to vet if ODI/FDMEE is truly broken or not in this release.  The EPM Configurator tool does not reveal the problem when FDMEE is broken, but there's a way I can see it on the back-end.

Finally, time permitting, I'll take my unpatched Middleware backup, restore it to my botched/patched> in-place upgrade VM and see if I can put Humpty Dumpty back together again.

And here we thought RCU was difficult....

Tuesday, April 27, 2021

EPM 11.2.5 - My Week is Full

We finally get Oracle Fusion Middleware (FMW)!

SQL Server 2017!

Essbase 21c certified!

The bad news:

If you're still using Essbase Studio, migrate away from it.  Essbase Studio is slated to be retired in EPM 11.2.6 as per this Oracle Statement Of Direction:

Visual Basic scripts for FDMEE need to be migrated to Jython ASAP.  VB scripting is expected to be decertified in EPM 11.2.7.  We knew this some time ago, but now we now the release number where VB goes away for FDMEE.

Interesting news:

Oracle's readme for 11.2.5 confirms what I've suspected.  In 11.2.x we aren't getting Patch Set Updates (PSUs), but rather new "dot" releases.  Here's a copy/paste directly from the 11.2.5 readme:

EPM System updates are released on a quarterly basis, generally in January,
April, July, and October.

You can directly apply an update from the previous two updates.

I won't paste the entire thing.  When you download 11.2.5 from Oracle eDelivery, you get this folder:

EPM_11.2.5\EPM\EPM System Installation Documentation\EPM System Installation

Stop, open this folder.  Open the readme before doing anything.  Here's the Cliff Notes.  You can apply 11.2.5 as an in-place upgrade on top of either 11.2.3 or 11.2.4.  Do not attempt to apply it on top of or any older release; you need to do a fresh install and LCM your apps from the older release.  Only is certified for this migration path.

If you were an early adopter like me, you need to jump to 11.2.2 before you can get to 11.2.3 or higher.  You can apply 11.2.2 on top of either 11.2.0 or 11.2.1.  You can't get to 11.2.3, .4 or .5 unless you're on at least .2.  Job security!

Migration Path documentation: to 11.2.x

If you're on Financial Close Management or older, prepare for pain.  I've done it and it is not fun.  :(

It is now time to back up my sandbox and attempt the upgrade.  Wish me luck!

Wednesday, March 31, 2021

EPM 11.2, Visual Studio, and SSIS Packages

This is a bit of a weird one, and it isn't Oracle's fault at all.  This is actually a Microsoft issue.

Suppose you are migrating from Hyperion / Oracle EPM to EPM 11.2.x.  Further suppose you have custom data integrations in FDMEE/ODI or MaxL that rely upon SSIS (SQL Server Integration Services) automation.

Your EPM 11.2.x system would be using MS SQL Server 2016 SP2+ if you want to use SSIS.  I checked the certification matrix last week and Oracle still hasn't certified MSSQL 2019 for EPM 11.2.x.

(Disclaimer: the above paragraph may become be dated as Oracle might certified MSSQL 2019 in the future. The Internet is forever!)

Now here's the fun part.

To migrate your SSIS packages to MSSQL 2016, you will need to first import and upgrade them via MS Visual Studio.  The version available to download is Visual Studio 2019.

Once upgraded, you use MS SQL Management Console to import them into SSIS.  The version of this software as of this writing is 18.8.

This combination of software do not play well with each other, and you'll get an error message in MS SQL Console when you try to work with the upgraded packages.  This exact error and solution has been written about on many blogs.  I'll just jump straight to the solution.

You'll need to uninstall MS SQL Management Console 18.8, and then grab version 16.x from Microsoft's download page.  There's a link there that lets you download older versions, and 16.x is still available as of this writing.  Version 17.x does not solve our issue... we have to go all the way down to 16.x.

You may then complete your migration in MS SQL Console 16.x.

One final tip: if your custom integrations are using Microsoft's dtexec utility, you'll need to replace the reference in the script's path to dtexec from 110 (SQL Server 2012) to 130 (SQL Server 2016).

Saturday, March 13, 2021

Latest Windows Update Removes Abobe Flash

This is a follow-up about Adobe Flash Player EOL and On-Premises EPM 11.1.2.x.

As you may have heard, Adobe ended support for Flash Player on Jan 1, 2021.  This date has been known for some time, and as a result, Oracle released patches for EPM in Summer 2020 that removes Flash dependency from Hyperion Planning, Hyperion Calculation Manager, and the Financial Close suite.

Some Oracle EPM / Hyperion customers may have deferred patching or upgrading.  Perhaps the thinking was "we can just leave it on end-user workstations as-is even though it is out of support."

Microsoft says "Not so fast!"

If you're on EPM and are using any of the 3 modules I mentioned above, please apply the patches right away.  They're listed in my link above, although newer ones might be available by  now.

If you're on EPM, you need to upgrade.

As mentioned in my earlier post, Adobe removed the Flash Player download from their website.  They further stated that downloading it from any 3rd party site is a license violation.

The good news is EPM 11.2.x has the fix built-in.  As does the EPM Cloud.

Thursday, March 11, 2021

FDMEE 11.2 - Java 6 reference can be buried within the database

Depending upon you migrate FDMEE from Hyperion / Oracle EPM to EPM 11.2.x, you may have an issue when trying to run your load jobs.

In 11.2, Oracle included a handy migration package specifically to migrate the AIF* tables from to 11.2.  You'll find it on your 11.2 FDMEE server in \Oracle\Middleware\EPMSystem11R1\products\FinancialDataQuality\database\migrate.  There's a package each for MSSQL and Oracle - check the subfolders for the packages and instructions.

As per Oracle's documentation, you want to run this in 11.2 after you've executed "Configure Database" for FDMEE.  This because the migration package only migrates the AIF* (FDMEE) tables, and does not migrate the ODI-specific tables (SMP* etc.).

Now let's say you're in 11.2's Data Management and you're trying to run an import job.  It fails.  You check the log and see a reference to JAVA_HOME=%EPM_ORACLE_HOME%\..\jdk160_35.

This simply won't do!  Don't be tempted to just copy jdk160_35 from your server to your 11.2.  Java SE 6 is out of support and won't be patched anymore.

You can run a simple SQL statement to fix the problem.  Here's how it looks in MSSQL, and Oracle's version of this would be the same:

Bounce your 11.2 FDMEE service(s) just to be on the safe side, and now when you go back in to Data Management, you won't see that reference to jdk160_35 in your process log anymore.