Hyperion Release 11 Architecture and Installation, Part 3 of 5

“Installation and Configuration”

In installment #1 and #2 of this guide, we reviewed the architecture considerations and pre-installation requirements.  If you haven’t read the two previous post or haven’t read the Hyperion “Installation Start Here” guide, you’ll want to be sure to do that.

With this installment I’ll review the Installation and Configuration activities necessary for a Hyperion 11.x environment.  The installation and configuration are separate items.  The installation can takes place first and it only lays out the files to run the system.  The configuration ties everything together, creates repositories, deploys applications, and creates services.  This will cover both including the following items:

  • Hyperion Fusion Installer and How it Works
  • Preparing the Fusion Installer
  • Using the Fusion Installer
  • Hyperion Configuration Utility

The companion Hyperion Documentation for this post is either of the following documents found in the Oracle Documentation Library:
Oracle Hyperion Enterprise Performance Management System Installation and Configuration Guide Release 11.1.1.x
Oracle Hyperion Enterprise Performance Management System Manual Deployment Guide Release 11.1.1.x

You probably are not going to read them in their entirety since they are rather lengthy but they are very useful in fully understanding what is going on and priceless for complex environment or when things don’t go well.

Hyperion Fusion Installer and How it works.

So let’s get started on this installation already.  One of the great features of Release 11.x Fusion Edition is the Fusion Installer.  It is a nice application for guiding you through the installation.  The first thing to do is download the Fusion Installer and copy it to each server in your architecture.  The Fusion Installer is only the shell for the rest of the installation.  Under the Fusion Installer create a folder called “assemblies”.

Preparing the Fusion Installer

You’ll next need to download the remaining Foundation Services as well as any other applications you are using.  For our example we are going to assume the client is using Foundation, Planning, and HFM.  You are probably looking at something in the neighborhood of 4GB to download.  Each download, when unzipped contains a group of folders looking something like this:

Each server will need the appropriate assemblies copied to its own \<FusionInstaller>\assmblies directory.  This way, whenthe Fusion Installer starts, it knows what is available to install.  Some of the common components are needed on each server.  If you are missing something, the Fusion Installer will let you know in the status window at the bottom application.  For details on which assemblies are required for each application, refer to the Installation and Configuration Guide.

Using the Fusion Installer

As you start the Fusion Installer you will see something like this:

 

I like to choose “Choose Components Individually” since it feels like I have a little more granularity.  At this point I’ll select all of the components I want to install on each server.  Once again, this is run on every server in the architecture.  The Fusion Installer only lays out the application files; it doesn’t need any information so the sequence of installation can occur in any order.  It seems to work pretty well when all the components on a server are chosen together.

The last thing to do is to review all the install logs for any errors.  It is much easier to catch them now than after the configuration is started before anything is written specific is written to registries and relational databases.  Once the configuration starts, you are committed.

Configuration

The first thing to do is to configure Shared Services.  After the installation is complete, each server will have a Configuration Application.  It can be launched on a Windows Server from Start >Oracle EPM Applications > Foundation Services > EPM System Configurator.  This application will guide you through the configuration with such things as creating and distributing Java applications, creating relational repositories, and building the Windows Services.  The EPM System Configurator displays the installed components and then you can select which components to configure.  It looks something like this

The first thing to do is configure Shared Services.  This needs to be done by itself and before any other components are configured.  As soon as this is complete, launch Shared Services and verify that it is working appropriately.  If it isn’t, it’s will be a long day.  If you are able to log in to Shared Services, it is also probably best to go ahead and configure any external authentication provider at this time.

When Shared Services is complete and verified, you can move from server to server configuring all the components.  The documentation says that you can configure all the components at once but this will attempt to configure all the selected products in the same relation schema/table.  The documentation also says that some of the repositories need to be separate.  I prefer to do it one at a time to be certain I can keep all the relational repositories separate and I can validate each component as it is competed.  I usually start with all the Foundation Services and then make sure Workspace functions before moving on to the EPM application like Planning and Financial Management.  The last thing to do is to redeploy Workspace so it is configured to proxy all the remaining Web Applications.

You will want to be careful with each screen to make certain every component is configured as you planned.  It is easy to keep hitting ‘NEXT’ only to find out you mixed your Calculation Manager Repository in with your Shared Services repository.

As with the installation, I like to review all the configuration logs on each server very carefully.  Better to catch an error now than later.  When I’m comfortable with the configuration, I shut everything down and bring it back up.  The start order is quite finicky.  The Oracle Installation and Configuration Guide has specifics regarding the start order but I usually do something like this:
1.    Shared Services OpenLDAP
2.    Shared Services Application Server
3.    Hyperion Annotation Service
4.    EPM Workspace Agent (CMC Agent)
5.    EPM Workspace UI (CMC UI)
6.    EPM Workspace Web Server
7.    EPM Workspace Application Server
8.    Hyperion RMI Registry
9.    Performance Management Architect Services

Process Manager automatically starts the following services:

  •   Hyperion EPM Architect – Engine Manager
  • Hyperion EPM Architect – Event Manager
  • Hyperion EPM Architect – Job Manager
  • Hyperion EPM Architect – .NET JNI Bridge

10.    Performance Management Architect Web Services
11.    Essbase Server
12.    Administration Services Application Server
13.    Smart Search Application Server
14.    Essbase Studio Server
15.    Provider Services Application Server
16.    Hyperion Financial Reporting – Java RMI Registry
17.    Hyperion Financial Reporting – Print Server
18.    Hyperion Financial Reporting – Report Server
19.    Hyperion Financial Reporting – Scheduler Server
20.    Web Analysis Application Server
21.    Performance Management Architect Application Server
22.    Performance Management Architect Data Synchronizer Application Server
23.    Financial Reporting – Web Application
24.    Calculation Manager
25.    Planning Application Server
26.    Financial Management
27.    Hyperion Financial Management DME Listener
28.    Hyperion Financial Management Web Service Manager
29.    Hyperion Financial Data Quality Management – Task Manager

Assuming everything starts, we’ll discuss validation in the next part.

 

 

 

 
/0 Comments/by

EPM Reformation

The EPM Reformation

Enterprise Performance Management (EPM) is undergoing the same transformation that Enterprise Resource Management (ERP) systems brought about in the early 90s.  As complimentary solutions such as Asset Management, Payroll, and General Ledger converged into one consolidated, modular system, so too are the solutions that comprise EPM (Financial Consolidation, Budgeting/Forecasting, Strategic Planning, and Reporting).   Along with the obvious benefits and economies of scale that accompany this transition, we must be aware of the pitfalls associated with the design, implementation, deployment, and support of these mission critical applications.

EPM as a Compliment to ERP

Just as Enterprise Resource Planning (ERP) solutions are an essential component of the Back Office operations of every Fortune 500 Company, Enterprise Performance Management systems are complimentary in nature and provide insight into the operational and financial effectiveness of the organization.  Metaphorically speaking – If the organization was an automobile, ERP would be the engine and EPM would be the gauges.  Carrying the analogy forward, nothing prevents us from operating a car without a speedometer, gas gauge, or heat indicator.  Furthermore, when the car is running well (at least in so far as we perceive) we have little interest in these instruments.  But, what about when we hear the first ping in the engine, or the car doesn’t respond when we hit the accelerator.  Worse yet – A seize up (aka Recession).  In the absence of information conjecture prevails and we are forced to speculate as to the cause of the problem. Without EPM, organizations are essentially operating their business in a similar fashion; reactive at best, “from the gut” at worst.

The Problem

From a business (functional) perspective, EPM solutions are categorized by the convergence of Analytic Application such as Financial Consolidation, Budgeting/Forecasting, and Strategic Planning with traditional Business Intelligence Solutions hallmarked by Query & Reporting, Key Performance Indicator (KPI) Dashboards, and Enterprise Scorecards.  As EPM has evolved from it’s siloed upbringing as a departmental solution to the Enterprise-class solutions of today, the underlying technology required to support these applications has become more broad and in recent years increasingly more complex.  This evolution is both natural and expected.   Given the expansive use of EPM based solutions, technical constructs such as multidimensional databases, data marts, enterprise data warehouses, workflow engines, web services, SOA, Calculation Scripts, ETL packages, and Master Data (Hierarchies) have all become vital components to the architecture.

In so far as organizations appreciate the criticality of EPM solutions to their organization, there is a gross under estimate of the effort associated with deploying and supporting these mission critical applications.  This similar lack of effort appreciation is shared by the ERP implementation of the 90s.  How often did we hear about the $2 million dollar ERP solution that came in at $20 million or more?

Gaining an Appreciation

Few would argue that the ERP solutions of today have not brought about a degree of integration and consistency throughout the business.  The ability to integrate key operational back-office systems up and down the organization with the capacity to exchange data between functional modules without fear of inconsistency is certainly a hallmark of the ERP promise.  But, this integration did not come without a price.  The same can be said for EPM.

ERP and EPM are both the harbingers of consistency, transparency, and audit ability.  As such, they force the institution of standards and controls where they have not historically existed.   Furthermore, there is an illusion that these disciplines run contradictory to loosely coupled legacy processes that are thought to be more flexible, nimble, and sufficient for supporting the business.  Whereas this may appear to be true when viewing each process as a stand-alone, siloed operation (forecasting separate from budgeting, separate from financial consolidation, separate from operational reporting).  It is important to have the right perspective here.  As with traditional ERP solutions, to gain an understanding of the EPM value proposition, you must first rise above the individual business solutions that encompass performance management (i.e. Financial Consolation, Budgeting/Forecasting, Reporting, etc).  Only by viewing these applications from a holistic, integrated business perspective can you appreciate the business and technology economies of scale that accompany Enterprise-class EPM solutions.

The Point

EPM solutions if approached correctly must be seen as the acronym implies, “Enterprise” in scope.  Similar to their ERP counterpart, EPM solutions can and in many cases should be implemented modularly, but under the auspice of an overall Solution Deployment Strategy.  Notice the term “Solution” not “Application”.  Applications are but one component of the EPM strategy.  Others include: Technical Infrastructure, Data Management/Governance, Process Integration, Communication/Change Management, and Administration & Support.  When you view EPM solutions from this perspective it is hard not to appreciate the level of involvement required from Executive Leadership, The Business, and Information Technology.  Organizations must think of their EPM solutions as “ERP Projects”; enterprise enabling solutions that require the establishment of well documented and endorsed strategy that align with the corporate directive.   In this vain, EPM requires a realistic investment of resources, time and capital to be successful.   Then again, you could pull away from the car lot with a 1971 Pinto and hope no one hits you from behind…

 
/0 Comments/by