Hyperion Enterprise Performance Management System Installation and Configuration Guide Release 11.1.1.2 (252 Pages) and Oracle Hyperion Enterprise Performance Management System Manual Deployment Guide Release 11.1.1.2 (160 Pages) are a wealth of knowledge.  I know because I have read a great deal of it and keep them quite close during each engagement.  Most of what you need to know is available in the documentation and a good deal of additional knowledge can be found on the support forums.  I do not want to rehash the specifics of the installation and configuration.  There are just too many variables to cover everything without reposting most of the already prepared material.  What I hope to provide here is just a primer on architecture considerations and general installation activities with this release.

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 1 that you, as the Hyperion architect, should deliver.  Steps 2-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.

Defining the architecture is somewhat difficult, especially if you do not have a good understanding of your organizations’ usage patterns or platform preferences.  Below are the core questions that need to be answered to define the necessary architecture.

How many servers will be needed?

The number of servers depends on a lot of things.  Below is a sample of some of the questions I typically ask when recommending the server infrastructure.

• How many users do you have?
• Will you be leveraging an existing Relational Database Platform?
• What products did you purchase?
• What products do your users use most frequently?
• Will you be using loadbalancing?

Let’s assume the answer is 100 users, the client has an existing Oracle database I can leverage, the client purchased HFM and Planning, and the client uses a lot of Financial Reports.

With these assumptions, you will want to make sure the Workspace and Reporting platforms are a decent size and the reporting application services reside on a separate server from the application servers.  In addition, since you are going to leverage an existing relational database, you can plan on having a stand-alone data tier for Planning and Essbase.  Just to further simplify the matter, let’s assume there is no load balancing and clustering.  For our example discussion, I will assume 3 servers will be included in the architecture.

What would be the system specifications and Operating System?

Once again, the answer to this question can vary widely based on the answers below.

• What operating systems does your organization support?
• How long do you intend to use this hardware?
• Will you be using virtual machines?
• Will you be using shared or local disks?
• How much data do you have now and what does your growth look like?

Keep in mind that HFM requires a Windows Server so I will need at least one of those.  It may be simpler from an administrative perspective to have a homogeneous OS infrastructure but it is not necessary.  If you have no preference, this is what I would typically go with.  If you have a propensity for some flavor of UNIX, then I would go that route where applicable.  Many organizations keep hardware in place for up to 3 years.  With that in mind, I think the best approach is to buy the most robust and powerful hardware you can afford.  The cost of migrating in 24 months will often be greater than the hardware spend.  VMware is quickly growing in popularity and I see deployments in virtual environments quite often with success.  Although Essbase does not require a physical server, I recommend that it not reside on virtual machines due to higher disk I/O.  It is also the application that is expecting the most growth.

What Web Application Server should we use?  Should it be Oracle Application Server 10g, WebSphere, WebLogic, or the Embedded Java container (Apache Tomcat 5.5.17)?

• What does your organization support?
• Do you have a license for anything?
• Will you need clustering?

First, some comments in favor of the Apache Tomcat server.  It is free and Hyperion does do some development on that platform.  So far, I have found it to be stable in most situations.  If your organization has a Web Application group, it may not be standardized on a version that is required by Hyperion.  In these instances, it may make sense to deploy Tomcat as opposed to a version of WebLogic or WebSphere that your organization does not support.  Additionally, if the organization is upgrading its application server farm in the future, Hyperion may be an outlier.

Now for the downside, there isn’t really any help desk you can call for Tomcat outside of Hyperion.  Unless your organization has a few other Tomcat servers, there is likely to be a learning curve in the administration and support.  Then, there is always the question of scalability.  Clustering with Tomcat is quite a bit more complex.  Our common recommendation on application servers is that you should use what you know.  If you do not know anything about application server administration and do not have a huge user base, Tomcat is probably your best choice due to its ease of installation.

One rule of thumb is that you can expect a single Tomcat instance to handle 25-30 concurrent threads comfortably.  The practical maximum is 50 per instance.  If you are using other sorts of Java servers, it is a good idea to review with those administrators their experience with free servers.  In a development environment, one could benchmark how Hyperion EAR and WAR files behave in comparison to those of other Java apps.

With all these assumptions, I deliver a Viso diagram detailing which components go on which servers with general recommendations for server sizing and operating systems. 

In our 2^nd installment, I will review the pre-installation activates that need to occur before the installation begins.

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.