To SSL or not to SSL

 The use of Secure Sockets Layer (SSL) within an EPMS deployment is a fairly controversial topic. Generally SSL is not necessary from an EPMS implementation perspective. Yes, we’re dealing with corporate financial data, and therefore extremely sensitive material. However, we’re also talking about an Intranet Only application. SSL is used in conjunction with EPMS implementations approximately 20% of the time. The fact that few EPMS clients utilize SSL should not preclude prospective clients from considering its use. However there are other things to consider when discussing security.

A common practice is to tie the Oracle EPM System into a corporate Single Sign-on System (SSO). When a user accesses a web application secured by SSO, a Security Token is generated for the user. This token contains the user’s credentials and is passed to other web applications that accept SSO tokens. The token eliminates the need for the user to enter their credentials each time they access a corporate web application. The added convenience comes with a significant risk. The security token is valid for a set amount of time, typically for 30 minutes to 1 hour. If a user were to walk away from their workstation leaving it unlocked, anyone could access the EPM System using the cached security token. This would bypass all security measures; SSL, EPMS Security, Firewalls, etc. Most corporations have a policy to lock workstations when they’re not in use. However, it’s common for that policy to be ignored at least by some users.

Before deciding to add additional complexity to an already complex system, clients should consider all potential risks and eliminate ‘low hanging fruit’. Once the decision has been made to move forward with SSL, the next step is to decide which method to use. There are three (3) common methods for implementing SSL with Oracle EPMS; SSL Offload, SSL at the Web Layer, and Full SSL. The first two (2) options are straight forward from an implementation and support perspective. The last option adds significant effort to both implementation and support. These options, along with their pros and cons will be discussed in a future Blog.
--Author, Damon Hannah

Oracle Security Alert for CVE-2011-5035

This alert from Oracle addresses a specific type of Denial of Service attack to WebLogic only.  No data is at risk and the alert specifically notes that malicious users won’t be able to access the environment.  However, during the attack (like any Denial of Service attack), normal users will be unable to access the environment as well.
 
A set of WebLogic patches have been released to addressed the issue.  However, since the overall risk is very low to the average Hyperion users, application of this patch is does not need to be a high priority unless the WebLogic server is publicly accessible (not firewalled).  WebLogic patch ID is 13583186 and has only been publically available for one week.

--Author, Tony Moyers

Essbase Server Clustering

At long last, after many years of customer requests, and many unsupported, creative workarounds, Oracle now has an officially supported Essbase clustering method.  This is a software based, active-passive cluster, using Oracle's OPMN (Oracle Process Monitoring and Notification service).  Due to the nature of Essbase, and its agent's need to have exclusive locking rights of files associated with applications and databases, only one agent can be active at any given time.  But, what OPMN does is provide automatic fail over, high availability and write-back to the other Essbase agent, upon failure of the active agent.  The only capability missing is load balancing.

This new functionality was first introduced with EPM System 11.1.2, though there have been many issues in this first release.  Oracle recommends implementing Essbase clustering in EPM System 11.1.2.1.  In addition, you need to apply OPMN patch 11744008, which resolves some known issues with OPMN.  What Essbase clustering still doesn't give you is live backups, but, Oracle is supposed to be working on finally making that a feature for future releases.  

An active-passive Essbase cluster can contain two Essbase servers. To install additional Essbase servers, you must install an additional instance of Essbase, either on the same server, which would really not be recommended, since you still have a point of failure of the physical hardware, or another physical server, which is recommended. The applications must be on a shared drive, and the cluster name must be unique within the deployment environment.

These types of shared drive are supported:

1. SAN storage device with a shared disk file system supported on the installation platform, such as OCFS.
2. NAS device over a supported network protocol.

Note: Any networked file system that can communicate with an NAS storage device is supported, but the cluster nodes must be able to access the same shared disk over that file system.  SAN or a fast NAS device is recommended because of shorter I/O latency and fail over times.

Essbase cluster initial setup occurs on the first instance of Essbase, where you define the Essbase cluster name and the local Essbase instance name and instance location, using the EPM System Configurator.  This version of Essbase still uses the old variable name of ARBORPATH, but, the variable itself is now used to define the location of the application files, not the location of the Essbase system files, as in previous versions Essbase. 

All of this information is stored in the EPM System Registry, which is stored in the Shared Services database When you setup each instance, not only for Essbase, but for the entire system, you connect to the Shared Services database so that the same EPM System Registry is in use for the entire system. OPMN also reads the Essbase cluster information from the EPM System registry and keeps track of the active node there.

When you setup the second instance of Essbase, and connect to the same EPM System Registry, you will be presented with an option to join the previously configured cluster, that was setup on the first instance. All information regarding the previously configured cluster will automatically populate and will be grayed out.  Once you complete the setup, with the EPM System Configurator, there are still quite a few manual steps that must be taken to update OPMN configuration files, on each Essbase instance. Consult the EPM System High Availability guide and Oracle EPM System Installation and Configuration guide for more detailed information on the manual changes required to complete the setup.  Happy Clustering!

--Author, Larry Lapp

Clustering Essbase Administration Services

In an EPM Planning environment, there must only be one Essbase Administration Services (EAS) Server in any given environment.  One of the most common mistakes when it comes to implementing an EPM planning environment involves EAS and not Planning.  Many architects try to load balance EAS, or install more than one for fault tolerance, or just for convenience and install EAS wherever they install Essbase.  In fact, if you read the latest documentation in 11.1.2, the High Availability and Disaster Recovery guide says you can use Weblogic Clustering for high availability.  Years of practical field experience and support cases say otherwise.  

The problem is one of functionality. Specifically the functionality in Business Rules (HBR) and its relationship with Hyperion Planning.  In almost every Hyperion Planning environment, Business Rules are in use.  Calc Manager has simply not gained enough momentum yet.  The functional problem that requires only one EAS server is around how Planning and HBR communicate.  In business rules a rule is assigned to a "Location".  These are usually in the format > PlanningServer/PlanningApplication/Cube.  They are seeded into HBR as applications become "active", and can then be assigned.

If you have installed or administered Hyperion Planning, you know there are two Planning services, or components, that have to be running. The first is the Planning Web Application itself.  The other, the Hyperion RMI Registry.  Planning notifies HBR that a location is available or "active" when someone logs into a planning application for the first time by sending a message through the RMI registry service to the HBR server.  It knows where the HBR server is because it's stored as a property in the HBRServer.properties file found either on the file system (pre 11.x) or in the EPM System Registry.

When there are more than one EAS servers it will only notify the EAS server registered in the HBRServer.properties file. The properties file stores only one server name. The result is business rule development on any EAS server but the registered EAS server lacks the functionality to assign planning locations to business rules. Even if the EAS servers share a repository, the second server might be able to see the locations, because it shares the same schema, but the locations can fail to connect because the RMI connectivity fails.

If you are not using HBR you may be able to install multiple EAS servers in an environment.  But consider EAS as an administrative tool, and not an end user tool.  It does not support any functionality that requires high availability.  If you want to install the admin client on every Essbase server that makes sense, but there should not be a need for more than one EAS server. If you are using HBR a single EAS server is a must, so why architect yourself into a situation that can limit functionality should your client decide to use HBR down the road.

Author: Mike Turner

FDM 11.1.x Issues Loading Periodic Data

Overview

When using Oracle Hyperion Financial Data Quality Management (FDM) to load data into Oracle Hyperion Financial Management (HFM), you have the option of specifying the DataView as either year to date (YTD) or periodic.

By default, FDM loads HFM with year to date formatted files.  In this case, the user does not need to specify the DataView.  However, some data sets are required to load as periodic, most notably Budget and Forecast scenarios.  To load periodic data, you specify the DataView in the location's corresponding import format.

Since FDM version 11.1 and later there has been two known issues preventing FDM from loading periodic data into HFM.  Below is an overview of the issues with information on how to correct them.

Part 1 - Export Script Does Not Properly Handle Periodic Data

The first issue requires a change to the HFM Export adapter script.  The script is missing essential code necessary in identifying and processing periodic data.  The code change requires a new block of code to assess the DataView of the current processed record.

Oracle Information

• Oracle Knowledge Base ID: 840319.1
• Oracle Knowledge Base Article: Periodic Data Export Fails Loading into HFM with "No Such Member PER" [ID 840319.1]
• Oracle Bug ID: 8588253
• Version Impact: Release: 11.1 and later, including 11.1.2.1

Part 2 - Intersection Validation Fails When Processing Periodic Data

Issue # 2 requires another adapter script change, this time to the CheckIntersections adapter script.  This script is executed during the Validate workflow step.  Without changes, the CheckIntersections adapter script truncates the periodic label value - "PERIODIC" becomes "PERIO".

Oracle Information

• Oracle Knowledge Base ID: 838559.1
• Oracle Knowledge Base Article: DataView is Truncated from Periodic to Perio and Causes a Failure During the Intersection Validation for Financial Data Quality Management (FDM) [ID 838559.1]
• Oracle Bug ID: 8580652
• Version Impact: Release: 11.1 and later, including 11.1.2.1