Demystifying Hyperion EPM Versions, Patching, and Upgrading

by Eric Helmer

Understanding Oracle product versioning certainly isn’t rocket science, but it can be a bit confusing. Oracle has been very successful over the years acquiring software and products to compliment and strengthen its impressive portfolio. While the level of effort and complexity of combining products into an overall solution stack such as Oracle Fusion Middleware must surely be daunting, it is easy to overlook the challenge Oracle faces to get everything on a consistent versioning and release scheme.

Those who used legacy Hyperion products were used to a simpler, and easier versioning construct. Hyperion System 9 was somewhat easy to understand, as the product matured into an overall solution from otherwise separate products in the previous versions. However, with the Oracle acquisition and the integration of the Hyperion code into the Fusion Middleware line of products, the product adopted the Oracle versioning system, which can be foreign to some, which can trigger questions among customers: What is my a base version? When should I apply a patch? What’s the difference between an upgrade and a patch? Should I apply all patches that are on the support site, how often?

This article attempts to demystify the current Oracle versioning scheme for Hyperion-oriented customers, and to clarify when and how to apply patches and upgrades.

Versioning

Let’s start with a base version. Prior to Oracle EPM 11, the Hyperion code set followed its own numbering scheme. You remember Hyperon Version 9.2.1, 9.3, etc?

Oracle skipped the version number 10 in the EPM suite, presumably to bring it in line with the rest of the Fusion products in the version 11 series.

Version 11.1 was the first Hyperion release to follow the Fusion version numbering system. However, it’s important to note that the code was still legacy Hyperion, bearing little resemblance to its Fusion counterparts.

Oracle EPM version 11.1.2.0 was the first version to resemble Fusion, including the built-in adoption of Weblogic, the new Fusion and middleware directory path structure, the use of Oracle HTTP server instead of Apache, and the elimination of OpenLDAP. It seemed that every line of code was touched or re-written as the word “Hyperion” was removed throughout the product experience, as well as within many back-end configuration files.

Although we are all used to an annual major release of the EPM, you will notice that there was a 2-year gap between 11.1.1 and 11.1.2. It’s important to note why.

There was something very unique to the 11.1.2.0 version: It was only intended only for new installations , with no supported upgrade (though many attempted and succeeded). Oracle EPM 11.1.2.0 was not backwards compatible with any previous versions. However, 11.1.2.0 was highly adopted because of the long-awaited compatibility with 64-bit Microsoft Windows 2008 and more modern versions of Microsoft Office and Internet Explorer.

Later that year, Oracle released version 11.1.2.1, which supported upgrades and backward compatibility.

Today, no doubt we are securely in the Fusion world and indeed the Fusion versioning scheme. Let’s break it down:

Oracle Fusion version numbers are generally tied to a major database release, then expand to the right, narrowing down product subsets. We can think of them in almost a parent/child relationship. For EPM, we can see that the overall database release being a parent of Fusion, and EPM being a child subset of Fusion.

In this case, this EPM version number is tied with version 11g of the Oracle Database with the maintenance version 1. This is the second Fusion product line. We can still think of the third digit as the major EPM release.

It’s not until the fourth digit that we see a specific EPM Version, or minor release. The fifth digit can be thought of as an in-between version reserved for EPM specific patches, which used to be called service packs or service fixes.

In the EPM world, the fourth digit indicates an upgrade release, and the fifth digit indicates a patch release.

So going from 11.1.2.2 to 11.1.2.3 is an UPGRADE.

Going from 11.1.2.3.0 to 11.1.2.3.500 is applying a PATCH.

Patches are commonly applied and are fairly easy, quick, and low risk. They are intended to be installed on top of an existing environment. Upgrades are major code changes that can require a more strategic, time-consuming project. Depending on the version you are upgrading from, you may have the option of upgrading on top or in-place, however most choose to create a new upgraded environment on new hardware in more of a lift-and-shift approach. While lift-and-shift upgrades take longer, they are the least risky as they allow for a smoother transition with plenty of time for parallel testing without impacting the current production system.

Historically, major releases are an annual occurrence for Oracle. In between those major releases there can be hundreds of patches, and a handful of patch sets. While it may be unnecessary to be in a constant state of upgrade, it is generally a good idea to have a quarterly or at least a bi-annual patching strategy. However, not all patches should be applied simply because they are available.

Oracle EPM Patches

In the EPM world, there are two types of patches: Patch Set Updates (PSU), and Patch Set Exceptions (PSE).

A Patch Set Exception is a patch that Oracle creates as a one-off to address a specific bug, and is provided to customers that are in critical need. PSEs are neither version controlled nor cumulative. They are not tested in every customer situation. Usually these patches are only installed with Oracle’s guidance after opening a service request and Oracle has identified a bug. These usually have long, nasty numbers associated with them, such as 11.1.2.3.1788341

Patch Set Updates are proactive, packaged patches that have been certified and tested by Oracle and are recommended for installation in all cases. Each PSU can contain 25-100 individual bug fixes, performance enhancements, and even minor new functionality. These numbers are usually nice and round, like 11.1.2.3.500 or 11.1.2.3.501.

In general, you should only apply PSEs if instructed to do so by Oracle in response to an identified bug. You should never apply PSEs simply because they are available. Because they are designed for a specific use case, PSEs have been known to break otherwise perfectly functioning systems.

PSUs, on the other hand, should always be applied.

Where To Go For Patches

All Patches can be found on the Oracle support site http://support.oracle.com

Once logged in, you can go to the Patches and Updates Tab.

From there you can search by product, platform, version or a specific patch number…

Searching is fairly intuitive. You can search by product line, version, or product family. Here I am going to search for planning patches to the 11.1.2.3 version.

Here is an example of an individual Patch Set Exception that addresses a specific issue in importing E-Business Suite HR Data into Planning Public Sector.

Patch Set Updates are listed in the search result sets. Below is a PSE for the Hyperion Essbase Run Time Client for version 11.1.2.3

Once you click on a patch or patch set update, you will have the ability to download the README and the patch itself. Be certain you select the correct platform, noting that some platforms are 32-bit and others are 64-bit. Installing the wrong one can be disastrous.

Applying a Patch

Important: Read the README. It includes valuable information.

• Type: PSU or PSE
• Supported version and paths to install this patch
• Prerequisites
• Supported platforms and languages
• List of all defects fixed
• Known Issues with the patch
• Instructions on how to apply

Most patches are applied with the Opatch utility with syntax such as the following, however, you will want to follow the instructions in the readme or contact a partner and have them assist

Identifying Installed Patches

Just as you use the Opatch utility to install the patches, you can also use it to see what products and patches are currently installed using the lsinventory flag

(UNIX) ORACLE_HOME/Opatch/opatch lsinventory

(Windows) ORACLE_HOME\Opatch\opatch lsinventory

Example output:

Of course, as with any changes to a live production environment, patches should be applied and fully tested in lower (DEV, TEST) systems prior to production. There will be downtime while installing these patches, as services will need to be stopped.

Notification of Patch Availability

Unfortunately, Oracle does not email their customers when there is a new patch or patch set. However, they sometimes post if on the EPM Blog, which you may want to follow. For example:

https://blogs.oracle.com/proactivesupportEPM/entry/epm_psu_201406

It’s good practice to establish a standard interval for checking for and implementing patch sets as the come available. A quarterly exercise is suggested.

Oracle EPM Upgrades

As with all enterprise software, Oracle EPM upgrades are a necessary evil. It is common that corporations consider upgrading every two years. Oracle, however, generally supports a version for five years on standard support for individual releases. Unlike patches, upgrades do not necessarily follow a strict frequency as they introduce the most change. Most upgrades are need driven. The most common reasons for upgrading are:

• Compatibility with modern operating systems, versions of Microsoft Office, web browsers, or when it’s time to refresh hardware.
• New features, functionality, or fixes that are applicable to the business
• Supportability by Oracle if the current production version is in jeopardy of falling off Oracle support and maintenance
• Other Business activities such as mergers, acquisitions, chart of account restructures, consolidation of multiple systems.

Upgrades also serve as a great opportunity for companies to take the next step in maturity and processes. It’s a great time to reflect back on the last 2-3 years and use the activity to make technical and procedural improvements. While some companies do a simple like-for-like upgrade, more strategic companies tend to use the change to improve:

• Security and encryption of sensitive data
• Business continuity and fault tolerance
• Change control and quality assurance processes
• Support and monitoring processes
• Service level agreements and measures
• Governance and control systems

Taking a step back to do an honest self-assessment is the key to making the most of your upgrade. By understanding where organizations fit on my EPM Maturity Scale gives us the ability to take that next step to a truly optimized EPM environment that is scalable, reliable, repeatable, automated and protected. While we do not necessarily expect to jump from level 1 to level 5 overnight, making incremental improvements with each upgrade is a great way to instill continuous improvement and maturity.

Understand the Change

Another key to a successful upgrade is to expect and manage the change upgrades will create. Each major version of the EPM suite introduces significant and sometimes massive changes to functionality, performance, compatibilities, and user interface. Sometimes full features are eliminated, or moved into other product areas especially in the latest versions as Oracle continues to port the EPM suite to their Software as a Service Cloud offering.

The readme’s and What’s New sections of the release documentation are great tools for understanding the new features. For a quicker comparison, Oracle offers a Defect Fixed Finder tool (Doc ID 1292603.1), an Excel 2007 based tool that will spit out by product the functional and technical differences and fixes listed after your current version.

Phases of an Upgrade

1. Prepare

Upgrade planning is essential to a successful upgrade. In this phase it is imperative to look at the project two very important components.

IT and Hardware
Each version of the software can introduce additional software components, services, and requirements. Also, entire operating systems and architectures are newly supported or deprecated. It is imperative that a full IT analysis is done on the new system so that proper hardware can be acquired. Impacts on monitoring tools, server storage, network, backup/recovery systems, security and encryption methodologies, user compatibility, scalability, and performance should be carefully analyzed.

It is also important to understand all the pre-installation requirements that are needed, such as hostnames, databases, special operating system settings, networking equipment, security accesses, etc.

Functional Gap
Of course each new version introduces exciting new features that Oracle customers want. However preparing for those and managing those changes are important. Not all features will be applicable, and some changes are mandatory. For example, in recent versions, Oracle removed Hyperion Planning business rules from the Essbase Administration Server and forced customers to move to the Calculation Manager. In the next version, Oracle will force all Financial Data Quality Manager users to use the new Enterprise Edition. Changes such as these can have varying effect on users and product interactivity.

2. The Technical Upgrade

Once all the preparations have been done and the servers are in place, its time to lay down the software. Software can be downloaded fro the Middleware section of the Oracle Download Center under Hyperion Performance Management and BI.

It is important to note that the four files that make up the Foundation Services include Weblogic, Enterprise Performance Management Architect, Shared Services, Workspace, and the client installers. All other components will have to be downloaded separately.

Installation
The installation of the software is performed using the provided installtool. The installtool requires certain files to be downloaded from the Oracle website and uncompressed in a certain way. Depending on what files were downloaded and uncompressed, the installtool will traverse the directory structure and give you the option to install individual components.

In this step it is important to only install what is needed and not install what is not. In this example, we are installing only the web application pieces of the Foundation, Planning, and Reporting suite on this particular server.

Configuration
The configuration is performed though the configtool. This tool will discover all the EPM software that was installed and list them all out. Configuration is a tedious task that will have take you through each component one-by-one to assign things like Weblogic configuration, database repository connections, ports, and locations of key files.

Here is an example of assigning ports to Weblogic containers during configuration:

The configtool shows products with a green checkmark once complete, and an exclamation point for those that are still to be configured:

In some cases configuration can be redone if there is a mistake, however in many cases mistakes can force a full uninstall and rebuild. It is important to go slow, carefully documenting steps along the way for reference and only configuring the components that need to be configured. In many cases not all items listed will be competed with green checkmarks.

Post Installation
One interesting (and frustrating) thing with the EPM installation process is that the tools lay down the software with default settings that assume the minimum requirements. The minimum requirements for this software is so extremely low, it can even be installed on a decent sized laptop. However these minimum settings are almost always inappropriate for modern day servers and corporate use. We have no choice but to go in after the installation and for each component tune things like:

• Memory settings
• Timeouts
• Cache settings
• Max database connections
• HTTP Serve Compression
• Keepalive settings

For example, the Weblogic Java heap size in many cases needs to be tweaked and tuned, which, depending on the component can be done in the Windows Registry, the Weblogic Console, or in script files on the file system. The key java options are –xms which tells java the minimum memory to allocate at startup, and –xmx which is the maximum amount of memory a java instance can use if it needs more. Exact values are situational. Blindly setting these values high does not necessarily maximize performance and in some cases can cause degradation due to impacts on things like Weblogic garbage collection. Optimizing these settings usually requires close monitoring of memory utilization under peak loads.

Migration
Installations that are performed on new hardware only lay down the plain vanilla software. For upgrades, all the individual application components need to be brought over from the older version. Each component of the EPM suite may have a different methodology to migrate and upgrade the applications. For example Financial Management has a different process than Planning. In some cases, a tool such as Life Cycle Management can be used. Life Cycle Management is an export/import transportation system that is built into the foundation of Shared Services. Either way, all artifacts have to be moved over individually such as security, reports, forms, applications, and data. Also do not forget about any other conversions that will have to be performed such as Business Rules to Calculation Manager or Financial Data Quality Manager to the Enterprise Edition.

3. Acceptance and Go-Live

**User Training
**After all the applications have been migrated over and tested to the new environment, it’s time to train end users to get them familiar with the new features and any differences in the UI. Some components such as smartview have significant new features in every version that is sure to have impact on users. It’s common to run trough 1-3 parallel close cycles to vet out the new system before finally shutting it down.

Go-Live
Going live is the exciting end-game in any upgrade. However, just because the users are happy with their new system does not mean we are done. From an IT perspective we need to ensure the system is ready for full production. Prior to officially go-live, we will need to address these critical items. Be sure to take these into consideration in your project timelines.

• Change control procedure
• Security and vulnerability analysis
• Backup and recovery implementation, documentation, and testing
• Helpdesk integration and proactive heath monitoring tools
• Administrative scripting and automation
• Business continuity and disaster planning
• Mobile devices rollout and policies

Summary

As is typically the case with enterprise software, the Oracle EPM suite has its nuances with versioning, patching, and upgrading. EPM administrators who have a good understanding these nuances and plan for the inevitable changes and required maintenance will be the best equipped to ensure smooth transition and end user acceptance.

About the Author

Eric Helmer is an Oracle ACE Director and Vice President of IT, cloud, hosting, and managed services for ADI Strategies. He has 18 years experience in implementing technical Oracle-Hyperion EPM solutions including Essbase, Planning, HFM, OBIEE, HPCM, and OFSAA.

---

Disclaimer

This article represents the expertise, findings, and opinion of the author. It has been published by Oracle in this space as part of a larger effort to encourage the exchange of such information within this Community, and to promote evaluation and commentary by peers. This article has not been reviewed by the relevant Oracle product team for compliance with Oracle's standards and practices, and its publication should not be interpreted as an endorsement by Oracle of the statements expressed therein.