The simplest and thankfully most common method for implementing SSL with the EPM Suite is SSL Offloading. Offloading refers to moving the SSL Certificates to a Load Balancer. This is a physical device that is used for load balancing network traffic to the EPM System. Offloading requires no SSL specific configurations within the EPMS Suite. Placing the SSL Certificates on a physical device also eliminates any performance concerns that can sometime arise from the use of SSL. It also simplifies maintenance associated with SSL Certificates within an organization by keeping all SSL Certificates in a single location.

The second option, SSL Terminated at the Web Server is more involved, however still fairly straight forward. By default most of the EPM System web components are accessed through OHS (Oracle HTTP Server) through redirects within the OHS configuration. Oracle is working to integrate the remaining components into OHS. The few that are not currently accessed, FDM for example can be added to the OHS configuration by modeling existing redirects. This creates a single point of entry for all EPMS web applications. SSL Certificates are assigned to the OHS web server and entries are added to the OHS configuration to direct inbound traffic to use SSL (HTTPS). By securing communication between clients and the OHS server(s) using SSL, and blocking direct access to the WebLogic deployed applications through Firewalls or ACLs, the desired SSL configuration is achieved. This configuration allows for non-SSL communication between the OHS web servers and the WebLogic or IIS EPMS web applications. However as all of this communication is server è server, there is much less exposure to security threats. Let’s face it, if someone can trace you backend network traffic you have bigger concerns!

The final option and by far the most complex is using SSL for both client è server communication, as well as backend server è server communication. In addition to securing OHS using SSL, all communication between OHS and the WebLogic and IIS web applications is also secured. This requires creating SSL certificates for each WebLogic server and each IIS web server. The SSL certificates must then be added to the WebLogic and IIS configurations. The EPM System must also be configured to use HTTPS for all internal communication. Given the ‘chattiness’ of the EPMS internal communications using Full SSL can have a significant performance impact. This configuration also adds to the complexity of supporting Oracle EPMS and increases maintenance as SSL Certificates are typically good for 2 years or less.

There are two additional options for using SSL within an EPMS deployment. The first is using SSL between Oracle EPMS Shared Services and the corporate External Authentication Directory, MSAD or LDAP. This is typically not a decision made by the implementation team or project, but is more of a corporate standard. This simply secures communications between the Foundation Server and the Active Directory or LDAP servers within the corporate domain. Traffic between the EPMS Components and their RDBMS server can also be secured through SSL. This is less common and requires more setup on the RDBMS side than with the Oracle EPMS configuration. The connection string given to the EPMS implementation team must contain the correct SSL parameters, and the SSL certificates must be added to the RDBMS clients for each EPMS server.

SSL is becoming more and more common within the Oracle EPMS landscape. If you’re considering implementing SSL with you EPMS deployment, please consider carefully your choices as your decisions will affect more than the initial configuration. Keep in mind other security holes in your environment and how to get the best security for your efforts.

Author Damon Hannah

We believe the scope of EPM includes the following:

All of the enterprise planning you do (financial and operational), including

• Annual operating plan
• Sales & Operations Planning (S&OP)
• Forecasting (sales, expense)
• Workforce, Project, Demand Planning, etc.

All of the financial & operational management reporting & dash-boarding you do

• Variance (to forecast, to plan, to prior)
• P&L (region, product, channel, LOB, etc.)
• All of the flash, statutory/external reporting

All of the financial & operational analytics you do:

• Trending, benchmarking, historic
• Customer & Product Profitability (including allocations)
• Price/Volume Mix analysis
• Statistical analysis

All of the financial & operational modeling you do:

• Long-rang scenarios/5-year plans/ Strategic Financial Planning
• Merger, Acquisition, and Divestiture scenarios
• What-if scenarios
• What-if commodity costs skyrocket?
• What-if competition discounts more heavily?
• What-if we halve/double our trade spend?
• Predictive analytics

AND - true EPM is when you interconnect all of these areas, both technically, and as a process.

It's easy to see why EPM is sometimes confused with Business Intelligence (BI).  The major components of BI (reporting & analysis) are inside the scope of EPM as outline above.  And some newer BI use-cases and tools are starting to include the planning & modeling scope.  Perhaps the terms are converging, and what really matters is that you interconnect these domains and leverage each as part of a holistic process.

-Ron Dimon

Luckily, there is a solution.  A key part of any project plan should be testing the hardware in any given environment for scalability.  Metrics testing tools are an ideal tool a client can use to accomplish that task. The most common tool in use for this is HP Load Runner.  At a high level, this tool allows a team to script test scenarios, and then apply virtual user and transaction volume to a test, to understand where the hardware will 'fall down'.

Of course, as with most things, it is not that simple.  In fact one of the common things Load Runner can determine is not just the viability of the architectural design, but also the viability of the application design.  If either side of the house is a weak link then something will fail.  The nice thing about baking Load Runner into the project plan is that you can head potential problems off at the pass.  If an environment needs more servers you can add them, if the application or reports design needs tweaking, they can be revisited.  All of these opportunities make Load Runner, or some metric testing, key in an environment. 

If you are thinking of using Load Runner or some other tool, here are some high-level 'lessons' to keep in mind to make best use of your time and effort:

• Engage a 'solution' consultant to help you.  It's one thing to script Load Runner, but to put together the proper use and work cases is actually harder as it requires a strong application and Load Runner knowledge to build a valid test.
• Define the users and think about not just the volume but where they might be located (i.e. geography) and how they will be secured.
• Define 'real' business cases for testing.  It is easy to break a server environment by overloading it.  That should not be the goal of your test.  Instead, plan on executing a test that is a mirror of the day-to-day user process, and then ramp that test up to the needed volume of users and transactions.
• Plan on twice as much time to gather the business information as you would normally expect.  It can take time for users to understand what you really need and this extra time allows for clarification and consistency.
• Think about making this a repeatable process that can be leveraged as applications change, as complexity is added, etc.

The ideas above are just the tip of the metrics iceberg.  As you can see, utilizing Load Runner can help define the right hardware and application design.  It can be a powerful tool for your environment, if used appropriately.  Please contact CheckPoint Consulting today for assistance with your testing needs.

 Author, Jeff Henkel

Oracle has documented a method by which to keep the WebLogic server from listening automatically on all NICs. Determine which NIC is the "primary" for the server, then look up the IP address or DNS name assigned to the server. For long-term ease-of-maintenance, it is recommended to use the fully-qualified server name that resolves to the IP of the "primary" NIC. If you have a distributed installation, find this information for each server in the environment which will have WebLogic applications deployed.

Start the WebLogic Administration server service, "Lock and Edit" the configuration, and modify the value of the "Listen Address" field for each application listed. For example, a single server deployment may have several WL app names like FoundationServices0, RAFramework0, etc. In a distributed installation, you may have RAFramework1 or FinancialReporting2 as possible names. Change the Listen Address to the fully-qualified name assigned to the primary NIC for the server in question. When done, save the configuration and exit. The next time you restart your WebLogic services, your netstat output will show you are now only listening on the "primary" NIC you specified earlier.

Author, Robert Spelman

And I’m happy to report I’m now with CheckPoint Consulting.  I’ve worked with many of the leaders and consultants at CheckPoint over the years – and couldn’t resist joining forces with them any longer!

Enterprise Performance Management helps you focus on the right things.  And it’s not just about ‘measuring what matters.’  It includes ‘planning what matters,’ ‘analyzing what matters,’ and ‘modeling what matters.’  So how do you determine what matters?  Here are a few qualities of your data to take a look at when deciding where to focus:

Materiality.  Does the data have a material impact on your business?  Examples include sales, gross margin, product quality, customer satisfaction, labor expense, and so on.  This should come before reporting & planning the small stuff.

Volatility.  Does the data change frequently and can it fluctuate wildly?  Some commodity prices are highly volatile, while most employee satisfaction survey results aren’t.  Where there’s more volatility, there needs to be more scrutiny.

Variance.  How does the data compare to what you planned the result to be, and what is your tolerance for that variation?  You may have a plus or minus 5% tolerance on overhead expenses, and a 15% tolerance on sales forecast (since sales forecasts are notoriously difficult to reign in, right?).  Management by exception means drawing your attention to the biggest variances beyond tolerance.

Reach.  Does the data need to be seen by many people in the organization?  Data that is seen by more people needs to be more frequent, of higher quality, and tends to impact more business decisions.

Impact.  Does that data affect other data in the business?  Our travel expense affects our SG&A (Selling, General & Administrative) expense and our Operating Margin.  It may also affect end-of-month discretionary spend and even variable compensation (we don’t get our bonus if we exceed expense budgets for example).  Don’t underestimate the impact of some of those key planning drivers.

Alignment.  Does that data you’re measuring align with your overall strategic and operational objectives?  Are you focused on those things that help close the gap between strategy & execution?

I’m looking forward to hearing from you and how you determine what to focus on.

- Ron Dimon 

 Upgrades in 11.1.2.1 are limited to specific versions, can’t be done “in place” and can only be done during installation / configuration.  Some of these limitations aren’t new to the upgrade process and some are.  Walking through each of them and the process itself will help explain limitations and some workarounds that are available.

 We’ll discuss the newest and most significant limitation first – that you can ONLY upgrade during installation and configuration.  This is significant.  In previous versions, there were often migration utilities and processes to bring items from an existing environment into the new environment after the new environment was running.  This allowed for the “controlled” migration of applications over a period of time.  Now the only time a migration from a previous version is allowed is during installation and configuration.

 There are a few workarounds available, but they are limited and will require a bit of work.  Planning applications have a supported “upgrade later” path that is complicated, but possible.  Essbase is Essbase – you can connect with EAS, copy application outline, then use a level 0 export / import to bring data in.  Both of these solutions work and are supported.  Officially, every other migration must be done at the initial installation; however there’s no reason the solution given for Planning applications could not be used for all other products.

 What is the “solution” to import Planning (and other products) from an existing environment into an existing 11.1.2.1 installation?  Build a new (temporary) 11.1.2.1 environment and perform the upgrade during installation and configuration of this new temporary environment.  Once done, you can use LCM to migrate to the existing 11.1.2.1 environment (LCM is only supported to migrate between environments that are the same version).  This may not sound like much of a “solution” – after all, building a new environment sounds more like “starting over” than a “solution”, but it does work and it does preserve both the running environments.

 The bad news is that you need to build a new environment. The good news is that this temporary environment can be small – just big enough to install / configure and run the products being upgraded.  This is not a simple, fast or easy process, so it is recommended to do as much at once as possible.  If more than one upgrade wave is required, try to combine and upgrade in as few “waves” as possible.

 While there are scripts and processes to move Essbase into the new environment, they are rather involved.  After looking at the process and what we were moving, we made the determination to recreate the Essbase cubes used for our Planning apps after the Planning migration. We then imported the data using a level 0 export from the existing environment.  This worked even with an export from a 4.x Essbase environment.  The process of copying the outline and using the data export/import process was simpler than the migration provided in the Oracle documentation.  Your mileage may vary in this area.

 Now to discuss the more familiar restrictions: The upgrade path is limited to three releases – 9.2.1, 9.3.3 and 11.1.1.3.  If you are not at one of these release levels, an intermediate installation and upgrade has to be done before upgrading to 11.1.2.1.  This isn’t as horrible as it may sound – all that is needed is a small, temporary environment (the kind of thing VMWare does wonderfully).  If you don’t plan to upgrade all your applications at once, keep a copy of this environment to use again in the future.

 In some previous version upgrades, there was an option to do an “in-place” upgrade.  While I would always discourage this path because of the risk to a working, existing environment, that path has been completely removed in 11.1.2.1.  While you can still do a “maintenance release” upgrade in place from 11.1.2.0 to 11.1.2.1, I would continue to discourage this approach.  In-place upgrades behave slightly different than “clean installations” and the risk of corruption during an upgrade is always there. The primary (road most travelled) path is the clean installation.  Following the “clean installation” path will keep you on this road and help make your upgrade successful.

 With this restriction, you can’t just use the current servers.  If your plans include using your current hardware, you will need to find a temporary environment for your existing servers (i.e. using Physical-to-Virtual conversion to move to VMWare, and then reformat the original servers, etc.).  However, because 11.1.2.1 is now supported on 2008, this is a perfect opportunity to upgrade hardware, OS and application all at once.

 An upgrade of Hyperion is traditionally a time to revisit applications – get rid of the old forms, unused reports, etc.  The result is that often applications are rebuilt in the new environment to clean them up and take advantage of the features of the new system.  With the upgrade restrictions of 11.1.2.1, the incentive to do this is even stronger.  An upgrade is supported and there is a path to the new version no matter what version you’re currently on, it just may be a long road.  There are restrictions and pitfalls.  And even after you have finished the Hyperion upgrade, you are likely to have a lot of work yet to do to fix the forms, reports, etc. that didn’t upgrade as expected.  Be prepared and plan for the “after the upgrade” work.

 Having travelled the upgrade road recently, I know that it’s a long road.  No two upgrades go exactly the same way – even if you are upgrading the same products from the same version.  You have to be ready for detours along the way, it’s always good to have a roadmap before starting.

 Author, Tony Moyers

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

--Author, Tony Moyers

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

Author: Mike Turner