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

 

Server

Notes

Oracle Application Server 10g (10.1.3.3.x) a

If Oracle Application Server is used as the Web application server, Oracle HTTP Server is also required.  Profitability and Cost Management supports only Oracle Application Server 10.1.3.x.

Oracle WebLogic Server 9.2 (MP1 minimum) / 9.2.xb

Shared Services requires WebLogic Server patch CR283953” for all platforms. You can obtain this patch at the BEA web site.

IBM WebSphere 6.1.0.17 / 6.1.x C

 


Embedded Java container d

 


a Supports these editions: Java, Standard One, Standard & Enterprise. Includes support for Oracle Application Server Single Sign-On.

b WebLogic Express is supported for each supported version of WebLogic Server; non-base versions are supported only via manual deployment.

c WebSphere Express, ND, and XD Editions are supported for each supported version of WebSphere; ND and XD are supported only via manual deployment.

d For this release, Apache Tomcat 5.5.17 is the embedded Java container that is installed automatically on all platforms. Apache Tomcat is supported only in this capacity. If future EPM System releases embed different Java application servers, Apache Tomcat will no longer be supported. For deployments that require high availability or failover, Oracle recommends using a commercially supported Web application server that supports high availability and failover.

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. 

 

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 2nd installment, I will review the pre-installation activates that need to occur before the installation begins.

Overview

The SQR Production Reporting module generates high volume, presentation-quality formatted reports with unparalleled performance—even when the data is taken from disparate sources. This reporting application delivers business context for key metrics by consolidating information from core business applications throughout the enterprise.

Product History

Since the mid-1980s, SQR Reporting has been part of numerous reporting suites with companies such as Sybase, MITI and Brio Software.  Prior to the Hyperion acquisition of Brio in 2003, the product was distributed under the name Brio Reports.  The product then became part of the Hyperion Performance Suite as Hyperion SQR, pre-System 9.  Hyperion SQR included SQR Activator, SQR Server, SQR Viewer, SQR Developer and SQR iServer.  As part of System 9, these modules were integrated and packaged as Hyperion Production Reporting.  With release 9.3, the product was changed to its current name, Hyperion SQR Production Reporting.  The product is currently part of Oracle’s BI Enterprise Edition Plus (OBIEE+) suite. 

Strengths / Benefits

  • User Friendly GUI - delivers its comprehensive enterprise reporting capabilities through a graphical report creation environment and a powerful 4GL reporting language (called SQR) for advanced reporting and data processing.
  • Multiple Data Sources - Including IBM DB/2, SAP R/3, SAP NetWeaver BI, and SQL Server.
  • Flexible and Scalable - Report designers can take advantage of SQR Production Reporting's comprehensive report lifecycle management, flexible formatting, layout, and distribution options. Additionally, SQR Production Reporting provides proven, massive scalability through report bursting, and reduced processing time from single-pass production of reporting jobs.
  • Common Infrastructure - Shares common administration, user management, and installation and configuration support with other Hyperion BI modules of Oracle Business Intelligence Suite Enterprise Edition Plus.

Resources