1. Dynamic References using CurrentMember, CurrentTupule etc are not supported currently (necessary if we want to run multiple allocations within the same dimension)
2. Hierarchical references like PARENT etc are not allowed in both calculations & allocations. These references are allowed for the parameters but not for the assignment scripts/allocation amounts.

The above 2 are significant drawbacks which i hope will be supported in future releases. Lets now look at a very simple example for allocation. I will be using the ASO version of the Demo->Basic cube for demonstrating this. The screenshot below shows the data that has been loaded into the cube.

If you notice, we have data for the Sales measure for all Regions except South. The idea is to allocate data into the South Region (both Sales & Cogs equally) based on the Total Expense values of the East Region. This is a very simple allocation example where our input data is at Level-0 but we are allocating from non Level-0. One good thing about this example is the fact that this shows that though ASO does not support input to non level-0 members, it supports allocation from them.

An Allocation in a ASO cube does not require a separate calculation script. All allocations are done through MaxLs directly. An allocation MaxL contains four main parts (in addition to other parameters which i shall not cover here).

1. POV – POV or a Point of View provides execution context to an allocation. A POV allows only reference to level-0 members. For every combination in the POV, the allocation will be executed once. POV is specified in the form of a MDX-Set.

2. Amount – This can contain a static member, Tupule or a constant. This does not support MDX expressions. In our example above, the amount will the (Total Expenses,East) Tupule. Ideally, Amount & POV should have all the dimensions in the cube.

3. Target – Target is specified in the form of a MDX Tupule. Basically it represents the region that will act as a target for the allocation. In our case, this will be empty.

4. Region – Region is a MDX set expression. This represents the target region where the data will be allocated. The dimensions specified in POV, Target and Region should be mutually exclusive as they all combine to form the target region. In the example above, Children(Total Expenses) & the Children (South) will form the Region.

5. Basis – This is commonly used when we are doing member based allocations. In our case, since we are using dividing the values equally (Spread allocation), this is optional.

So the final formula that i shall be using for achieving this is given below

execute allocation process on database DemoASO.Basic with
pov "Crossjoin(Descendants([Year],[Year].levels(0)),
Crossjoin(Descendants([Product],[Product].levels(0)),
Descendants([Scenario],[Scenario].levels(0))))"
amount    "([East],[Total_Expenses])"
target    ""
range        "CrossJoin({[Sales],[Cost_of_Goods_Sold]},
Descendants([South],[Market].levels(0)))"
spread;

As you see, Essbase has generated the necessary cells to accomplish this. As i mentioned last time in the Calculation blog post, the allocations/calculations are done separately and then the updated cells are pushed through external data load buffers. So, you would start noticing cells being loaded into incremental slices.

And if you look at the data, the South region would now have data with the values uniformly distributed.

Though this does work there are some inherent drawbacks. As ASO does not accept data at non level-0 members, the way allocation maxL’s are designed it makes it very tough(though possible) to do hierarchical allocations within the same dimension. Hopefully the introduction of dynamic member references and member functions should enable that in the future.

In this release, as i mentioned yesterday, the calculation scripts will have to be written in a separate text editor or the BSO calc script editor. There is no syntax validation available. So, ensure that you get the syntax correct atleast for the POV part.

Lets look at the various aspects that are involved in the creation of an ASO Calculation through MaxL.

1. Calc Script – This basically is a file (like the BSO .csc file) that will contain the actual calculation. The calculation currently does not support MDX member commands like Descendants etc. Only constant Tuples are supported. An example script is given below

([Bud Var],[Jan]) := 100;

In the above example, the calculation script basically assigns a value of 100 to all the cells with the matching Tupule.

2. POV – This basically is used during the execution of a calculation script. This determines the context of the calculation. For example, we can determine the combination of other dimensions not specified in the Tupule above. It is expressed as an MDX Set (not a Tupule). There is a very important difference between an ASO and a BSO calculation. If the POV includes the same dimension as the Tupule members in the calc script, then all the same dimensionality members in the POV will add themselves(can be controlled through Debit & credit members) and overwrite into the Calc Script Tupule Member combination. I will cover it in the examples below.

3. SourceRegion – A calc script can potentially have more than one calculation. For example, if you look at the calculation script below

([Bud Var],[Jan]) := ([Budget],[Jan]) - ([Actual],[Jan]);
([Bud Var],[East]) := ([Actual],[East]) - ([Budget],[East]);

This contains 2 separate calculations. Each tupule contains a different set of the dimensions. A source region basically is a MDX set which superset of all the tupules specified in the calculation script. This is needed as each line in the script is executed in parallel.

There are 3 other optional parameters like CreditMember, DebitMember & Offset. For today’s blog post, i will just cover the above 3.

Lets first start with creating a simple calculation script shown below

Basically all this script does is, it tries to assign a value of 100 to the ([Bud Var],[Jan]) tupule. After creating the calc script, save the script in the {ESSBASE_HOME}/app/DemoASO/BasicASO folder where DemoASO->BasicASO is my application & database respectively. Before running this script lets look at the statistics of the ASO cube.

As you see, this cube basically has no incremental slices. All the data is in the main slice. In the case of Block Storage cubes, when we assign a constant value to a member then the constant value gets assigned to all the existing blocks or will create new blocks depending on the CREATEBLOCKONEQ setting in the calculation script. But in the case of Aggregate Storage cubes, we do not have blocks. So it will be interesting to see what happens when we run the above calculation. To find out, lets run this script using the MaxL shown below

execute calculation on database DemoASO.BasicASO with
local script_file "/u01/app/Middleware/user_projects/epmsystem1/EssbaseServer/essbaseserver1/app/DemoASO/BasicASO/BudVar.csc"
POV "Crossjoin({[Jan]},Crossjoin({[New_York]},Crossjoin({[Stereo]},Crossjoin({[Sales]},Descendants(Scenario,Scenario.Levels(0))))))"
SourceRegion "Crossjoin({[Bud Var]},{[Jan]})";

As you see, all we are doing is we are running the calculation script against a POV context containing 4 cells.

The outline of the DemoASO cube is shown below for reference.

If you notice, in the POV we have 4 members from the same dimension (Scenario). And in the calc script we are assigning a value of 100 to a member in the Scenario dimension. Also, if you look at the data(before calculation) in the cube, we have cells populated for 3 of the Scenario members and not for the 4th one (Bud Var)

Now lets look at the data after running the calculation.

Though we assigned a value of only 100 to the Bud Var member, we now have a value of 400. The reason why this is happening is in our POV we have 4 scenario members included. Since we are assigning to value to only one scenario member, all the values of the 4 members get added and will be stored in the Bud Var intersection. Lets take a look at cube statistics again after running this calculation.

This is interesting. What we have now is 1 incremental cell in the incremental slice and the remaining 3 generated cells are in the main slice. So what has happened is, Essbase looks at the POV context and determines the number of cells to be generated. Out of these cells, it looks at the source of these 4 cells. Out of these 4, 3 already exist in the main slice. But 1 cell does not exist at all. So, it generates the new cell in the incremental slice. To validate this theory, lets change the MaxL as shown below and execute it

execute calculation on database DemoASO.BasicASO with
local script_file "/u01/app/Middleware/user_projects/epmsystem1/EssbaseServer/essbaseserver1/app/DemoASO/BasicASO/BudVar.csc"
POV "Crossjoin({[Jan]},Crossjoin({[New_York],[Boston]},Crossjoin({[Stereo]},Crossjoin({[Sales]},Descendants(Scenario,Scenario.Levels(0))))))"
SourceRegion "Crossjoin({[Bud Var]},{[Jan]})";

What we have basically done is, we have added one more member called Boston to the MaxL. Again, if we look at the Cube stats, we will see that there are 2 incremental cells and each cell will be in its own slice.

These 2 incremental cells are for New_York->Bud Var and Boston->Bud Var members which do not exist in the cube at all. The data in the cube will now have spread the value of 400 across both New York and Boston as shown below

In the case of BSO calculations, the calculations are generally driven through the existing blocks & the FIX’ed members (though we can alter this in different ways). In the case of ASO cube though, the control happens through the POV (and also Offset which i have not covered here) & the calc script. ASO generates new cells depending on whether that cell exists or not in the main slice. Of course, i have not tested this when all the input data in an incremental slice, but i would assume the behavior will more or less be the same. So far, i will have to say the performance is really good. I will be putting this through further test with a larger data set. It would be interesting to see if this can replace level-0 currency conversions that are quite common in implementations. So far, the only way to do that in ASO was either by using BSO as a partition source or by using Dynamic MDX hierarchies. I have covered both of them here and here. My first impression is, this can quite easily be used for currency conversions as well. I will hopefully cover my findings in a future blog post on this.

1. Using Calculation Manager to design the calcs and executing from there
2. Using MaxL and executing the scripts through MaxL

The second option above is actually more flexible since it allows to write custom MDX Tuples, sets easily within the calc scripts. I somehow felt that the calc manager has undergone a significant UI change primarily due to the introduction of ADF based UI. Though it does work, there still are some UI bugs which crept up here and there especially while trying to enter the calculations manually. One significant difference between calculation manager and MaxL is the fact that Calculation Manager follows more of a BSO based member set entries. It does not support MDX, atleast as far as i have tested. MDX is supported only within the calc scripts that run through EAS.

Lets look at a very simple example using both the above options. I shall be using an ASO version of the Demo->Basic cube to demonstrate this

Essbase ASO calculation execution now follows more of a HBR/Calc Manager syntax. That is, we start with defining a calculation script and then during execution time, we can specify the Point Of View of Execution, Member Offset, Credit/Debit members etc. A single calculation script can be executed in different point of views thereby providing different results. ASO calc scripts cannot be executed in isolation directly within EAS. They will have to be executed from within the maxL script editor. Also, the calculation script editor in EAS, does not support MDX. So for now, we will have to ensure that the scripts are absolutely correct as there is no way we can check the syntax validity from within the UI. I believe there is a bug in the EAS console, wherein if you get the MDX set scripts wrong, it will bring down the EAS server (atleast on my 64 bit console).

Lets start with logging into the calculation manager. Though IE 8 is supported, the latest version of Firefox is not supported for any of the ADF based EPM UI(similar to EPM 11.1.1.3). I had to downgrade my Mac firefox to a lower version to get this working.

I will start with creating a very simple rule called Budget Variance.

You will see that now the calc manager has ASO specific icons like Allocation, Calculation, Point Of View etc for executing ASO calculations. As with any calc manager calculation, we can specify a global range and then execute calculations.

With the introduction of ADF components, we can now drag and drop the individual components into the main palette. I will start with defining the Point of View first. I want the calculation to execute for the entire level-0 member combinations of the cube.

After defining the Point of View, lets drag and drop the calculation(Formula) on to the main palette. The calculation will be defined after the Point of View(or before depending on how we want the POV to be applied).

In the formula, lets define a simple calculation where we would like the Bud Var member to be having a value of 100.

We can have more than one formula defined in a calculation. But the difference between a ASO and a BSO calc script is the fact that the formulas are executed in parallel in ASO. We can serialize them by defining a proper flow within the calc manager. Lets now deploy this rule and execute it.

After execution, the cells within the ASO cube will be updated as shown below.

So, this does work & seems to work even for some complex cases within the calc manager. Lets put this to test further by using EAS & MaxL in the next blog entry. I have not tested what happens to the load buffers, data slices etc when we run these calcs. I will hopefully cover those as well as part of the EAS/MaxL based ASO calculation execution blog entry.

1. EPM System Installer
2. EPM Foundation Services (All the 4 parts are needed. 3 Parts are OS specific and the last part is OS generic)
3. EPM Essbase Server (both the parts are needed. The first part is OS generic and 2nd part is OS specific)
4. EPM Essbase Client (OS generic)
5. EPM Static Content (OS generic)

When you unzip the contents there are 2 things that you need to be aware of

1. The file size requirements have significantly increased in this release. So, if you are installing this on a VM, then make sure that you atleast have 30 to 40 GB of free space.
2. In EPM 11.1.1.3, we can just fire the unzip commands (in linux) and overwrite the files. But in the case of 11.1.2, one has to be extremely careful while doing the unzip. Since there are some binaries that are OS generic and some binaries that are OS specific, ensure that you unzip the Essbase Server, Essbase Client and Essbase Static Content files in separate directories. And then copy the assembly files to the main assemblies directory. Any mistake here, the installer will not recognize Essbase.

The folder structure within your assemblies install folder should have the following folders

There are some significant changes to the entire EPM framework. So direct upgrades are not possible. The main changes are

1. Shared Services does not use OpenLDAP anymore. Instead it uses a local database that is part of the Weblogic framework.
2. Apache Web Server has been replaced by Oracle HTTP Server and the Tomcat application server has been replaced by Weblogic server.
3. The base memory footprint required (RAM) has increased significantly due to the introduction of HTTP Server and Weblogic server.
4. There are some ADF based components that are used widely within the workspace. You can actually see how the entire Oracle product is converging using the common ADF framework.
5. The directory structure of the entire EPM 11.1.2 is completely different from the previous EPM 11.1.1.3 release. Essbase base folders have been pushed into the weblogic Middleware home directory.
6. Essbase clustering can be done directly during the installation process itself. There are significant changes in the Essbase ASO functionality as well.
7. Not a significant one, but the admin passwords can be changed as part of the install itself.
8. Data Direct drivers are not used anymore. EPM 11.1.2 now supports OCI by default.

The screenshot below shows the weblogic domain that gets created during the installation. This is the base of the entire EPM release now (Default install, other application servers are still supported)

As part of Essbase integration with Oracle SSO and Oracle Enterprise Manager, Oracle HTTP server is mandatory and should be installed prior to Essbase installation.

As i said above, Essbase by default is installed within the Middleware folder structure. This can be customized. Also, you can see the cluster setup can be done as part of the install process (i will cover this in a later blog entry)

And finally, workspace will be deployed & rendered through the Oracle HTTP server. All the other applications like APS, Planning, EPMA will be accessibly within the workspace through the Oracle HTTP server instead of apache.

You can notice that the entire shared services & workspace UI now have more of a ADF feel to it.

From an Essbase Administration services standpoint, the Java Web Start based console has undergone a small UI change. And of course, the features that have been added in EAS directly correspond to the features added in Essbase. I will cover them in the coming blog entries.

From my standpoint, the amount of changes in this release are so significant that this does not seem to be a .X release. I am just wondering how the EPM team managed to bring in so many changes within a short period of time (after the EPM 11.1.1.3 release) considering the fact that we have been waiting for BI EE 11g for almost a couple of years now. I am guessing this has been in the works for quite a while and i will have to say that the EPM team has done an extraordinary job in bringing this together. Atleast these are my first impressions. I will blog about some of the new features over the course of next week.

Some of the significant new features in this release are

1. Oracle Financial Close Manager
2. Oracle Essbase Analytics Link in HFM (was available in 11.1.1.3 itself but enhanced now)
3. Oracle Hierarchy/Dimension Management from within Oracle Applications
4. New Planning Modules – For Public Sector
5. Smart-View Enhanced – Lot more powerful now like closer Planning forms integration etc
6. Tasks integration with Outlook
7. Hyperion DRM – Completely Web based now
8. Clustering of Essbase
9. SSO with Oracle SSO in Essbase
10. Mgmt packs for Essbase
11. Footnotes & XBRL tagging in HFR
12. Enhancements to Hyperion Planning – Web Based Form Conditional Formatting etc

Not all the features are covered in the list above. But i will start covering them hopefully in the coming weeks.

The major advantage of using XOLAP and HFR (when compared with BI EE 10g) is this provides 3 main distinct advantages

1. HFR provides contextual drills as opposed to normal drills that BI EE 10g provides.
2. HFR provides and supports hierarchical prompts which BI EE does
3. HFR provides extensive formatting capabilities (like conditional formatting on Pivot tables etc) which BI EE itself natively lacks

Of course, BI EE 11g would provide all of these capabilities. But until then, for customers who absolutely need the 3 points mentioned above, HFR can be used to supplement BI EE as it is part of the BI EE Plus bundle.

To get this to work, lets start with a simple XOLAP cube. If you are not sure about what XOLAP offers and its advantages, refer my previous blog entry on this here. For this i shall be using the GLOBAL schema that can be downloaded here.

XOLAP basically is based on a ASO cube format. All the design considerations in terms of outline structure etc would have to be adhered to even in XOLAP. So we start with importing the required database tables from within Essbase studio

After importing the required tables, we establish the relationship across the tables using the normal SQL Joins

After establishing the relationships, we need to define the Hierarchies and Measure Hierarchies in Essbase Studio. In the XOLAP cube that i will be building, we will have 3 normal dimensions Time, Product and Channel. There will be one Accounts dimension which will have all the relational measures.

After defining the hierarchies, we need to create a Cube Schema and Essbase Model so that we can designate the target cube to be deployed as a XOLAP cube.

Deploying this to Essbase should create a new application and database. The only difference is, this cube will always return data from relational sources at run-time. There will not be any pre-aggregated data stored in this cube.

So, we basically have an outline that is directly dependent on relational source. Any MDX query fired to this cube will be converted to the corresponding SQLs by Essbase. So, all the complex multi-dimensional reporting MDX that we use on normal ASO/BSO cubes can be used on this as well. Of course, not every MDX function is supported (As there is no corresponding equivalents ones in the relational source).

Now that the XOLAP cube is built, lets see how we can use this from Hyperion Financial Reporting. To begin with i start with defining this XOLAP cube as the source for HFR.

Then i create a very simple grid in HFR with the following layout.

The idea is, i will enable the drills on the Product and Time dimensions. Both Channel and Measure dimensions will act as USER POVs. The POVs will act as hierarchical prompts just for this example.

If you notice, we can now leverage XBRL directly here. After defining this report, if you look at the report from EPM Workspace, you will notice that the HFR provides more capabilities (at-least in some aspects) than BI EE 10g.

In the report, you can see that the drills are context sensitive. Also, if we click on a User POV, we will see that the prompts show the hierarchy as well

For multi-selects we can use USER PROMPTs of HFR. Even they are hierarchy aware. Now that we have demonstrated the basic advantage of using HFR on XOLAP, lets try some complex reporting functionality on this. For example, lets add a calculation which will basically show the value of  “Hardware” – “Deluxe Mouse”. Hardware is one level above the Deluxe Mouse member. But this kind of calculations are quite common when dealing with Essbase sources

As you see, custom financial reporting functions work quite well. This is actually quite exciting (Atleast for me) to see a web based reporting solution(which is in the strategic direction of Oracle) from Oracle that can do multi-dimensional aware reporting on relational sources. All the complex formatting that we are so used in HFR will all work here as well.

From my perspective, part of the reason why XOLAP was introduced is to make HFR work with relational sources. Now, we can make Horizontal & Vertical Fragmentation & Federation work easily with XOLAP by using Essbase transparent partitions on XOLAP. Atleast until 11g comes out this can quite easily serve the reporting needs of multi-dimension aware reporting on relational sources. And of course, we can use HFR as a sort of comparison to see how 11g behaves when compared with features of HFR.

Next in line is in comparing how XOLAP converts MDX to SQL. I will cover that as a separate blog entry. The first part of the XOLAP MDX to SQL conversion is available here. The 2nd part will cover what SQL queries get fired for multi-level MDX reporting.

To demonstrate how the integration works, i will be using a simple report built in Web Analysis and expose that in Weblogic Portal. The procedure remains the same for HFR & IR as well. I chose Web Analysis for a couple of reasons

1. Its one of the most under-rated tools in the Hyperion Stack. Its one of the best tools in Oracle that provides excellent multi-dimensional analysis even on relational data. There are so many features that makes BI EE 10g look like a very simple analysis tool in comparison, atleast from a multi-dimensional analysis standpoint. Its major downside though is it does not scale very well & lacks a slick UI like BI EE.

2. HFR & IR both require windows clients. In my case, both my VM’s (one running EPM Workspace and the other running Weblogic portal) were on Oracle Enterprise Linux.

From a portal standpoint, i believe Weblogic Portal 10.3 is now superseded by the Webcenter Suite portal framework. I had to choose Weblogic to reduce the memory footprint on my VM’s. Somehow the SOA Suite 11g portal along with JDeveloper on OEL seemed to bring my VM’s to a grinding halt. The procedure for portlet integration with Webcenter Suite is a bit different from Weblogic Portal which i do hope to cover in future(after sorting out the memory issue). One point to note is, while installing Weblogic Portal ensure that you are installing the Portal Samples as well. These samples contain a sample DVT application which provides a login portlet for the portal.

Having used Weblogic Portal, i can surely say that it is much better than the Oracle Portal 10g. Portlet development/deployment is a lot easier in Weblogic as it is purely java based. I still remember i had to get 2/3 patches applied on Oracle Portal 10.2.0.x to 10.2.0.4 just to make the Oracle Portal WSRP compliant so that it can consume JSR-168 compliant BI EE portlets. In the case of Weblogic, it supports WSRP by default. One downside though is Weblogic Portal 10.3 does not provide login portlets out of the box. This is essential to render EPM 11 portlets. I will demonstrate how we can enable a login portlet in the Weblogic Portal later here. One other good thing about Weblogic portal is it supports Portal deployment directly from the Eclipse IDE. This is so essential during the development cycles and i thought that is the biggest differentiating factor between Oracle portal 10g and Weblogic Portal 10g. Oracle Portal 10g supported only web based development and lacked a true IDE integration.

When you install EPM Workspace or Web Analysis, the Workspace portlets get installed automatically. There is nothing extra that we will have to do to use the portlets.

We will start with creating a very simple report in Web Analysis as shown below. This a report based on the SH schema.

Once the report is created, login to the machine where the portlets are installed. Navigate to the directory {HYPERION_HOME}\products\Foundation\workspace\InstallableApps\portlets

In this directory, you would find all the portlet files for various portals. In our case, since we are using Weblogic Portal, we will have to copy the bea-avaproxy.zip to a temporary directory and decompress it.

The next step is to navigate to the Weblogic Portal and open up the eclipse IDE (workshop). If you are new to Weblogic Portal, the following steps will basically highlight what you need to do to quickly create a portal. Start with creating a simple Portal EAR Project directly from the Eclipse IDE.

Once you have created the EAR Project created, associate the project with a Weblogic domain. If you do not have a domain, you can create it as part of the EAR creation process.

Once the EARProject is created, we will have to create the Portal Web Project. While creating the Portal Web Project ensure that you are assigning the Samples DVT application as part of the project facets. This is very important for the portlet integration to work. This DVT application provides a login portlet that we can use within the portal. Remember that EPM portlets cannot be used by autonomous(non-authenticated) users.

Once the Portal Web Project is created, we need to deploy the portlets that we decompressed before. Portlet deployment in weblogic is done by copying the portlet.xml from the decompressed portlets folder to {BEA_HOME}\{Workspace_Home}\{PortalWebDirectory}\WEB-INF folder. In my case i had to copy the portlet.xml from /home/oracle/portlets/WEB-INF to /u01/app/bea/user_projects/workspaces/default/EPMPortalWebProject/WebContent/WEB-INF. Remember while copying on linux, the portlet.xml will contain Ctrl characters like ^M. Ensure that you do a dos2unix on this file before copying.

After copying the portlet.xml, merge the contents web.xml in /home/oracle/portlets/WEB-INF with web.xml in /u01/app/bea/user_projects/workspaces/default/EPMPortalWebProject/WebContent/WEB-INF folder.  For reference i have attached the web.xml and portlet.xml files here and here. Then ensure that every other file/folder (from decompressed portlet directory) is copied within the Portal Web applications portlets directory as is.  This will enable us to use the EPM portlets within the workshop framework. After the deployment, the eclipse IDE will recognize the portlets and will list it in the Design Palette as shown below

To use the portlets, lets create a page in the Workshop portal and include the following portlets

1. DVT Enabler – Login portlet
2. Hyperion Reporting and Analysis Portlet
3. Hyperion Reporting and Analysis credentials Manger Portlet

Now run this portal directly from Workshop. Remember to alter the name of the portal to remove the .portal extension. Else deploy the portal from Portal Web Admin console. If you deploy it with the portal extension, the portlets will not render properly.

As you see, since we have not logged in, both the portlets will throw an error. Lets login as the admin user. After logging in, we customize the portlets by entering the EPM username/password. The report portlet basically has 2 options. One is to specify the path of the report. And the other is any parameters that we would like to pass. When i tried this, the portlet seemed to be very fast, much faster than workspace itself.

Not all the functionality available in the EPM workspace will be available in the portlets like Drill up, Keep/Remove etc. Basic drill functionality will work though.

The biggest compelling feature, in my opinion to upgrade from 9.3 to the EPM 11 release is the inclusion of the new Life Cycle Management utility which makes the process of migration from one machine to another all the more smoother. Not that this utility works perfectly or isnt without bugs, it is nevertheless a significant leap from the older 9.3 release and can drastically reduce migration times/effort involved.

The 2 common issues in the 9.3 release was

1. There was no automated way of migrating shared services users/groups/provisioning information from one machine to the other. There did exist a CSV/XML import-export utility but it was never straight forward to use. Just to work around this we had to build a custom JAPI based User/Group extractor.

2. There was no automated way of migrating Essbase artifacts without doing copying from the file system (Outlines, rule files, calc scripts etc). EAS does provide an option to copy applications across multiple servers but unfortunately cannot be automated out of the box. Even if we can somehow automate it by reusing the EAS Jars, we cannot reuse the same scripts without modification across environments.

Now only if we could have a similar such utility in BI EE, it will make the process of migration all the more smoother. Anyway i am digressing. Today, i will demonstrate how this utility can be used to migrate Essbase applications from one environment to another.

LCM Utility supports 2 kinds of migration

1. Application to Application Migration – If you have multiple instances of Essbase registered in a single shared services instance, then this migration automatically migrates the Essbase Application & Database Artifacts to the other Essbase instance through the common Shared Services CSS.

2. Application to File System Migration – This is the most common case. If you have multiple instances of Essbase registered in different shared services instances then this utility migrates all the necessary artifacts on to the file system. Then we need to move the extracted artifacts to the target machine and then run the utility again which will reimport the application in the target machine.

I will demonstrate the 2nd type of migration for Essbase as that is the most commonly used one. We start with migrating a very simple database Sample->Basic. The migration can be executed directly from shared services or can be remotely executed using the LCM utility. But for either of them to work, we will need something called as a Migration XML. This XML basically defines the source and target artifacts that we will be migrating from/to. This XML is created from Shared Services by navigating to the corresponding Application Group that we would like to migrate

In the screenshot above, we have basically chosen all the artifacts corresponding to the Sample->Basic database. One very good thing about this is, it migrates the security & Substitution variables(which are not stored as separate files but are created through MaxL) as well. All the major artifacts are identified using the file extensions. This does not support data migration i.e if your cube has data in development, the LCM utility will not migrate the data to the test/prod machine. We will have to do that manually. Also, Partitions will have to be recreated manually in the target instance using MaxL. Once the artifacts are chosen, we need to click on “Define Migration” to specify how we would like to migrate the Sample->Basic database artifacts.

We shall choose the file system migration for the Destination as shown above. We can specify any folder name here. This will in turn create a folder under {HYPERION_HOME}\common\import_export\<user>@<Directory>\<foldername>. The folder will be created only when we execute the migration. Currently we are just defining the XML for the migration. Once we have defined the destination options we need to save the MigrationDefinition XML

<Package name="web-migration" description="Migrating Product to File System">
    <LOCALE>en_US</LOCALE>
    <Connections>
        <ConnectionInfo name="MyHSS-Connection1" type="HSS" description="Hyperion Shared Service connection" user="" password=""/>
        <ConnectionInfo name="FileSystem-Connection1" type="FileSystem" description="File system connection" HSSConnection="MyHSS-Connection1" filePath="/SampBasic"/>
        <ConnectionInfo name="AppConnection2" type="Application" product="ESBAPP" project="Essbase:oraepm2.venkatlap.com:1" application="Sample" HSSConnection="MyHSS-Connection1" description="Source Application"/>
    </Connections>
    <Tasks>
        <Task seqID="1">
            <Source connection="AppConnection2">
                <Options/>
                <Artifact recursive="true" parentPath="/Databases/Basic" pattern="*"/>
            </Source>
            <Target connection="FileSystem-Connection1">
                <Options/>
            </Target>
        </Task>
    </Tasks>
</Package>

If you notice we have defined our XML for doing the migration which is from Shared Services to File System. After defining the XML, we need to execute the Migration. This will extract the necessary artifacts from Essbase to the folder that we specified. Shared Services has a nice console view to look at the status of all the migrations.This can come in very handy if you have a lot of applications and you are migrating all or most of them.

Once the migration is complete you will notice that all the Essbase artifacts will now have been copied over to the File System directory we specified before

To migrate this to another Essbase instance, we can zip the entire File System folder that was created and then move it over to the target machine. We also will have to copy the Migration XML as well. To complete the migration we will have to modify the XML a bit to cater to File System to Essbase migration. The modified XML is given below

<Package name="web-migration" description="Migrating File System to Essbase">
    <LOCALE>en_US</LOCALE>
    <Connections>
        <ConnectionInfo name="MyHSS-Connection1" type="HSS" description="Hyperion Shared Service connection" user="" password=""/>
        <ConnectionInfo name="FileSystem-Connection1" type="FileSystem" description="File system connection" HSSConnection="MyHSS-Connection1" filePath="file:/u01/app/SampBasic"/>
        <ConnectionInfo name="AppConnection2" type="Application" product="ESBAPP" project="Essbase:oraepm2.venkatlap.com:1" application="SampLCM" HSSConnection="MyHSS-Connection1" description="Source Application"/>
    </Connections>
    <Tasks>
        <Task seqID="1">
            <Source connection="FileSystem-Connection1">
                <Options/>
                <Artifact recursive="true" parentPath="/Databases/Basic" pattern="*"/>
            </Source>
            <Target connection="AppConnection2">
                <Options/>
            </Target>
        </Task>
    </Tasks>
</Package>

Remember you will have to modify some of the config files(sourceInfo.xml etc) in the extracted files to support target updates. To import the Sample->Basic application we just have to call the LCM utility directly from command line. This facilitates integration with external schedulers so that we can do the migrations at regular intervals. Also supported is a Java API, so that external applications like ODI etc can call this.

This is pretty straight forward and works pretty well too. But the actual interesting part is in migrating shared services users/groups. This is where it can become tricky. In a couple of my installs, the exports worked absolutely fine but the import process corrupted the entire shared service instance. I observed this on a couple of my OEL-EPM-Weblogic instances. I might have to log this as a LCM bug. But i will cover a workaround in my next blog entry and show how users/groups can be migrated from one instance to the other.

1. Styles
2. Skins

I have blogged about the method for customizing the BI EE UI using both Styles and Skins almost 2 years back here and here. In the case of EPM Workspace, the terminology used is a little bit different. Also, Oracle has an agreement with Bindows, a third party vendor which basically provides the entire framework for customizing EPM Workspace. The full agreement is available on Bindows website here.  I am not sure how the agreement works, but i believe it does allow for change in the UI styles implemented as part of the Bindows framework. In fact Bindows has a nice set of themes on their website(for download) which can effectively be retrofitted back to EPM workspace with some amount of work.

In the EPM 11 release, a new feature was added to support high contrast themes. This can be invoked directly from within the EPM workspace by pressing Ctrl+Shift+H.

Though a third party framework is used, there are also some internal themes that Oracle EPM uses. To understand how this all work together, we need to start with understanding how EPM workspace renders all the themes, styles, images etc. Whenever we deploy the Workspace war manually or do an automated deployment into an application server, the deployment process manually copies certain part of the installed Workspace(or different application) files to the App Server accessible area (within its relative URL reach). This is very similar to what happens in BI EE. When we deploy Presentation Services Plug-in to an app server, all the themes, images etc are copied to the context accessible area of the application server.

As you see in the above screenshot, i have deployed Workspace into Tomcat and hence we have a multitude of workspace related files in the deployed directory. You can see a couple of folders here. themes and thirdparty/bindows/html/themes.

If you notice, we have completely different set of folders under both the theme folders. My initial impression was that only the bindows one was used (not the workspace native one). But on further analysis i realized that both the folders above are required to make the themes to work. Bindows themes are just for Workspace alone(bringing all the components together while using 19000 workspace port). But the individual themes can vary for different products. In the above screenshot we basically had theme_tadpole and theme_tadpole_hc as native workspace themes(workspace as a product). Also, the Bindows specific themes Bpmtadpole and BpmtadpoleHc. Similarly lets look at the ui_themes folder of Hyperion Scorecards

As you see we only have the product specific ones theme_tadpole and theme_tadpole_hc. So, there are a couple of conclusions that we can derive out of this.

1. When customizing the UI of EPM components, the bindows theme as well as the individual product themes should be in sync with each other
2. Ensure that when you have EPM components deployed in multiple machines, all of them get a common ui through the same default theme theme_tadpole. The _hc version of the themes are the high contrast variants of the original themes.

In BI EE, we typically start off with creating new themes(styles) as a copy of existing themes(styles). But in the case of EPM workspace, due to the nature of interaction (or lack of it) between the bindows and the product themes, i would recommend not to create new themes but to modify the existing ones(Its better to backup the older themes so that we have something to revert back on).

To start with lets look at a way of customizing the login screen of EPM workspace.
The login screen basically has 2 parts. One is the background color. And the other is the Oracle EPM logo. Remember, whenever you are customizing the EPM workspace, the same customization will have to be done across all the other product component themes as well. The primary reason is each product can be invoked either through the workspace or directly. In either case, we need to ensure that the UI remains the same. Once you start thinking in those lines, you will actually realize that the customization is actually pretty easy. To customize the logo, navigate to

{HYPERION_HOME}/deployments/<appserver>/<application>/webapps/<application>/(ui_)themes/(theme_)tadpole/images_global/

In my case, since i am customizing the login of workspace alone, i had to navigate to /u01/app/oracle/hyperion/deployments/Tomcat5/Workspace/webapps/workspace/themes/theme_tadpole/images_global folder. Here you would find a file called logon_panel.gif. This is the image that actually gets rendered in the logon screen. Replace this image with you corporate logo. Ensure that the image size is 298*367 (pixels).

Copy the same image over to

{HYPERION_HOME}/products/<product>/AppServer/InstalledApps/<application>/(ui_)themes/(theme_)tadpole/images_global

In my case the actual product folder was /u01/app/oracle/hyperion/products/Foundation/AppServer/InstalledApps/workspace_static/themes /theme_tadpole/images_global.

This is very similar to BI EE customization where we need to have the modified style in both the product directory as well as the installed app server directory. Once we have changed the image, the next step is to change the background color. It can be a little bit difficult to do understand this part as there are 4 places that we need to modify the settings. I will just list them down here

1. Global.css file in {HYPERION_HOME}/products/Foundation/AppServer/InstalledApps/workspace_static/themes/theme_tadpole/ - Product Customization
2. Global.css file in {HYPERION_HOME}/deployments/Tomcat5/Workspace/webapps/workspace/themes/theme_tadpole/ – Product Customization
3. theme.css file in {HYPERION_HOME}/deployments/Tomcat5/Workspace/webapps/workspace/thirdparty/bindows/thirdparty/ themes/Bpmtadpole
4. theme.css file in {HYPERION_HOME}/products/Foundation/AppServer/InstalledApps/workspace_static/thirdparty/bindows/ thirdparty/themes/Bpmtadpole

Just edit the css files and modify the necessary property (in our case the background color property). The above changes will ensure that you have customized your workspace application as well as the overall workspace. If you have deployed more applications like Planning, Shared Services etc to be accessible through the workspace, the same customizations will have to be done in those components as well.

Update: Though theoretically we can customize the entire look and feel of EPM Workspace, you might want to check the licensing agreements to see what can be and cannot be customized.

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

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.

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.

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.

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.

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.

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

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>

3. 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.

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

5. 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.