Technical

Oracle EPM 11.1.1.3 - Installing Hyperion Components on Multiple Machines

Venkatakrishnan J

• 9 min read

In any EPM deployment, rarely do all the components get installed on a single machine. In majority of the cases, you will see that each component is actually installed on separate machines with their own application and web servers. So, how does this all work and how do we go about installing various EPM components across multiple machines? I plan to cover this today and will try to compare the architecture of EPM deployment along with BI EE deployment.

One major problem with an Oracle EPM installation is in the number of components involved and the dependencies among them. Immediately after the Hyperion Acquisition (with the EPM 11 release), Oracle has done significant improvements to the end to end install. The entire installation/configuration is now more or seamless through the EPM system configurator. Though it is much easier to deploy an EPM system now, there still are quite a few components that we need to be aware of while doing a distributed deployment. It would always help if we can understand how they interact with each other. Oracle EPM system has the following products

  1. Oracle Shared Services - Grouped under Foundation Services
  2. Oracle Workspace - Grouped under Foundation Services
  3. Oracle Planning
  4. Oracle Essbase, Essbase Admin Console, Provider Services, Studio
  5. Oracle Enterprise Performance Management Architect
  6. Oracle Financial Reporting, Web Analysis, Interactive Reporting & Production Reporting
  7. Oracle Financial Management
  8. Oracle Scorecards
  9. Oracle Data Integration Management (DIM with its adapters)

There are other components as well(like CMC etc). But above 9 are the most commonly used ones. If you consider the number of products and how they can all work together you can imagine that we can never get the full performance out of them if we install all the components in a single machine. So, to get the maximum performance out of them we need to identify an architecture where each component can be clustered separately but at the same time work in tandem with the other components. At a high level from a deployment standpoint i have depicted the entire Oracle EPM architecture as shown below

Picture 16

The actual deployment can (web & app servers can be swapped, reused, added etc) vary but the above will give a high level conceptual overview of what components we will need in every machine in a distributed installation. Every component can work in isolation or can be brought together through a common workspace.

The above architecture will also provide an overview of how we need to go about adding new components to an existing installation. Every component, for example hyperion planning, has its own web interface (http://machineA:8300/HyperionPlannig). So in a distributed environment, every machine requires an application server, a web server and the component itself. There are some components like Essbase that do not require application servers and web servers. But for the sake of this discussion lets club Essbase installation with EAS, Provider Services and Essbase Studio. But remember most of these web enabled components are brought together in a single interface through Workspace (For ex. http://machineC:19000/workspace). How does that work? Also, Workspace has its own Application Server and Web Server (http://machineC:45000/workspace) which works in a standalone mode without any component integration.

For security reasons, all the web enabled components do not talk to each other directly since they can typically reside in multiple hostnames (possibility of cross domain scripting). So, Oracle EPM combines all the components together into a single web enabled workspace (http://machineC:19000/workspace) either using an Apache HTTP Server or an IIS Server. One distinctive advantage of this is it provides a means of complete security where there is a need to expose the components over the web. In such cases, we can just put the web server alone to be internet facing and everything else inside a DMZ and then put a firewall (on both sides of the DMZ) to protect the corporate intranet. There can be other variations like multiple firewalls across multiple layers but the point is it provides flexibility

I think Oracle/Hyperion also did this for a couple of other reasons

  1. Workspace was a product that was introduced, much after Planning and Essbase, EAS etc to bring them all together. So, they had to find an architecture where every component will be in a different machine but at the same time should be able to work together through a common console
  2. Incremental product/component purchase. If someone purchases Planning along with Shared Services today, they can add more components like BI EE etc later and will still be in a position to bring them all together.

One more point to note is, multiple components can be installed on a single machine and then deployed on to the same application and web servers. So, depending on the usage, performance required, an optimal number of servers required etc can be arrived at before doing a deployment. Lets look at a very simple distributed deployment scenario today. We will start with the first component which is shared services. The application server i will be using is Weblogic Server 9.3. Other app servers are supported as well. But ensure that, for the workspace integration to work the application server used for workspace deployment will have to be used for other components as well.

Picture 17

The order of installation of various components can be different. But the configuration should be done in a certain order. In our case, on MachineA we will start with shared services installation. Once the installation is done, install Weblogic Server on that machine as well. Ensure that while installing weblogic server, you choose the servlets option. This is what will enable the Apache redirects between the main workspace http server and individual Weblogic embedded http servers through mod_so.

Picture 10

After the installation, install an Oracle Database or use a new database schema from an existing database instance. The Oracle client installation on any of the machines is not necessary as the connections happen through JDBC with pre-bundled drivers. Start the configurator and then point to a database schema specific to sharedservices. It is a standard practice to have one schema for each component.

Picture 11

Picture 7

Choose the automatic deployment for Oracle Weblogic 9. Also enter the Weblogic home. During deployment, a weblogic domain for Hyperion is automatically created(no need to create before hand). If multiple components are deployed at the same time, all the components will be deployed onto the same domain. Once the deployment is successful, ensure that shared services is up and running. Shared Services has to be up and running for other components to be configured from other machines.

Picture 14

Once the shared services is installed and configured, we can move on to other components. In my case, i will install Workspace & Planning together in another machine.

Picture 19

Picture 6

Once the install is done, install Weblogic server again in this machine (i believe using weblogic node manager it is possible to use a single em managing multiple instances of weblogic, but i will leave that for now). While installing ensure that the Servlet Plugins option is enabled as well. In this we will configure 2 components(Planning & Workspace) on to a single weblogic domain. Start the EPM configurator.

If you have other components installed on other machines, while in the system configurator, do not check the "Configure Web Server" option. This is always done at the end once every component is registered with shared services. This option basically configures the URL redirects from the main HTTP Server to the individual component http servers. In our case, since we do not have any other component to install, we shall choose every option available for Workspace and Planning (Except clustering). Every other configuration remains the same. The only addition is in the Web Server configuration. You will notice that all the web enabled registered components will be listed in the web server configuration screen

Picture 15

You will also see components along with their machine names as well. This will ensure that Workspace can automatically make redirects to other applications using its http.

If you notice this is very different from a BI EE deployment. BI EE has only one web facing component which is through the http server and the presentation services Plugin(deployed in the Java Container). Every other component like Presentation Services, BI Server talk to each other through specific ports but are not web enabled by themselves. The main reason is, BI EE itself is a single product. Presentation Services alone will not make sense without the BI Server. BI Scheduler cannot work in isolation. So, in effect, this comparison itself is not valid since we are comparing a multiple product deployment (EPM) with a single product deployment i.e BI EE. But if you look at the whole architecture in the first figure, it blends overall with the entire Oracle EPM universe story. The integration of BI EE with Oracle EPM is very similar to the integration of Hyperion Planning with Workspace. End users connect to the Workspace http server. When BI Presentation Services is chosen, Apache does a redirect to the local apache of the app server on which BI EE is deployed. But what is not seamless yet is the security integration. In the case of Planning, Workspace etc, since Hyperion itself developed it, all of them more or less followed the same security model. But in the case of BI EE, the security model is completely different. Hence Oracle i believe, had to come up in some way to pass the SSO tokens from EPM to BI EE and then make BI EE to recognize them. Hopefully this integration will become more seamless with future releases of EPM and BI EE. I can envision BI EE becoming the core of reporting in the EPM architecture replacing Web Analysis.

Lets look at the list of steps that we typically go through while integrating BI EE with EPM Workspace.

  1. We start with Registering the BI EE into Hyperion Shared Services Registry (using BI EE Administration->Manage EPM Connection tab). This step enables the configurator to recognize BI EE as another EPM product. This will basically enable apache redirects between the EPM Workspace HTTP Server and the BI EE http server.

  2. Once the registration is done, we enable BI EE to recognize the Oracle EPM SSO tokens (as the security model is different). This is done by adding the the following configuration tags to instanceconfig.xml

<Auth>
 <ExternalLogon enabled="true" logonPageAllowed=”true”>
   <ParamList>
      <Param name="UID" source="url" nameInSource="sso_token"/>
      <Param name="PWD" source="constant" value="obips.hss.ssotoken"/>
   </ParamList>
 </ExternalLogon>
</Auth>
  1. There are a couple of ways in which the EPM SSO tokens can be recognized by the Javahost. One is through the cssURL method wherein the CSS values are derived from the cssURL. The cssURL can be verified using the URL http://machineA:28080/interop/framework/getCSSConfigFile. If you query this, it will generate an XML as shown below
<css>
	<hub location="http://esscluster1.venkatlap.com:28080">
		<dirPort>28089</dirPort>
	</hub>
	<spi>
		<provider>
			<native name="Native Directory">
			</native>
		</provider>
	</spi>
	<searchOrder>
		<el>Native Directory</el>
	</searchOrder>
	<token>
		<timeout>480</timeout>
	</token>
	<logger>
		<priority>WARN</priority>
	</logger>
	<delegatedUserManagement>
		<enabled>false</enabled>
	</delegatedUserManagement>
</css>

Javahost can extract the required values out of this config XML itself. But in many cases, since this can be extracted directly from sharedservices registry, there is an option to specify the HYPERION_HOME registry property file within Javahost so that it can communicate with sharedservices and authenticate accordingly.

  1. The next step is to make sure BI Server authenticates against shared services using the custom authenticator.

  2. Once all the above are done, we need to enable the apache from Workspace through the EPM configurator to redirect requests for BI EE to the app server on which Presentation Services plugin is deployed.

If you look at it from an overall perspective the only complicated piece is in the enabling the EPM to BI EE security. But hopefully in 11g, BI EE would have the same authentication model like Oracle EPM. If that is the case, the only configuration that we probably would have to do is the first and the last steps i.e register with shared services and then enable apache redirect. Now, how about bundling BI EE along with the EPM installer(i think we might even see this in the coming future). Even that will become straightforward like other Hyperion Components once the security model is straightened out hopefully in 11g(again based on rumours in the public domain). Now we can realize why Oracle is planning on moving BI EE towards a common security framework. Its all for seamless integration with Oracle EPM. But again from a shared services perspective, i think there need to be significant improvements there. From a provisioning standpoint, shared services does not have a good integration with Essbase or with BI EE currently. Now, only if they can revamp shared services with more Essbase & BI EE specific provisioning capabilities, it will become all the more interesting.

Sign up for more like this.

Enter your email
Subscribe