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 11.1.2.4 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 11.1.2.4 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 11.1.2.4 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 11.1.2.3.500+, 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 11.1.2.4 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 11.1.2.4 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 11.1.2.4 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.


EPM 11.2 - Your environment has been set

All releases of Hyperion / Oracle EPM 11.2.0.0 through 11.2.4.0 hosted on MS Windows Server do the following:

While this doesn't hurt anything, if you want to clean things do, do the following after you've finished deploying all of your WebLogic services.

Open regedit and export the Hyperion Solutions registry hive to your desktop.

Open this file in notepad/Notepad++ and do a Search->Replace.

Change Your environment has been set.; to nothing.  Save the modified .reg file.

Double-click the .reg file to import it back into your registry.

Do this on every server.


Friday, February 19, 2021

OHS 12c Startup Script for EPM 11.2

The following assumes your OHS is hosted in MS Windows.  An equivalent bash shell script may be easily created to do the same in Linux/Exalytics.  The below assumes you have already executed the OHS storeUserConfig process previously documented on this blog.


SET CWD=%~dp0

REM This script sets up our environment variables.

CALL %CWD%ScriptEnv.bat

sc start "Oracle Weblogic ohs NodeManager (F_Oracle_Middleware_ohs_wlserver)"

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


You're welcome.

Change the "F" in red above to be your EPM system's drive letter.  The variable EPM_INSTANCE_HOME is the path to the instance, such as F:\Oracle\Middleware\user_projects\epmsystem1 and I define it in my custom ScriptEnv.bat.

Tuesday, February 9, 2021

Oracle EPM 11.2.x and Essbase Thick Client

Here's an intellectual exercise for my followers.

Suppose you've constructed a brand new Oracle EPM / Hyperion 11.2.x system (11.2.0.0 through 11.2.4.0 as of this writing).  Now also suppose you have a need to automate Essbase MaxL scripts... let's say for example an Essbase nightly level-0 backup, or an FDMEE nightly data load automation.

You run the Essbase Client installer, and MaxL works just fine.

Except the Essbase Client is 11.1.2.4 technology and you've just corrupted one small element of your 11.2.x system.

Trying launching the configTool graphical client.  The javaw.exe process crashes immediately and you never see the Oracle EPM Config logo pop up.

What to do?

Oracle does have a fix for this documented within their Knowledge Base.  You just need to know where to look.

Or, search for files dated in the year 2014 A.D.  Open the Windows Explorer and put in a date range of 1/1/2014 through 12/31/2014 as you see in my screenshot below.

 

Don't bother with the html files.  What you care about are the EXE and JAR file extensions.  The act of running EssbaseClient.exe causes the 2020-2021 versions of these files to be blown away by the 2014 versions.

The fix: stop everything.  Replace the 2014 files from a server where you did NOT run EssbaseClient.exe to install Essbase MaxL.  Then launch configTool and confirm it works again.  Customers who have security policies mandating database & WebLogic password changes every 90 days will need a working configTool utility.

Try this out in a DEV environment.  I like Ahi Tuna sashimi with a bit of soy sauce and wasabi, and thus you can thank me with that.  ;)

Sunday, January 31, 2021

EPM 11.2.x - Why Did My Web Service Crash During Startup?

So you're working on your shiny new upgrade: Oracle EPM / Hyperion 11.2.2.0 through 11.2.4.0.  (You want to be on 11.2.2.0 at a minimum, as that's the only path to subsequently jump to higher releases as of this writing).

You attempt a first-time start up of web services, and one or more web services shuts itself down.  The problem I'm about to describe existed in 11.1.2.4 and prior, but it still rears its ugly head in 11.2.x from time to time.

Here is the symptom.  For ease of discussion, I'm talking about an MS Windows server, but the problem can happen in Linux as well.  Flip the slashes and change .cmd to .sh.

Inspect Oracle\Middleware\user_projects\EPM_ORACLE_INSTANCE\diagnostics\logs\services\*-sysout.log for the failed process in question, and discover this text:


(Note: This "services" folder does not exist in Linux and you'll need to crawl through the WebLogic domain's log folders)

What to do here?

Answer: the fix is very simple.

1. Start up your WebLogic Admin Server.  There's no service for it (yet! A future post I'll write will discuss the easy way to do it.  Don't use the Knowledge Base article to create "beasvc"!)

For now, double-click Oracle\Middleware\user_projects\domains\EPMSystem\bin\startWeblogic.cmd.  Leave the DOS command window that pops up alone, and wait until you see the text RUNNING in upper-case.  This takes 2-1/2 to 5 minutes, depending upon your server.


This process encrypts the master boot.properties file for your WebLogic Admin Server.

2. Copy the file Oracle\Middleware\user_projects\domains\EPMSystem\servers\AdminServer\security\boot.properties to the Oracle\Middleware\user_projects\domains\EPMSystem\servers\FailedServerName\security\ folder, overwriting the boot.properties file that might exist in that folder.  Do this while your AdminServer process is still running in that DOS command window.

3. Restart the failed service in question.  Now it sees the encrypted boot.properties file and is able to communicate with AdminServer.

4. Once you've been able to successfully start all web services (Planning Web, HFM Web, EAS Web, etc.) you may hit Ctrl-C in that AdminServer DOS command window to end the process, if you wish to.


Appendix:  I've stood up every 11.2.x release released thus far:  11.2.0.0, 11.2.1.0, 11.2.2.0, 11.2.3.0, and now 11.2.4.0 as of this writing.  I've hit the issue described herein multiple times, and most recently in 11.2.4.0.  If you hit this issue yourself - you did nothing wrong during your config.  It just happens sometimes.

Once you fix it, the solution tends to be permanent and I've yet to have to do it a 2nd time in the same WebLogic domain.