1. SSL Offloading
2. 2-way SSL deployment
3. SSL termination at the web server

1. Additional information in migration status reports, including source and destination details.
2. Users must be provisioned with the Shared Services Administrator role to work with the Deployment Metadata tool.
3. The Calc Manager is supported, and has its own node under Foundation. As a result, business rules can now be migrated to classic HFM and Planning applications.

1. Manage Taskflows – This role allows users to create and edit a taskflow
2. Run Taskflows – This role permits users to view and run a taskflow, but they cannot create or edit taskflows

Improved Support for Essbase

1. Utilizing the Reorder Children dialog box, a new sort order can now be created to reorder members in the hierarchy.
2. Performance settings for dimensions can now be modified in EPMA
3. Dynamic Time Series (DTS) is now supported on the period dimension (BSO cubes)
4. The ability to add Typed Measures and members with a Date Format has also been included.
   1. Varying Attributes are still not supported in this release

1. Select the Financial Management app. It will then be copied as a Classic application. Once this has been done, the EPMA upgrade feature can be uses
2. Alternatively, the LCM tool can be used to migrate the application. Once this is done, the Copy Application Utility can be utilized to move the data.

1. Login through a proxy is now supported
2. Single Sign On (SSO) login is also supported

What’s New in Hyperion 11.1.2?

Essbase

Now that 11.1.2 has been rolled out and put to use, it’s time to do a little reflection on the new features that have been added in this release. This post will cover the significant changes made to Essbase.

ASO-Specific Changes

Several of the changes included in this release help Aggregate Storage Databases make up significant ground on Block Storage Databases in terms of functionality. First, ASO cubes now support allocations. Allocations can be performed based on a set value, proportionately, or spread evenly.

1.    Allocations can be written in MaxL using the EXECUTE ALLOCATION command

2.    Allocations can also be written with the Essbase API using EssPerformAllocationAso and providing the information in the ESS_PERF_ALLOC_T API structure

The second big addition for ASO databases is the ability to utilize custom calculations. There are two ways to write these calculations:

1.    Custom calculations can be written in MaxL using the EXECUTE CALCULATION command

2.    Custom calculations can also be written with the Essbase API using EssPerformCustomCalcASO and providing the information in the ESS_PERF_CUSTCALC_T structure

Two important notes regarding this new feature:

1.    These calculations are only available for level-0 members

2.    Calculations for ASO cubes can’t be executed from EAS in the same way that BSO calculations can

Another ASO related addition is the supported conversion of both non-Unicode and Unicode BSO’s to ASO’s.

Monitor Progress of Data Loads and Dimension Builds

When using asynchronous data loads and dimension builds, users can now query the system for the following information:

·         State and stage of the build/load process

·         Number of processed and rejected records

·         Name and location of the error file

Error and Exception Handling

You can now use the @RETURN function in calc scripts to exit the calculation with customized error messages based on conditions specified within the IF… ELSEIF calculation.

The MaxL shell IfError command can be used to detect syntactical, nested script, and permission errors. The command accepts a non-zero argument and allows you to exit the script or continue processing.

Alias Tables

Alias tables have been updated to allow 32 different tables to be used for a given cube as opposed to the old limit of 10. While it is uncommon to have more than 10 alias tables for a single cube, it is possible and therefore is a nice addition.

Multiple language codes are also supported for a single alias table. These codes are cleared when an alias table is cleared or copied (cleared in the copy), and preserved when a table is renamed.

Dynamic Write-back

While Essbase has allowed users to pull data from other cubes using the @XREF function, there hasn’t been a simple way to write to those cubes. Well this release includes a feature that was created to do just that. The @XWRITE function was added to allow users to write to blocks other than the ones being calculated. These blocks can be in the same database, or in a remote database.

Metadata Export to XML

Metadata can be extracted from an outline file or the active database outline into an XML. This allows users to compare outlines more easily, as well as track changes more effectively. The MaxL statement EXPORT OUTLINE has been added to support this export.

Follow the link below to view the complete document of changes

Essbase New Features

What's New in Hyperion 11.1.2?

Planning

• Bottom-Up Budgeting - Users input data at the lowest level. It follows the approval process up to the top budgeting group owner who then uses the approved data to create a final, consolidated budget
• Distributed Budgeting - The key difference between the two budgeting forms is that in distributed budgeting, ownership begins at the top and is pushed down to the bottom of the hierarchy. Data is then entered and follows the same approval process. 

This purpose of this article is to introduce the command line Life Cycle Management(LCM) utility in Oracle EPM. The LCM tool can be used to export and import objects that can be found within the Oracle EPM Environment.   This includes Security, Essbase, Hyperion Planning, Financial Management … etc.  As once gets more familiar with LCM, one comes to realize how powerful the tool is and how empty life without LCM was. Without LCM some of the more detailed artifacts within an application were difficult to move between environments.  LCM provides a centralized mechanism for exporting and importing nearly all of the objects within an Oracle EPM application or module. The table below is listed to get an idea of all the facets of LCM.

Application Artifacts by Module

The LCM tool is integrated into the Shared Services Web Interface.  If can be found under the Application Groups tab. Within the application groups there are three main areas of interest:

1. Foundation – includes Shared Services security such as Users/Groups and Provisioning.
2. File System - This is where the exported files will go by default. The default location is to be stored server side, on the Shared Services server in the location: E:\Hyperion\common\import_export
   Under this main folder, the contents are broken out by the user account that performed the export. Within the export folder, there is an “info” folder and a “resource” folder. The info folder provides an xml listing of the artifacts contained within the export. The resource folder contains the actual objects that were exported.
   
   The LCM Command line tool provides more flexibility because it can be installed on any machine and the results can be directed to output to any local folder. Sometimes this is very useful if the Shared Services node is a Unix machine, and the LCM users are unfamiliar with Unix. Simply install the LCM Command Line Utility on the Windows machine and redirect its output to a local Windows folder using the –local command line option. 
3. Products and Applications – Each registered product will be listed and provide a mechanism to export and import the respective objects for the associated applications, Essbase, Planning…etc.

Going Command Line

The Shared Services LCM GUI is a great way to become familiar with the LCM tool. However, when it is time to start automating LCM tasks and debugging issues, the Command Line LCM utility is very helpful. To get started, the LCM Command Line tool requires a single command line argument, an xml file that contains the migration definition. The quickest way to obtain the xml file is to use the Shared Services LCM Web interface to select the objects you wish, select Define Migration to pull up the LCM Migration Wizard, and follow the prompts until the last step. Two options are presented, “Execute Migration” or “Save Migration Definition”. Choose “Save Migration Definition” to save the migration definition to a local file.

That is pretty much all there is to it… move the xml migration definition file to the location you have installed LCM. For instance, \Hyperion\common\utilities\LCM\9.5.0.0\bin, open a command line and run Utility.bat as indicated:

E:\Hyperion\common\utilities\LCM\9.5.0.0\bin>Utility.bat SampleExport.xml
Attempting to load Log Config File:../conf/log.xml
2011-03-20 11:50:49,015 INFO  - Executing package file - E:\Hyperion\common\util
ities\LCM\9.5.0.0\bin\SampleExport.xml
>>> Enter username - admin
>>> Enter Password----------
--2011-03-20 11:50:57,968 INFO  - Audit Client has been created for the server h
ttp://hyp13:58080/interop/Audit
2011-03-20 11:50:58,421 WARN  - Going to buffer response body of large or unknow
n size. Using getResponseBodyAsStream instead is recommended.
2011-03-20 11:51:03,421 INFO  - Audit Client has been created for the server htt
p://hyp13:58080/interop/Audit
2011-03-20 11:51:03,437 INFO  - MIGRATING ARTIFACTS FROM "Foundation/Shared Serv
ices" TO "/SampleExport"
2011-03-20 11:51:32,281 INFO  - Message after RemoteMigration execution - Succes
s. HSS log file is in - E:\Hyperion\common\utilities\LCM\9.5.0.0\logs\LCM_2011_0
3_20_11_50_48_0.log
2011-03-20 11:51:32,687 INFO  - Migration Status - Success

E:\Hyperion\common\utilities\LCM\9.5.0.0\bin>

LCM Example: Synchronizing Shared Services Security between Environments

LCM often requires moving objects and security between environments, such as from a development environment to a production environment. While LCM makes it easy, it is not as straightforward as simply running an export from one environment and importing into another environment. The reason is that LCM imports work in a “create/update” mode. In other words, the operations performed in LCM are typically additive in nature. While the typical LCM method would capture new users and new application provisioning, it will not handle removing user provisioning, removing or changing groups, or essentially removing users from the system. This can be an easy oversight, but it will ensure that the security becomes out of sync over time and can cause issues as well as security implications. At a high level, the steps to sync provisioning using LCM would be:

1. Export Users/Groups/Provisioning from Source Environment
2. Export Users/Groups from Target Environment
3. Delete Using Step 2 Results the Users/Groups in Target Environment
4. Import Users/Groups/Provisioning into Target Environment

Essentially, Step 1 and 4 are the typical import/export operations – where security is exported from one environment and imported into another environment. However, two additional steps are necessary. In Step 3, the users and groups in the target environment are deleted, removing provisioning too. This leaves an empty, clean environment to then import security, ensuring no residual artifacts remain in the environment. To use the LCM delete operation, a list of items to be deleted must be supplied. This is where Step 2 comes in, a simple export of the Users and Groups in the Target environment will provide the necessary information to provide to Step 3 – deleting the respective users and groups.

Below are some sample XML migration definitions for each step:

Step 1 – Export Users/Groups/Provisioning from Source Environment

Note: By default the results will be sent to the source Shared Services server in the “import_export” directory. You can use LCM to redirect the output to keep the results all in the same environment (the target system) by using the command line option [-local/-l] (run utility.bat without any command line options to see help for your version of LCM). Simply redirect the results into the local folder, \Hyperion\common\import_export, in the Target system.

<?xml version=”1.0” encoding="UTF-8"?>
<Package name="web-migration" description="Migrating Shared Services to File System ">
    <LOCALE>en_US</LOCALE>
    <Connections>
        <ConnectionInfo name="MyHSS-Connection1" type="HSS" description="Hyperion Shared Service connection" url="http://sourceSvr:58080/interop" user="" password=""/>
        <ConnectionInfo name="FileSystem-Connection1" type="FileSystem" description="File system connection" HSSConnection="MyHSS-Connection1" filePath="/Step1ExportFromSource"/>
        <ConnectionInfo name="AppConnection2" type="Application" product="HUB" project="Foundation" application="Shared Services" HSSConnection="MyHSS-Connection1" description="Source Application"/>
    </Connections>
    <Tasks>
        <Task seqID="1">
            <Source connection="AppConnection2">
                <Options>
                    <optionInfo name="userFilter" value="*"/>
                    <optionInfo name="groupFilter" value="*"/>
                    <optionInfo name="roleFilter" value="*"/>
                </Options>
                <Artifact recursive="false" parentPath="/Native Directory" pattern="Users"/>
                <Artifact recursive="true" parentPath="/Native Directory/Assigned Roles" pattern="*"/>
                <Artifact recursive="false" parentPath="/Native Directory" pattern="Groups"/>
            </Source>
            <Target connection="FileSystem-Connection1">
                <Options/>
            </Target>
        </Task>
    </Tasks>
</Package>

Step 2 - Export Users / Groups from Target Environment

<?xml version="1.0" encoding="UTF-8"?>
<Package name="web-migration" description="Migrating Shared Services to File System ">
    <LOCALE>en_US</LOCALE>
    <Connections>
        <ConnectionInfo name="MyHSS-Connection1" type="HSS" description="Hyperion Shared Service connection" url="http://targetSvr:58080/interop" user="" password=""/>
        <ConnectionInfo name="FileSystem-Connection1" type="FileSystem" description="File system connection" HSSConnection="MyHSS-Connection1" filePath="/Step2UsersGroupsTarget"/>
        <ConnectionInfo name="AppConnection2" type="Application" product="HUB" project="Foundation" application="Shared Services" HSSConnection="MyHSS-Connection1" description="Source Application"/>
    </Connections>
    <Tasks>
        <Task seqID="1">
            <Source connection="AppConnection2">
                <Options>
                    <optionInfo name="userFilter" value="*"/>
                    <optionInfo name="groupFilter" value="*"/>
                </Options>
                <Artifact recursive="false" parentPath="/Native Directory" pattern="Users"/>
                <Artifact recursive="false" parentPath="/Native Directory" pattern="Groups"/>
            </Source>
            <Target connection="FileSystem-Connection1">
                <Options/>
            </Target>
        </Task>
    </Tasks>
</Package>

Step 3 – Delete Users/Groups in Target Environment

<?xml version="1.0" encoding="UTF-8"?>
<Package name="web-migration" description="Migrating File System to Shared Services">
    <LOCALE>en_US</LOCALE>
    <Connections>
        <ConnectionInfo name="MyHSS-Connection1" type="HSS" description="Hyperion Shared Service connection" url="http://targetSvr:58080/interop" user="" password=""/>
        <ConnectionInfo name="AppConnection1" type="Application" product="HUB" description="Destination Application" HSSConnection="MyHSS-Connection1" project="Foundation" application="Shared Services"/>
        <ConnectionInfo name="FileSystem-Connection2" type="FileSystem" HSSConnection="MyHSS-Connection1" filePath="/Step2UsersGroupsTarget" description="Source Application"/>
    </Connections>
    <Tasks>
        <Task seqID="1">
            <Source connection="FileSystem-Connection2">
                <Options/>
                <Artifact recursive="false" parentPath="/Native Directory" pattern="Users"/>
                <Artifact recursive="false" parentPath="/Native Directory" pattern="Groups"/>
            </Source>
            <Target connection="AppConnection1">
                <Options>
                    <optionInfo name="operation" value="delete"/>
                    <optionInfo name="maxerrors" value="100"/>
                </Options>
            </Target>
        </Task>
    </Tasks>
</Package>

Step 4 – Import Users and Groups into Clean Target Environment

This step assumes that Step 1 was redirected onto the target environment within the import_export directory. The respective folder, Step1UsersGroupsSource, can also be manually copied from the source to the target environment without using the redirection to a local folder technique.

<?xml version="1.0" encoding="UTF-8"?>
<Package name="web-migration" description="Migrating File System to Shared Services">
    <LOCALE>en_US</LOCALE>
    <Connections>
        <ConnectionInfo name="MyHSS-Connection1" type="HSS" description="Hyperion Shared Service connection" url="http://targetSvr:58080/interop" user="" password=""/>
        <ConnectionInfo name="AppConnection1" type="Application" product="HUB" description="Destination Application" HSSConnection="MyHSS-Connection1" project="Foundation" application="Shared Services"/>
        <ConnectionInfo name="FileSystem-Connection2" type="FileSystem" HSSConnection="MyHSS-Connection1" filePath="/Step1UsersGroupsSource" description="Source Application"/>
    </Connections>
    <Tasks>
        <Task seqID="1">
            <Source connection="FileSystem-Connection2">
                <Options/>
                <Artifact recursive="true" parentPath="/Native Directory" pattern="*"/>
            </Source>
            <Target connection="AppConnection1">
                <Options>
                    <optionInfo name="operation" value="create/update"/>
                    <optionInfo name="maxerrors" value="100"/>
                </Options>
            </Target>
        </Task>
    </Tasks>
</Package>

Troubleshooting with Command Line LCM

LCM can be a great tool when it works flawlessly. However, it can quickly become part of mission critical activities like promoting artifacts from development to production. Consequently, it is necessary to learn some troubleshooting skills to maintain business continuity using LCM.

1. Review the output of the LCM operation. Usually it will provide some detail about the error that was received.
2. Review the server side Shared_services_LCM.log in ORACLE_HOME\logs\SharedServices\SharedServices_LCM.log
3. Turn on debugging for the command line LCM tool. Change the line “info” to “debug” in the files
   E:\Hyperion\common\utilities\LCM\9.5.0.0\conf in log.xml and hss-log.xml
     <param name="Threshold" value="info" /> 
4. Use Google, the Oracle Knowledgebase to search for more information.
5. Try only a subset of the initial objects. For instance, Essbase can export a number of objects, Outline, Calc Scripts, Rule Files, Report Scripts, Substation Variables, Location Aliases, and Security. Try one at a time to determine which part of the whole is failing.
6. Restart the environment. LCM is an emerging technology and can sometimes just be in a bad state. I’ve seen countless LCM issues where bouncing the environment clears the issue up.
7. Look for special characters that might be present in your data. LCM is a java tool and uses xml and text files to transmit data. There are instances where special characters can mess up the parsing.
8. Look for patches – as mentioned previously, LCM is an emerging technology and is still somewhat buggy (especially older versions). Check release notes in patches for enhancements/bug fixes in LCM.

"Installation and Configuration"

In installment #1 and #2 of this guide, we reviewed the architecture considerations and pre-installation requirements.  If you haven’t read the two previous post or haven’t read the Hyperion “Installation Start Here” guide, you’ll want to be sure to do that. 

With this installment I’ll review the Installation and Configuration activities necessary for a Hyperion 11.x environment.  The installation and configuration are separate items.  The installation can takes place first and it only lays out the files to run the system.  The configuration ties everything together, creates repositories, deploys applications, and creates services.  This will cover both including the following items:

• Hyperion Fusion Installer and How it Works
• Preparing the Fusion Installer
• Using the Fusion Installer
• Hyperion Configuration Utility

The companion Hyperion Documentation for this post is either of the following documents found in the Oracle Documentation Library:
Oracle Hyperion Enterprise Performance Management System Installation and Configuration Guide Release 11.1.1.x
Oracle Hyperion Enterprise Performance Management System Manual Deployment Guide Release 11.1.1.x

You probably are not going to read them in their entirety since they are rather lengthy but they are very useful in fully understanding what is going on and priceless for complex environment or when things don’t go well. 

Hyperion Fusion Installer and How it works.

So let’s get started on this installation already.  One of the great features of Release 11.x Fusion Edition is the Fusion Installer.  It is a nice application for guiding you through the installation.  The first thing to do is download the Fusion Installer and copy it to each server in your architecture.  The Fusion Installer is only the shell for the rest of the installation.  Under the Fusion Installer create a folder called “assemblies”.

Preparing the Fusion Installer

You’ll next need to download the remaining Foundation Services as well as any other applications you are using.  For our example we are going to assume the client is using Foundation, Planning, and HFM.  You are probably looking at something in the neighborhood of 4GB to download.  Each download, when unzipped contains a group of folders looking something like this:

Each server will need the appropriate assemblies copied to its own \<FusionInstaller>\assmblies directory.  This way, whenthe Fusion Installer starts, it knows what is available to install.  Some of the common components are needed on each server.  If you are missing something, the Fusion Installer will let you know in the status window at the bottom application.  For details on which assemblies are required for each application, refer to the Installation and Configuration Guide.

Using the Fusion Installer

As you start the Fusion Installer you will see something like this:

I like to choose “Choose Components Individually” since it feels like I have a little more granularity.  At this point I’ll select all of the components I want to install on each server.  Once again, this is run on every server in the architecture.  The Fusion Installer only lays out the application files; it doesn’t need any information so the sequence of installation can occur in any order.  It seems to work pretty well when all the components on a server are chosen together. 

The last thing to do is to review all the install logs for any errors.  It is much easier to catch them now than after the configuration is started before anything is written specific is written to registries and relational databases.  Once the configuration starts, you are committed. 

Configuration

The first thing to do is to configure Shared Services.  After the installation is complete, each server will have a Configuration Application.  It can be launched on a Windows Server from Start >Oracle EPM Applications > Foundation Services > EPM System Configurator.  This application will guide you through the configuration with such things as creating and distributing Java applications, creating relational repositories, and building the Windows Services.  The EPM System Configurator displays the installed components and then you can select which components to configure.  It looks something like this

The first thing to do is configure Shared Services.  This needs to be done by itself and before any other components are configured.  As soon as this is complete, launch Shared Services and verify that it is working appropriately.  If it isn’t, it’s will be a long day.  If you are able to log in to Shared Services, it is also probably best to go ahead and configure any external authentication provider at this time.

When Shared Services is complete and verified, you can move from server to server configuring all the components.  The documentation says that you can configure all the components at once but this will attempt to configure all the selected products in the same relation schema/table.  The documentation also says that some of the repositories need to be separate.  I prefer to do it one at a time to be certain I can keep all the relational repositories separate and I can validate each component as it is competed.  I usually start with all the Foundation Services and then make sure Workspace functions before moving on to the EPM application like Planning and Financial Management.  The last thing to do is to redeploy Workspace so it is configured to proxy all the remaining Web Applications. 

You will want to be careful with each screen to make certain every component is configured as you planned.  It is easy to keep hitting ‘NEXT’ only to find out you mixed your Calculation Manager Repository in with your Shared Services repository. 

As with the installation, I like to review all the configuration logs on each server very carefully.  Better to catch an error now than later.  When I’m comfortable with the configuration, I shut everything down and bring it back up.  The start order is quite finicky.  The Oracle Installation and Configuration Guide has specifics regarding the start order but I usually do something like this:
1.    Shared Services OpenLDAP
2.    Shared Services Application Server
3.    Hyperion Annotation Service
4.    EPM Workspace Agent (CMC Agent)
5.    EPM Workspace UI (CMC UI)
6.    EPM Workspace Web Server   
7.    EPM Workspace Application Server   
8.    Hyperion RMI Registry
9.    Performance Management Architect Services

       Process Manager automatically starts the following services:

•   Hyperion EPM Architect - Engine Manager
• Hyperion EPM Architect - Event Manager
• Hyperion EPM Architect - Job Manager
• Hyperion EPM Architect - .NET JNI Bridge

10.    Performance Management Architect Web Services
11.    Essbase Server
12.    Administration Services Application Server
13.    Smart Search Application Server
14.    Essbase Studio Server   
15.    Provider Services Application Server   
16.    Hyperion Financial Reporting - Java RMI Registry
17.    Hyperion Financial Reporting - Print Server
18.    Hyperion Financial Reporting - Report Server
19.    Hyperion Financial Reporting - Scheduler Server
20.    Web Analysis Application Server
21.    Performance Management Architect Application Server
22.    Performance Management Architect Data Synchronizer Application Server
23.    Financial Reporting - Web Application
24.    Calculation Manager
25.    Planning Application Server
26.    Financial Management
27.    Hyperion Financial Management DME Listener
28.    Hyperion Financial Management Web Service Manager
29.    Hyperion Financial Data Quality Management - Task Manager

Assuming everything starts, we’ll discuss validation in the next part.