10 January 2020

Oracle Hyperion EPM 11.2 - first impressions

Last month, Oracle finally released the long-awaited on-premises release of EPM 11.2, rumoured to be the last hurrah for the venerable suite. After a couple of test installations, I have a few thoughts from an infrastructure perspective.

First, the bad news:

  • This is very much a .0 release, in many ways the first since 11.1.2.0 (the last time so much of the infrastructure had substantially changed). It is rough in quite a few places, and configuration is not for the faint of heart.
  • I have encountered what, to me, looks like a blocking bug in multi-server configurations. I filed a support request with Oracle and will see how it goes. At the moment I simply wouldn't be able to recommend it in situations where high-availability is necessary.
  • Even after configuration, it is harder to operate by non-techies than in the past. Even the "start" and "stop" links provided, which used to be ok for single-machine use at least, are not sufficient anymore - some extra scripting will be necessary to make it useable even in the most basic scenarios.
  • Documentation has not fully caught up with 12c, particularly in the area of additional configuration tasks for Financial Close Manager (which was already pretty lacking). Some of the additions, to deal with the now-necessary Repository Creation Utility, are ambiguous.
  • Weblogic seems hungrier for memory than in previous releases. This might be due to 12c, or to the fact that it's now using Java 8 under the hood - I had already measured an increase in this area when replacing Java 6 with 7 on 11.1.2.4.
  • Essbase seems to have been shipped almost unmodified from the latest 11.1.2.4 version. Among other things, this makes it currently impossible to do a full-SSL configuration if Essbase is in the picture. It's disappointing, particularly considering how Essbase customers are typically among the few who often require fully-encrypted solutions.
  • The documentation seems to state that running any "Configure Database" task more than once will end in failure. I suspect this is true only for certain components, but I have not had the time yet to explore this area. This makes it even harder than before to migrate databases after configuration, so make sure you take design choices that will stand the test of time.
  • EPMA lives! Well, not really - the product is gone, but somehow it's still avilable in the Provisioning screen and you can assign roles for it. 🤷🏻‍♂️
  • This is the end of the line for IIS stalwarts. Using IIS as front-end webserver will simply not work (according to docs).
  • It's not particularly clear whether Oracle 18c and 19c are officially supported as database. In practice they seem to work (after all, they are really 12.2.0.2 and .03 rebranded), but it would be nice if the matrix was clarified.

But there are also some good news!

  • The products themselves are basically the same, with the occasional extra feature. Users shouldn't need any substantial retraining, with the notable exception of any EPMA or Interactive Reporting power-users still around.
  • The 12c stack, in theory, unlocks a number of attractive possibilities for system administrators and implementors - containers, no-downtime patching, and so on. It will take some time to fully unpack how EPM can take advantage of these goodies.
  • Recent Windows Server releases are supported.
  • In my test, everything seems to work even with the free editions or Oracle and SQLServer (XE 18c and Express 2017), which is nice for consultants and other professionals.
  • Both 12c and Java 8 support modern crypto standards, which should make things less awkward when risk-assessing and pentesting.
  • Java 8 brings a lot of improvements to the language and the ecosystem. Whole classes of problems have been removed (MaxPermGen, anyone?), which should make services more reliable and performant. Custom integrations will also be easier and faster to develop and run.

In the past, I would have expected such a release to be followed by a quick stream of fixes, necessary to make it actually fit for production use. We will have to see if it is going to be the case here, considering how long it took to debut and the overall tone of the Oracle roadmap (mostly cloud-focused). Should Oracle really commit to improving the on-premise, this release would soon prove itself as a substantial improvement over 11.1.2.4.

If you'd like to know more and discuss your options in the EPM space, make sure to get in touch with us.

at

8 comments:

  1. Corrado13/1/20 07:04

    Ciao Giacomo, bello leggerti.
    Stiamo facendo test anche noi, con speciale focus alle migrazioni. Sembra tutto molto più complicato, peggio forse della 11.1.2.0. Avete fatto qualcosa anche voi? A presto. Ciao. Corrado.
    ENG: Hi Giacomo, nice to read you again.
    We are performing some tests, particularly on the migrations from previous version. Did you do something similar as well? Any findings? Thanks. Corrado.

    ReplyDelete
  2. Francisco Fernandez Burgos13/1/20 13:52

    Hi Giacomo, thanks for your post & feedback. I agree with most of your comments.
    I've been also "playing" with 11.2 and was able to deploy a working environment using Oracle 12c, however, using SQL Server Express 2017 I was not able to complete the WLS deployment (it always fails), even after creating the EPM112_RCU database with RCU tool.
    The documentation steps when using SQL Server is not clear at all or at least I was not able find the way.

    May I ask you whether you used the RCU for creating (populating) the standard DBs? (I mean, once created the DBs at SQLServer did you run the RCU over them - selecting the WLS and the other AS Common Schemas- for creating the HSS, HFM, PLNSYS, etc databases?)

    The problem I saw was that while running the RCU with these "standards" DB it is require the collation: LATIN1_GENERAL_CS_AS, however this collation is not accepted when configuring them via Config tool (since SQL_Latin1_General_CP1_CI_AS is required).

    Anyway I'll create an SR but any hint on this from your side is highly appreciated.

    Thanks,
    Francisco

    ReplyDelete
  3. toyg13/1/20 15:42

    @Francisco:

    For SQLServer (Express or otherwise) you need to have at least two databases - one for the traditional EPM products (or more than one, in production setups) and one for RCU. This way you can have separate collation settings, and both RCU and Configtool are happy. Note that these databases can live on the same SQLServer instance, of course.

    Btw, RCU should never be pointed at the EPM databases - the structures it creates are simply meant to hold metadata stuff about the Weblogic domain, which can live separately. This mirrors what happens with Oracle, where RCU creates its own schemas that will live alongside any EPM ones.

    @ Corrado:

    Great to hear from you, been a long time! I've not had a chance to test migrations yet - I don't have any up-to-date and realistic HFM application, and typically that's where you see issues. The official position is likely to remain that everything has to be rebuilt or reimported via LCM. I noticed that Planning (and only Planning) is supposed to be LCM-compatible with 11.1.2.4 (as per official matrix), which to me suggests Essbase should also be easy enough; I expect the good old FR import/export might also work. I've not checked HFM, just noticed the "upgrade" option in configtool has gone.

    ReplyDelete
  4. toyg13/1/20 15:45

    @Francisco another thing to remember is that you need to delete your Weblogic domain folder if you run the configtool after changing RCU properties, since those details are read only when that folder is created; and that failed deployments might edit your RCU database in ways that prevent redeployment - so you'll have to get familiar with backing up and reverting that db...

    ReplyDelete
    Replies
    1. Francisco Fernandez Burgos13/1/20 18:15

      Good point, thank you Giacomo. That is probably the issue: the WLS domain folder was first created without any previous RCU DB, then later I created the RCU DB and retried the WLS deployment but it keep failing, due too somehow the WLS domain folder was incorrect. I'll recheck again deleting that folder and recreating a new RCU DB before re-running the EPM config tool. Cheers. Francisco

      Delete
    2. Francisco Fernandez Burgos13/1/20 20:52

      It worked, this time the WLS deployment finished successfully (using SQLServer Express 2017 in compatibility mode 2016). Thanks for your insights.
      Francisco

      Delete
  5. Reddy15/1/20 07:10

    Hi,

    If you have prepared prerequisites for HFM and SQL database installation in windows server, please provide me the prerequisites to babji.mba@gmail.com

    Appreciate your help, thanks in advance.

    Regards,
    Bharath Kumar

    ReplyDelete
  6. Karin Aunger20/1/20 08:05

    Hi Giacomo,
    I would agree with most of your comments too, except I have not deployed on Oracle DB, only on SQL server 2016, RCU with one DB, standard EPM DBs for the products, that all worked, even changing DB config for foundation to a different SQL db owner user worked too.

    I have carried out migration for the common EPM products from 11.1.2.4 (latest patches), all worked, HSS, HFM, FDMEE, Planning, Essbase, CalcMan. I followed the documented steps partly but also used HFMcopyapp followed by running the HFMapplicationUpgrade.exe (fine). For Essbase apps I used Copy App in EAS, for Planning apps I used LCM for everything.

    The main confusions I found was around getting WL admin server to deploy workspace with foundation, as this did not work until after I had OHS configured.

    Also I find as you said, the documentation is ambiguous about how RCU has to be used in a multi-server environment, because if you have to run RCU on each server (it says), surely you cannot re-create those WL databases for each machine with EPM components. Once those schemas are created, you could only perhaps point the other servers at those WL DBs (can you?) I deployed on a single VM with SQL separate.

    Another issue I had was after installing/running EAS console and Essbase studio (having changed the files to use Java8, as per readme's), the old java JRE6 deployed itself and messed up running standard start / setenv / config tool scripts, as the setJavaRuntime.bat (provided by oracle) then picked up that java JRE 1.6.0 on the system. I had to edit the .bat to force java8 for everything.

    rgds,
    Karin

    ReplyDelete