EPM Workspace integration with OBIEE update

In a recent blog I went through the process of integrating EPM 11.1.2.2 Workspace with OBIEE 11.1.1.7, as EPM 11.1.2.3 is available I thought I would test out the process covered in the blog to see if there are any issues.

In theory the process should be exactly the same and there is nothing yet to state otherwise but unfortunately I did hit a few problems.

Now I am not going to duplicate the last blog so if you are going to integrate then please read through the process first.

At the point of running the HSS registration utility the following error message was generated after entering the Shared Services credentials:

This error through me for a while but after hunting around I found out that the utility is calling upon Java classes in registry-api.jar which is located in <ORACLE_BI1>\common\jlib\11.1.2.0

If you compare the file size to the version in the EPM 11.1.2.3 instance you will see a difference.

The EPM version of the file in <MIDDLEWARE_HOME>\EPMSystem11R1\common\jlib\11.1.2.0 is larger in size so as I test I copied the file from the EPM instance to the OBIEE one.

The HSS Registration utility has the option to clean which removes OBIEE registration information from Shared Services registry and configuration so I thought it best to run this first as it is unclear exactly where the registration process had failed.

The registration clean was successfully so time to run the utility again with the register option.

This time the process gets further but unfortunately fails again with another Java related error.

After more digging around I found that the utility is accessing classes in css.jar which is located at <ORACLE_BI1>\common\css\11.1.2.0\lib

Once again there is a difference in file size between the OBIEE and EPM instance.

I copied the css.jar file from the EPM machine across to the OBIEE one and ran the HSS registration utility but using clean option first and then register option.

Good news the registration was successful and the process from the last blog was continued.

Once all the steps had been carried out the integration between Workspace and OBIEE was tested and the functionality was working as expected.

I am sure that Oracle will either update the jar files in a future OBIEE patch or amend the documentation to include the steps.

So basically if you are going to integrate with EPM 11.1.2.3 make sure the two jar files are copied before carrying out the process in the last blog.

11.1.2.3 – Remove EPM instance

Another new feature to hit the infrastructure side of 11.1.2.3 is the ability to remove EPM instances and the components deployed into that instance, this could be useful if you want to scale down a deployment and say consolidate components onto an existing machine or move an instance to a new machine, it could even be that you messed up and want to remove an incorrectly configured instance.
The following tasks will be performed during the instance removal for the components in this instance:

Removes the Java web applications from the cluster. If it is the last Java web application in the cluster, removes the cluster.

• Removes the configuration for IIS web applications.
• Removes files from EPM_ORACLE_INSTANCE
• Removes Oracle Hyperion Shared Services Registry entries.
• Removes Windows Start Menu entries.
• Removes Windows Services entries.
• Removes Windows Registry entries.
• For Oracle Hyperion Financial Close Management, removes composites.

The following information is retained during instance removal for the components in the instance:

• Binary files in EPM_ORACLE_HOME.
• The contents of EPM_ORACLE_INSTANCE/diagnostics.
• Product data.
• Product repositories.

I know in previous versions removing Java web deployments and cleaning up the registry was certainly not fun and of course manual, though saying that this feature is currently only aimed at instance level so if you have multiple components deployed in a instance they will all be removed, hopefully in future releases this will developed to focus down to individual product component levels.

To perform a simple test of the functionality I am first going to horizontally scale out the foundation web application to a new instance.

The EPM installation was carried out on the second machine and a new EPM instance named epmscaleout was created.

 The foundation java web application was deployed to the existing EPMSystem WebLogic domain.

As this is a second deployment on Foundation the managed server in the cluster is incremented by one.

In this deployment I have configured OHS to a shared drive location, this means there is no need to run the configure web server as the configuration is automatically added.

A quick check of OHS WebLogic proxy configuration file confirms this so all that is required is to restart OHS and refresh Workspace

Within the WebLogic admin console the new managed server which has been deployed to the existing “FoundationServices” cluster can be viewed.

I ran a registry report to display the components that have been deployed and added to the Shared Service registry which I will compare against when the instance has been removed.

The main entries that were added to the registry are:

HOST : EPMSCALEOUT
Instance: epmscaleout
Shared Services / Workspace Web Applications
Instance Tasks configuration for Shared Services/Workspace

A deployment report was also run so this could be compared a report run after the instance being removed.

The main entries displayed in the report in relation to the scaled out Web application deployments:

WebLogic entries for Shared Services/Workspace on the EPMSCALEOUT machine.
Fusion Middleware home and location for the epmscaleout instance
Instance home directory information for epmscaleout

All the information has now been gathered so it is time to remove the instance on the machine the instance is hosted.

If you are running windows then the instance can be removed from a start menu option.

Alternatively it can be run from command line by changing to EPM_ORACLE_INSTANCE/bin and executing:

configtool.bat/sh – remove

If you are removing an instance on a machine hosting the WebLogic admin server then the managed server should be stopped before running the configurator, if like I am removing an instance on a machine which is not hosting the admin server then the admin server should be up and running.

As a test I am not going to start up the admin server and see what happens when running the remove.

Interesting that it states that if it is the last component for the product then the database schema will be removed which is not included in the list of tasks that will be performed, it is not something I have tested out yet though.

After proceeding the command window closed without any error messages, so what happened?

Luckily the process is logged and the logs can be found at EPM_ORACLE_INSTANCE\diagnostics\logs\uninstall

The summary information can be found in unconfigure_summary.log and it clearly states the process failed.

For detailed information then configTool-unconfigure.log can be checked.

[2013-05-07T00:05:50.971+01:00] [EPMCFG] [ERROR] [EPMCFG-01020] [oracle.EPMCFG] [tid: 10] [ecid: 0000JtyCufZFg4WFLz7U8A1HYC5n000000,0] [SRC_CLASS: com.hyperion.cis.config.AbstarctAntDeploymentApiAdapter] Error: [[
Weblogic domain on the remote host FUSION11 not available

The error message indicates as expected that the Weblogic admin server was not available.

Next I ran the remove again but with the admin server running.

Now this is what the command window should output for a successful remove but the windows closes pretty much straight after the last message is displayed so if you blink you will miss it.

The summary log does not indicate a failure so this can be taken a successful removal of the instance and a few checks can be carried out to confirm.

In the admin console the managed server has been removed.

The instance entries from the start menu have been removed.

Comparing a registry report to the one before the instance was removed you can see that some entries still remain, I would have expected the instance tasks to have been removed as I don’t see why they would be required anymore, also even though this was the only instance on the machine the host information still remains, the registry has always had this annoying feature of storing up host, it is possible if you want the registry to be clean to  remove the host entries using the epmsys_registry utility.

Comparing the deployment report to the one run before removing the instance it highlights the entries for the Weblogic web application, FMW home and Instance directory have been removed.

I also ran the registry cleanup utility but it seemed to fail on the last step with a java error.

I am not yet sure if this relates to me removing the instance but I will update once I had more time to look at it.

Even though OHS was configured to a shared file location it does not look like it was automatically reconfigured to remove cluster entries.

As you would expect running the configure web server option again in the configurator resolves this, maybe it will be automatically added to the remove instance functionality in the future.

Update 20/05/2013 - Oracle are aware of the issue when running the registry cleanup utility after adding/removing instances, they are also aware that the OHS WebLogic config file is not updated after removing an instance, both these issues should be fixed in future PSUs.

I checked the file structure under EPM_ORACLE_INSTANCE and besides the diagnostics folder there were only a few empty folders still remaining.

I know this was only a simple test but hopefully it provides an insight into the new functionality.

EPM 11.1.2.3 – Vertically Scaling Java Web Applications

One of interesting new features for EPM configuration in 11.1.2.3 is the ability to vertically scale based Java web applications through the configurator, yes it was possible to vertically scale in previous versions though I am not sure how supported the process was unless you were in the exalytics world and it certainly was not as slick as it is now.

At present the following EPM components do not support vertical scaling:

• All Financial Management components
• EPM Architect Dimension Server
• All Strategic Finance components
• All FDM components
• Essbase Integration Services components

So what is vertically scaling web applications? Well in the EPM context it basically means the process of adding additional instances of already deployed J2EE web applications on the same server they were deployed on.

We are now in an age of not being confined to the dark days of 32bit limits with much more horsepower and memory starting to become the norm on single server 64bit machines so it can make sense to vertically scale the web applications.

With vertical scaling, the servers processing power, CPU usage, and JVM heap sizes  are the main factors in deciding how many server instances should be run on one machine.

So as an example you have a machine with a planning web application deployment which is notorious for being resource hungry but you are still finding that the machine is being underutilized, the JVM has been tuned and there is a large percentage of memory available and the CPU usage is nothing to write home about so maybe this is a good candidate for vertically scaling.

Another consideration is the possibility of some form of high availability, if you have multiple instances of the same web application not only can you load balance to share the load but you are still operational if one of the web application crashes, ok if the machine goes kaboom then you in trouble but there is nothing stopping you horizontally scaling as well.

There is a great piece of research done on “One JVM (64bit) vs Two JVMs(64bit) on a 64bit OS”  from the Oracle product assurance engineering team which is available in a EPM Infrastructure performance tuning guide white paper, the test concludes that there was  a 20% performance improvement when using multiple JVM instances. The improvement came from the reduction in the time spent in Garbage Collection and a significant reduction in lock contention and more efficient use of the CPU shared cache and memory.

Anyway let’s have a look at vertically scaling a java web application, in my example I will be scaling planning on a windows machine but the process is the same for different java web applications and *nix based systems.

Planning has already been deployed to the default port of 8300.

The EPM instance the web application has been deployed against is named epmsystem1.

In 11.1.2.3 the instance name are included in the display and service name of the service which plays a part in vertically scaling as the service name will be unique which was not possible in previous versions.

If you take a look at the servers in the WebLogic admin console there is a single managed server “Planning0” which is part of cluster “Planning”

To begin the vertically scaling process first start up the EPM configurator.

A new EPM instance is required to be created.

Only “Deploy to Application Server” is required for the product component as the other options have already been configured with the first deployment.

The Port and the Managed Server Name have incremented by one so now will be deployed as Planning1 on port 8301.

The port increase is another new feature in 11.1.2.3

“Port Manager, a feature of EPM System Configurator, manages port uniqueness by using Oracle Hyperion Shared Services Registry to check if a port is in use. Port Manager auto-increments ports so that ports not already in use are always shown.”

Once the web application has been successfully deployed then if you take a look at the window services there will be a new service for the vertically scaled web application.

A new instance will be created in the file system which means there will be a duplication of many of the files already created in the original instance.

It is also means that you will need to manage the logs under diagnostics in multiple places but there is no need to worry anymore because you have the new log analysis tool :)

Within the file system for the Weblogic EPMSystem domain there will be an additional executable which runs as the java web app process.

If you take a look in the WebLogic admin console the newly created managed server will be available and added to the existing cluster.

The web application has now been vertically scaled but at the moment the http web server is not aware of the additional server in the WebLogic cluster.

In the OHS mod_wl_ohs  (the module which handles requests to be proxied from Oracle HTTP Server to Oracle WebLogic Server) configuration file there is still only the original server on port 8300.

The “WeblogicCluster” (click to the link to find more information) parameter is required to proxy a list of back-end servers that are clustered, or to perform load balancing among non-clustered managed server instances.

To allow the second instance on port 8301 to be configured with the http server the simple to solution is to run the EPM configurator again and choose to configure the foundation web server.

After configuring the file should now contain the server with the additional port.

To confirm everything has been configured correctly a new EPM deployment report can be fired up.

Once the web applications have been started there will be the two managed server processes running and both should be accessible through the test URL.

So there we have it, vertically scaling is definitely an option worth considering.

Planning 11.1.2.3 – Smart View metadata management

One of the new features in planning 11.1.2.3 is the ability to manage dimensional metadata through Smart View which I am sure many are keen to find out more about so here is my take on the new functionality.

The key highlights are:

• Import existing, add, and edit dimensions and members.
• Move members within a hierarchy.
• Designate members as shared.
• Create and refresh cubes.

I have not found any mention of deleting members so I am not sure if that functionality exists or it is going to be one for the future.

As this is the first release of being able to manage metadata using Smart View don’t expect it to be perfect yet, I have already noticed a few issues and there are currently a number of inaccuracies in the documentation which I am sure will get resolved in later releases.

Before jumping straight into Smart View and trying out the functionality a Smart View planning extension is required to be installed.

The extension can be downloaded from the Tools menu in workspace and luckily it is one of the install links that actually works at the moment.

This will download a file called “PlanningSVExtension.msi” which is 1.4mb in size and can be easily installed by running the msi.

 I am not going to go through the installation as it as simple as selecting the installation directory and clicking next through the various screens.

Once installed if the Extensions tab is accessed through the Smart View options you will see a Hyperion Planning Admin extension has been installed and enabled.

To get running with the Planning Administration connect to planning using a Shared or Private connection in Smart View.

If a planning application is expanded then there will be a dimension folder which can be expanded to reveal all the dimensions (ok Period is not available).

After selecting Edit dimension an ad hoc grid will be retrieved at the root dimension level with the following functions available in the ribbon.

So now you can zoom in and out and select the members you interested in updating.

Here is an example of a quick retrieve including all the columns available:

In my sample application I have added an ASO database which the metadata can also be maintained.

There are a number of set guidelines when using the Smart View Grid.

• The following functionality is not available in Smart View grids with Planning metadata:
• Pivot
• Pivot to POV
• Cell Text
• Cell Notes
• Supporting Details

• Data cell values can be textual or enumeration or numerical.
• The Parent Member is used to specify or modify the parent/child relationship.
• The position of a member in a grid does not necessarily represent the actual position of siblings in the outline.
• Each metadata grid must be linked to a corresponding Planning dimension.
• Columns for each Planning dimension are based on the corresponding set of member properties available in the Planning dimension editor.
• Once a metadata grid is opened, it cannot be re-linked with a different dimension.
• The corresponding valid set of metadata members is specific to each dimension.
• Planning dimension members are valid for corresponding dimensions only.

To change a member property it is as simple as highlighting the property

After selecting a member property a drop-down menu will be presented with the available values for that property, so let’s change the data storage property from “Store” to “Dynamic Calc”

To update the member in planning then all that is required is to “Submit Data”.

A quick look in planning and the member has been updated.

The update does not have to be on a single member and multiple members can be updated in Smart View before submitting back to planning.

Validation of member properties which you would expect is included.


Moving a member

Once again the process is extremely simple.

 Select the “Parent Member” column for the member you want to move to a new parent.

Enter the new parent member name and submit.

Back in planning the member has been moved to a new parent, once again you are not confined to moving a single member and it is possible to change move multiple members at once.

Adding members

There are two different modes for adding new members in the Smart View grid:

• Dimension Editor Mode
• Submit without Refresh Mode

The Dimension Editor Mode (this is the default method) requires a Refresh is performed each time new members are added to a dimension but this method offers faster performance than the Submit without Refresh mode.

If the Dimension Editor Mode is used, new members are marked with an asterisk (*) in the grid after you perform the Refresh. The Submit without Refresh Mode does not require a Refresh but is generally slower in performance and does not mark new members.

The process to add a member using the “Dimenion Editor Mode” method is:

Enter only new member name in the first column (it is possible to enter multiple new member names on separate rows).

Press Refresh.

The new member will be marked with an asterisk and the default properties displayed, please note the member does not exist in planning at this point.

Update the parent member and any required properties then once complete submit back to planning.

The new member should have then been created in planning with the information from the Smart View Grid.

It is possible to change the sign from the default (*) when adding a member, this can be achieved by adding a new property in the planning application.

The documentation says to use “SMART_VIEW_MD_NEW_MEMBER_SUFFIX” which does not seem to work so after a bit of research I came up with adding “SMART_VIEW_DIMENSION_EDITOR_NEW_MEMBER_SUFFIX”

After adding the property the new suffix will appear when adding a new member.

The alternative method for adding members is “Submit without Refresh Mode” which can be set by adding a property in the planning application.

The documentation at present states to use “SMART_VIEW_MD_PARITY_MODE” which does not work for me so I came up with “SMART_VIEW_DIMENSION_EDITOR_PARITY_MODE” set to true.

 With this method you can enter all the member information in one go.

Submit back to planning.

 

The new member(s) should have been pushed to planning.

Shared Members

It is also possible to easily designate a new shared member for a base member.

Select the “Parent Member” for the base member you want set as a shared Member

Update the Parent Member column with the parent member you wish the shared member to be created, set the Data Storage property to “Shared” then “Submit Data”

The "Submit Data" operation will refresh the base member with its original "Parent Member" and "Data Storage" properties.

 A quick retrieve shows that member has now been shared under the designated parent.

Refresh/Create database

Another nice feature is the ability to perform a planning refresh/create from Smart View.

Right click the Dimension folder and select refresh or create.

 

The same options will be available as if it was being performed in planning.


I believe the functionality for managing the metadata is for classic applications only but Smart View does not seem to stop you from trying it on an EPMA application.

There is no warning when editing an EPMA dimension and updated a member property from “Dynamic Calc” to “Store”.

Within planning the member property had changed.

As expected in EPMA the property had no changed but surely something is not right.

Well I think I will leave it there for today and I hope you have found this useful, back soon.