“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.
- Defining an Architecture – Work with the client to define the hardware, software, and the distribution of Hyperion components
- Provide Pre-Installation Requirements – Provide the client with a detailed list of activities prior to the installation
- Installation – Running the installation and configuration utilities
- Validation – Perform all functional activities necessary to validate the environment readiness
- 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.