"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.

There are a host of new features in version 11.  As with most product releases, there are the typical improvements related to memory, scripting, and stability.  But, there are some other, very notable, functional additions that might peak your interest. 

Lifecycle Management

Shared Services now provides a consistent way to manage environments.  This console gives administrators the ability to compare applications, search for artifacts, and perform artifact migrations. It comes with a command line tool to automate tasks, as well as a full API for those who want to customize the process even further.

Typed Measures

Essbase now stores text!  Well, somewhat.  Text measures give administrators a way of storing a value other than a number in a data intersection.  Technically, it still stores numbers, but it represents a string.  A member in the measures dimension can have a text attribute.  This member is associated with an enumerated list.  Each member in that list has an index number, which is what is in the database.  When reporting is done, that number is converted to the associated text value in the enumerated list.  Members can also be tagged as Date, which changes the formatting to; you guessed it, a date.

Varying Attributes

Attributes have been around for a while now in Essbase.  Some people hate them and some love them.  They definitely have their place in the design of a database.  One limitation has been the inability to walk forward attributes over time.  For example, assume we have an attribute that identifies our customers into tiers based on their credit score.  If a customer’s score changes such that they move to a higher or lower tier, the history is lost because their attribute is the same for all time periods.  Not anymore.  Varying attributes adds the capability of Essbase to store, and calculate measures for attributes that vary over multiple dimensions.

Backup and Recovery

I have seen many methods to making sure Essbase applications are secured.  In version 11, there are some new options for BSO databases.  First, an option in EAS exists to backup the entire database, including its data and all of its objects, to one file.  When changing things rapidly through the day, this is a nice feature to ensure you don’t lose valuable work.  The entire database can easily be restored.  This is much quicker than manually archiving all the objects (calc scripts, load rules, outlines, and reports) and keeping data exports. 

Secondly, Essbase now includes the option to log transactions and replay them.  With this option turned on, Essbase applications can be restored with the option to replay all transactions that occurred after the backup occurred.  Now, a database can be restored to a specific point in time.

ASO Data Management

ASO now includes Maxl scripting to enable administrators to clear data from regions of a database in two ways.  The first and most obvious is to remove the values from the database.  The second is the ability to copy the data into another member as the inverse, resulting in a total of zero.

The use of Environment Variables

If your process management uses variables to decrease maintenance tasks from, this might be something that will intrigue you.  Version 11 has access to not only Essbase variables, but operating system environment variables as well. 

Monitoring Environment Reponses

Many environments take advantage of partitioning.  Now, there is a way to evaluate the cost of using partitions.  Using the ENABLE_DIAG_TRANSPARENT_PARTITION configuration setting in the essbase.cfg file, administrators can log transaction response times.

Common Log Locations

Version 11 organizes all log files in one location.  This is a very nice improvement.  Rather than searching through each products’ directory tree for the area logs are stored, they are now located in one common folder, with a folder for each of the Hyperion products.

Override Implied Shares

Essbase now includes an option in the outline management section to ignore the default setting for implied shares.  This can be very helpful when using partitions, as well as a host of other situations.

Notable Calculations Additions

Now that members can carry a text or date value, there are a host of functions that open up a whole new realm of possibilities.  DATEROLL will increase a value based on a specific time interval.  DATEDIFF will take the difference between two dates at the interval designated.  DATEPART will pull the time period (week, month, day, etc) from any date.  These operations were difficult at best, in previous releases of Essbase. 

“Pre-Installation Requirements”

In installment #1 of this guide, we reviewed the architecture considerations and defined a simplistic architecture to use as a reference moving forward.  I recommend you read the previous post before you pick up this one.  I also recommend reading

“Oracle Hyperion Enterprise Performance Management System Installation Start Here Release 11.1.1.2.pdf (128 pages)” from the Oracle Documentation Library.

To reiterate our general approach, the Hyperion architecture establishment and installation activities in our organization cover the following five areas.

1. Defining an Architecture – Work with the client to define the hardware, software, and the distribution of Hyperion components
2. Provide Pre-Installation Requirements – Provide the client with a detailed list of activities prior to the installation
3. Installation – Running the installation and configuration utilities
4. Validation – Perform all functional activities necessary to validate the environment readiness
5. Documentation – Provide the client with all the details of the environment as it is configured.

In this post, I will go through step 2 that the Hyperion architect, should deliver.  Steps 3-5 will be available in the coming weeks.  For the sake of simplicity I will be using the example of a common installation, primarily Hyperion Planning, Hyperion Financial Management (HFM), and the core BI applications.

As part of any installation, some items need to take place before the Fusion Installer is started.  I like to create a checklist of things that need to be done.  Often times these things are out of my control and I will rely on Database Administrator, Network Administrators, and other System Administrators.  This checklist contains the following elements.

• Web Application Server Specifications
• Relational Repository Information
• General System Administration
• Network Information
• Additional Components
• DCOM Configuration
• IIS and .NET Configuration

I’ll start with the Web Application Server Specification.  Once the web application server platform is chosen from the table below, the installation and configuration often falls on System Administrators.  Items such as clustering, system account management, and JVM setting are managed outside of the Hyperion installation.  Other times, I’ll get admin access and manage it myself.  The first item to do is to validate the application server is certified.  This is directly from Oracle Enterprise Performance Management System - Supported Platforms Matrices “Oracle Enterprise Performance Management System, Fusion Edition Release 11.1.1.2)” in the Oracle document library.  I recommend reviewing this document.  It can change from release to release.

I request the URL and authentication information since this will be needed during the deployment.  If I am doing a manual deployment, I will request contact information from the web application server administrator and work in collaboration on the deployment.

The next item on my checklist is to get the Relational Repositories Information set up.  This is mostly straightforward.  In general, I like to create a tablespace/database for each component ((Hyperion Foundation, Essbase Admin Services / Business Rules, EPMA, Planning, Financial Management, etc).  A distinct tablespace/database for each component makes it easier to manage in my opinion.  Although it may not be strictly necessary, the documentation does not seem to be clear on the matter.  I say ‘better safe than sorry’.  For the installation and deployment, I’ll need credentials for each table.  Based upon some Q&A, I’ll make initial size recommendations. 

The target installation servers have a General System Administration checklist containing the information that I’ll need to execute the installation.  This is made of the following items.

• Operating Systems version/build
• Account on each server to run the Hyperion services and account requirements
• External Authentication information (MSAD, LDAP, or OID if applicable)
• Drive/Volume information identified for installation of the Hyperion software.
• DCOM and .NET account information if HFM or FDM are to be installed

Next, I identify the Network Information necessities for appropriate communication between servers.  This includes IP addresses, DNS information, validation of name resolution, trace between servers, subnet configuration, etc.  This is vital so the components can communicate via Fully Qualified Domain Name, Short Name, and IP address.  Some components use different variations of name resolution probably because the components were developed separately and have not been fully standardized.

In addition to the Hyperion Software, Web Application Servers, and Relational Repositories there are a few Additional Components that need to be installed.  A PDF writer is needed for Reports Server to render .pdf reports in Workspace.  This can be GhostScript or Acrobat distiller.  I suggest referring to the “Start Here” documentation to see what is currently supported but we often go with GhostScript due to its cost.

For the Windows Administration, we provide the DCOM Configuration information needed to support FDM, EPMA, and FDM.  This includes the DCOM account information, permissions, and authentication information.  Although this is spelled out in detail in the “Start Here” manual, I like to provide step-by-step information with screen shots since DCOM is often confusing…well it is to me at least.

The last thing we review is the IIS and .NET Configuration.  IIS is often not installed as part of a standard OS build.  We make sure this requirement is specified, ensuring .NET is installed, and validate it is the appropriate version.

As with any installation, I recommend the Installation Architect read, and re-read, the Hyperion Manuals on there own rather than relying on this information or intuition.  It can always change and your installation may have some caveats that I have not covered.  For our purposes, with all the above activities completed and validated, we should be ready to start laying out the binaries and start the Hyperion Installation.  We will review the Fusion Installer and Hyperion Configuration Utility in our next installment. 

There are many considerations that must be carefully planned when addressing an upgrade to version 9 or 11, or creating a backup strategy.  Manually moving all the components involved can take days and is extremely error prone.  There is more to it than moving Essbase databases.  Essbase calc scripts, reports, and load rules have to be considered.  Server variables need to be moved.  All the Maxl and EssCmd scripts need to be copied and changed to reflect the new server and security model.  Security filters need to be copied and altered slightly if moving to a new version of Essbase.  All the security users and groups need to be created. As with any endeavor of this capacity, it can be time consuming. The benefits of the improved stability and features far outweigh the efforts. 

Completing this for one server is tough enough.  Imagine if corporate policy dictates that everything has to be done in a QA and/or test environment before it is moved to the new production area.  Now factor in the number of Essbase servers and the fact that the security model might have to be consolidated to one (this occurs when upgrading from anything before 9, to version 9 or 11).  Don’t forget that there is only a very small window for the current production servers to be down.  If 4 Essbase servers exist, this effort might have to occur 12 times! 

Doing the same work 3 times for every server is obviously redundant.  I developed a small .NET application that significantly reduces the work involved.  It virtually eliminates the need for any manual or redundant effort.  .NET was selected because it was the quickest for me to develop the application, but JAVA, Perl, or any other similar development language could be used.  The .NET application accepted the results of the following Maxl display commands.

display application all;
display database all;
display filter row all;
display variable all;
display privilege group all;
alter system load application all;
display partition all advanced;

Maxl scripts were created from the process to

1. create all the applications and databases
2. assign all relevant application and database settings
3. rebuild and update security filters
4. replicate all server variables

This Maxl can be executed on the destination server to setup the new environment.  Examples of the scripts generated from the .NET application below.

/* Create Application:  BUDGET */

create or replace application 'BUDGET' type nonunicode_mode;
alter application 'BUDGET' set lock_timeout after 300;
alter application 'BUDGET' set max_lro_file_size unlimited;
alter application 'BUDGET' set minimum permission no_access;
alter application 'BUDGET' enable startup;
alter application 'BUDGET' disable autostartup;
alter application 'BUDGET' enable commands;
alter application 'BUDGET' enable updates;
alter application 'BUDGET' enable connects;
alter application 'BUDGET' enable security;

/* Create Database:  BUDGET */
create database 'BUDGET'.'Budget';
alter database 'BUDGET'.'Budget' set data_file_cache_size 1024000000;
alter database 'BUDGET'.'Budget' set index_cache_size 76800000;
alter database 'BUDGET'.'Budget' enable startup;
alter database 'BUDGET'.'Budget' enable autostartup;
alter database 'BUDGET'.'Budget' set minimum permission no_access;
alter database 'BUDGET'.'Budget' set retrieve_buffer_size 102400;
alter database 'BUDGET'.'Budget' enable two_pass_calc;
alter database 'BUDGET'.'Budget' enable aggregate_missing;
alter database 'BUDGET'.'Budget' enable compression;
alter database 'BUDGET'.'Budget' disable create_blocks;
alter database 'BUDGET'.'Budget' disable committed_mode;
alter database 'BUDGET'.'Budget' set implicit_commit after 10000 blocks;
alter database 'BUDGET'.'Budget' disable cache_pinning;
alter database 'BUDGET'.'Budget' set retrieve_buffer_size 102400;
alter database 'BUDGET'.'Budget' set compression bitmap;
alter database 'BUDGET'.'Budget' set retrieve_buffer_size 102400;
alter database 'BUDGET'.'Budget' set retrieve_sort_buffer_size 102400;
alter database 'BUDGET'.'Budget' set data_cache_size 512000000;
alter database 'BUDGET'.'Budget' set io_access_mode buffered;
alter database 'BUDGET'.'Budget' set note '';
alter system unload application 'BUDGET';

/* Create Filter:  MRP100206310000 */
create or replace filter 'BUDGET'.'Budget'.'Audit' write on '@DESCENDANTS("Time"),@DESCENDANTS("Year"),"Input","Working Budget",@DESCENDANTS("Product"),@DESCENDANTS("Total Audit"),@DESCENDANTS("Expenses")'; 

DOS and UNIX scripts were generated to copy all of the database objects, data files, and Maxl and EssCmd scripts from the source server to the destination server.  The program also created all the files to import into Version 9 and System 11 to add users, groups, and replicate the security model.  

All the Maxl and EssCmd scripts (username, password, server names, file paths, etc.) were updated so they could be executed on the new servers.  

This process makes it extremely simple to migrate, or move, any Essbase application from one server to another.  The entire process could be completed in hours, rather than days, and eliminates the possibility of human error.  What would be budgeted to take weeks with several resources can take less than a day.