EPM 11.2.x FDMEE OHS Configuration Updates

  • Date: July 27, 2021
  • Article by: Jeff Henkel

In EPM 11.2.x, you may find that you see timeouts in batch jobs that still successfully complete, or you may find the browser returning http 503 errors when FDMEE jobs run long.  

A look at the FDMEE Process Details log will reveal an error such as: HTTPError: HTTP Error 503: Service Unavailable

When this happens, you will need to update the mod_wl_ohs.conf file for OHS.  There are a couple of different Oracle Doc IDs that mention different settings to update, but by default the setting for FDMEE are essentially blank (unlike other EPM products, this one just has the server redirect information and no tuning).  In case you don’t know where this file is, it’s usually located at:  \Oracle\Middleware\user_projects\Foundation1\httpConfig\ohs\config\fmwconfig\components\OHS\ohs_component

The values to add are below, and go into the sections for:

  • <LocationMatch ^/aif>
  • <LocationMatch ^/aif/static>
  • <LocationMatch ^/oraclediagent>

The values to add to the the above sections are:

  • WLIOTimeoutSecs 60000
  • Idempotent OFF
  • WLSocketTimeoutSecs 6000
  • WLForwardUriUnparsed ON
  • KeepAliveEnabled ON
  • KeepAliveSecs 20
  • DynamicServerList OFF

Once that is done, OHS needs to be restarted and all FDMEE process should complete and users will stop seeing the browser side warnings and the process batch failures in FDMEE Process Details.

Share me

Getting the SmartView .MSI

  • Date: Aug 10, 2021
  • Article by: Jeff Henkel
Read More

EPM 11.2.x FDMEE OHS Configuration Updates

  • Date: Jul 27, 2021
  • Article by: Jeff Henkel
Read More

Oracle Releases EPM On-Premise version 11.2.6!

  • Date: July 23, 2021
  • Article by: Mike Turner

Oracle dropped 11.2.6 this week and I’m working on a sandbox install but I wanted to get some quick highlights out for everyone.  We’re familiar with 11.2 updates by now, and this one is not any different, the release is both a  complete install package, and also a maintenance release for previous 11.2.x installs.  It’s important to note that Oracle has stated “you can directly apply an update to the previous two updates” – meaning you have to be at 11.2.4 or later to apply the update.  Oracle has said this in the last two updates, so they seem to be pushing everyone to stay current or plan on more work when it comes to the update process.  With a quarterly release cycle this means we should be targeting a patching/maintenance regimen of at least 1 every 6 months for EPM customers. Oracle has stated, EPM System updates are released on a quarterly basis, generally in January, April, July, and October.

NOW the NEW STUFF! WooHoo – 

  • MsSQL 2019 is officially certified
  • The installer now automatically handles patches/updates to the Fusion Middleware with “Apply Update” and its not a manual post install process anymore.
  • Support for ANY identity management product that supports header-based authentication
  • Updated HTTP Client
  • Planning is now certified with OGNL 3.2.18
  • And the documentation now outlines the procedure on how to change the DB passwords.
  • Planning supports a Custom Grid Spread
  • Profitability and Cost Management have a few new rest API’s

Some other things to note with this drop that stand out from previous 11.2.x versions…..

  • Oracle clearly states in the document that WebLogic has to be installed on same OS across the board in a distributed environment. This means if you have HFM and Essbase, the only component that can go on Linux is Essbase.
  • Essbase Studio is not included with 11.2.6 and has ben removed from future distribution
  • FDMEE support for scripting in Visual Basic is officially not supported. Customers need to port to Jython, if they have not already. It will not be available from a functional standpoint beginning with 11.2.7
  • And if you’ve been waiting for it – you should know the FDMEE SAP adapter “will be certified”, though they do not give a date, but it will be a third-party plugin for FDMEE available from Bristlecone Labs.

Over the next few days, I will be kicking the tires on the install and config so check back to see my take on how this new version works and if I run into any “gotchas” along the way….

Share me

Getting the SmartView .MSI

  • Date: Aug 10, 2021
  • Article by: Jeff Henkel
Read More

EPM 11.2.x FDMEE OHS Configuration Updates

  • Date: Jul 27, 2021
  • Article by: Jeff Henkel
Read More

FDMEE Migration – Less Than Ideal

  • Date: July 22, 2021
  • Article by: Jeff Henkel

So, if you are familiar with the Oracle EPM Suite (Hyperion) you know that most products over the years have had issues with migration.  Any migration is usually accompanied by some headaches.  The suite provides LCM to migrate most content, HFM has various forms of copying data and metadata, and Essbase has both LCM and the EAS Wizard.  There are multiple ways to move metadata and data.  Standing in its own unique position is Financial Data Quality Management Enterprise Edition (FDMEE).

In order to migrate content across versions (in other words to upgrade from 11.1.x to 11.2.x) you are supposed to use an Oracle provided SSIS (SQL) or Data Pump (Oracle) script to migrate from the source DB over to the target DB, with the target DB having already been configured for your 11.2.x version.  There is fine print in the documents that state the source environment should be on 11.1.2.4.220 or above prior to the migration.  The start of this process can be found here.

The following will focus on this process with a SQL FDMEE DB, but the same applies for Oracle DBs.  If you look at step 5, it states:

  • Check for any errors. Fix any issues in the source and repeat steps 3 and 4 in sequence as needed.

Now, this is where things get interesting.  What is most likely to occur is you will find various tables do not copy over when initially executing the SSIS script.  My experience is that this is due to duplicate records in the TDATAMAP and other similar TDATA tables.  Apparently, each combination of PARTITIONKEY, SRCKEY, DIMNAME, and TDATAMAPTYPE should be unique.  From a logical perspective, that makes sense.  But if they have to be unique then why are they in the tables to begin with?  I wish I had an answer to that, but I do not.

Additionally, the utility as provided offers no built in logging functionality, so you need to scroll around in a console window in order to see what an error looks like.  It looks as follows, for enquiring minds: 

What does all of this mean?  Well those of you familiar with FDMEE know that client FDMEE databases and their accompanying table sets can be large.  You may also know that many clients want to keep this history of data and transactions for audit purposes.  So, in my example the client had a relatively small 30GB database, and over 300,000 records in the TDATAMAP alone.  Running the utility to upgrade it takes approximately 90 minutes (or longer depending on the size of the app), and for it fail on each individual duplicate is problematic.  

To resolve, this and not run the utility potentially dozens of times, some SQL scripting can be your friend.  In this example I will focus on the TDATAMAP table, where the source of most issues seems to reside.  In order to do that, a look at the errors shows that the SSIS script fails to update a combination of PARTITIONKEY, SRCKEY and DIMNAME.  So the next step is to determine how many duplicates of this type there are.  Which can be done as follows:

This will tell you how many duplicates you have, and which combinations they occur in.  In the case of my runs, the uniqueness only seems to apply to the FDMEE required dimensions, but your mileage may vary.  Looking at the results from the query above you may see something like:

In this case, there are two duplicate records for 1264201300000000 and ENTITY (a required dimension) at Partition Key 30.  We can now search those, and remove one of the offending rows, which will each have unique DATAKEYS.  In my case, I removed the oldest DATAKEY.  Alternatively, you could go back to the FDMEE source and individually remove/resolve these and go back through the whole migration process.  I used SQL to first isolate the rows:

This returned two unique rows with different DATAKEYS and I simply removed one of them as follows:

Doing the above sort will then allow you to remove duplicates prior to executing the migration utility, or at least after a first failed run.  Whether you chose to resolve the duplicates in FDMEE (probably the Oracle preferred method) or via SQL is up to your judgement.  Either way, the above at least lets you know how many duplicates you are potentially dealing with, and gives some information to resolve them.  If there are issues in other tables, you could perform similar SQL searches, leveraging their column structure to also isolate and resolve similar issues.  

Lastly, it is important to note that Oracle Support has explicitly told me that they do not support migrating FDMEE from 11.1.2.x to 11.2.x via LCM.  So, while I know that works, and I have done it for customers when the above has failed.  You could encounter issues.  Following the LCM path would mean a loss of all historical FDMEE data though, and that can be an issue for customers.  

With the above stated, it is best to be prepared to have some struggles with FDMEE migrations.  I was able to speak with Oracle Development and they have agreed to add validation and better logging to the FDMEE migration process, I do not have a time/version for when that will be updated, but it is being tracked as a BUG for future improvements.

Share me

Getting the SmartView .MSI

  • Date: Aug 10, 2021
  • Article by: Jeff Henkel
Read More

EPM 11.2.x FDMEE OHS Configuration Updates

  • Date: Jul 27, 2021
  • Article by: Jeff Henkel
Read More

Oracle Critical Patch Update for July 2021

  • Date: July 21, 2021
  • Article by: Jeff Henkel

Oracle has released the quarterly patch update for July, and this list includes a number of EPM related items.  Here is the full list of July patch items.

First off the list are the usual suspects for WebLogic Server and Java:

For EPM 11.2 customers, the details are as follows:

For EPM 11.1.2.x customers (and thus running WebLogic 10.3.6) the details are as follows:

For Java, there are updates to both Java 7 (supported for EPM 11.1.2.x) and Java 8 (supported for 11.2.x):

The EPM Products have also released a series of patches:

Of the above patches, the only one new to this release is the one for Financial Reporting, which is available only in 11.2.6, though it is reported as an issue in EPM 11.1.2.4.  So, this is probably the first instance of Oracle demonstrating that EPM 11.1.2.x is truly end-of-life and will not be supported past 12/31/2021.  The exact verbiage in the patch is:

As always, if you are in need of assistance with patching, please feel free to reach out to iArch Solutions and we are happy to assist with your patching or upgrade needs.

Share me

Getting the SmartView .MSI

  • Date: Aug 10, 2021
  • Article by: Jeff Henkel
Read More

EPM 11.2.x FDMEE OHS Configuration Updates

  • Date: Jul 27, 2021
  • Article by: Jeff Henkel
Read More