A delve into the disturbing world of the Oracle Hyperion product set, uncovering the mysteries and facts beneath the shiny surface, yawn your way through yet another blog, let's hope this one is interesting...

Sunday, 24 July 2011

I am not sure if it is just me but the session timeout in 11.1.2.x EAS has slowly managed to annoy me more and more, if you leave EAS unattended for a period of time then you will likely be hit with

The session times out, now you may be saying stop whinging and log in again which is perfectly acceptable and I have been doing that for a long while but I thought it was time to put a stop to it. I have also been wondering why it has not bothered me in the past, maybe my patience has started to run out these days.

Anyway here are the quick and easy steps to increase the timeout.

On the server where EAS is installed and in location <MIDDLEWARE_HOME>\EPMSystem11R1\products\Essbase\eas\server\AppServer\InstallableApps\Common there will be a file called eas.ear (Enterprise Archive file format), this file basically contains the EAS web applications which are deployed each time the EAS Weblogic managed server is started and within the file there is a configuration xml which defines the session timeout.

I will be using 7zip to open and extract from the ear file as personally I find it an excellent free piece of software, if you are going to be making any changes I recommend taking a backup of the eas.ear file first.

The eas.ear file is opened with 7zip and within the file there are a number of war (web application archive) files which each relate to the different EAS web components, the file eas.war is the one we are interested in as it is the main EAS web application.

The eas.war file is opened and then the directory WEB-INF

The WEB-INF directory contains the web.xml file which defines the structure of the web application; this file is to be edited so it is extracted from the archive.

The file is opened and towards the end of the file there is the line -<session-timeout>45</session-timeout>The default value is set is 45 which means an EAS session times out after 45 minutes of inactivity.

The value can be updated to a timeout that suites you, once updated save the file and drag it back into the archive and save the ear file, restart the EAS web application and the new timeout will be effective.

I did check back at the default value used in version 11.1.1.3 and it was set to 1440 (24 hours) so no wonder it didn’t annoy me in the past.

From one annoyance to another, if in 11.1.2.x you have ever tried to open multiple sessions of workspace then you will hit a slight problem which is you can’t seem to do it anymore. Now there may be many circumstances where you want to have multiple instances of workspace open say for instance say you log in with an admin account and are making some changes to an application and you want to test them at the same time using a different user account, if you try and log in while the admin account is logged in it will just take you straight to the currently logged in session.

Ok, you can log out and log in again or say use IE and Firefox together but there is another method.

When logging into workspace append the parameter multi_process=true as shown above.

This example is using IE8 but is similar in other supported browsers. Go to File > New Session which will open another browser

Log in again using the multi_process=true parameter and there you have it multiple instances of workspace running at once.

Seeing as we are on the topic of workspace I thought I would take this chance to briefly go through some of options that available through "Workspace Server Settings".

In the past I covered speeding up authentication through the "Enabled Products" option which you can read about here.

Enable Installer Menu Items in Workspace

The default option is "Yes"

Depending on the products installed workspace will display different available client downloads.

Setting the option to "No" will leave an empty Install menu.

Enable User Display Name

The default option is "No"

This will display the login username in workspace.

Changing the option to "Yes" will display the full name of the user logged in.

Enable Native User Password Change

The default option is "Yes"

This allows users to change their password through the Tools menu; if the option is changed to "No" then the "Change Password" menu option will no longer be visible.

Required Logon Role

The default option is "None" which basically means anybody with an account even it has no provisioning roles applied can still log into workspace.

The other options available are -

Reporting and Analysis Role

A user must be assigned a "Reporting and Analysis" role or a "Foundation" role to be able to log into workspace.

Global Role, Reporting and Analysis Role, or Application Role

A user must be assigned a "Reporting and Analysis" or a "Foundation" role or an Application role such as Planning, HFM, Financial Close etc to be able to log into workspace.

If a user does not have a required role provisioned to them then the error message generated by workspace will be an authentication message which sometimes could be misleading as it doesn’t mean the username/password is incorrect.

Message File

This allows a message to be sent to all users logged into workspace or once they log into workspace.

The "Client Message Polling Interval" default is zero which means the messaging system is disabled, if it is set to anything other than zero then this will be the time in minutes that new messages are checked for.

A user will be greeted with a message like above, unfortunately HTML code cannot be used in the message.

Accept Credentials on HTTP GET Request

The default is "No"

If the option is set to "Yes" then it is possible to log straight into workspace using the sso_username and sso_password parameters.

Client Debug Enabled

The default option is "No" if set to "Yes" then a number of debugging features are available in workspace, now I must admit I don’t really understand some of them but I thought I would show what is available.

Using the URL http://<workspaceserver>:port/workspace/debug/configInfo.jsp will provide configuration information around all the installed products.

If the parameter debug=true is appended to the workspace login URL then you will notice a window called "Logging" is available in the bottom right corner.

Double clicking the window will display a mass of logging messages.

If the parameter module=wksp.widgets if appended to the workspace URL then a number of test cases and debugging utilities are available, I have no idea of what use they are but maybe somebody will find them interesting.

Sunday, 3 July 2011

This week’s blog is a continuation from the last one on compact deployments, it is not essential that you have read the last blog but for this one to be of any benefit then you would have had to successfully completed a compact deployment.

In the original post on EPM compact deployments I left two open questions and this week it is time for the second question to be covered off which only relates to windows OS deployments.

Once a compact mode has completed successfully a batch script named startEPMSystem.bat is generated to start up the WebLogic managed server, no windows service is created like the other WebLogic deployed products so to make life a little bit easier I set myself a task to create a windows service that will start up the EPM managed server.

Now I know it is probably possible to try and use the Weblogic install service utility but I didn’t have much success with it and I also I wanted the service to function like the other products in the stack so here are the steps I carried out to set up the service.

In a standard deployment once the Weblogic web applications have been started and if you look in task manager you will see a process for each managed server, each process has the same description as in fact they are all the same executable just with a different name.

Each of these executables are called when the service is started and they all reside in <MIDDLEWARE_HOME>\user_projects\domains\<domain name>\bin

The executables originate from <MIDDLEWARE_HOME>\EPMSystem11R1\common\utilities\JavaService, there is a 32bit and 64bit version of the executable.

When a Weblogic managed service is deployed it copies the file from the above directory into <MIDDLEWARE_HOME>\user_projects\domains\<domain name>\bin and renames it depending on which web application is being deployed.

I copied HyslJavaServiceAMD64.exe into <MIDDLEWARE_HOME>\user_projects\domains\epmsystem1\bin and renamed it to EPMSystem.exe

Usually the default deployment domain name is EPMSystem but in my compact deployment I called it epmsystem1.

If you take a look at any of the start up commands for the windows services you will see/ServiceName= and /RegKey= these define the registry keys used and are called upon when the windows service is started.

The keys are all stored under HKLM\SOFTWARE\Hyperion Solutions and contain important variables and various paths to pass into the WebLogic managed server for it to be able to function correctly.

For the windows service I am creating I would need to create a new registry key for the EPM Managed server.

When a compact deployment is run it creates a file called setManagedParamsEPMserver.bat in <MIDDLEWARE_HOME>\user_projects\domains\<domain name>\bin

This file contains all the necessary information for the registry key so the next step was to transfer this information into a .reg file.

Instead of creating the file from scratch I did use a registry key that had already been created from another EPM 11.1.2.1 instance, I used the foundation services registry key as a starting point and these keys can be found in <MIDDLEWARE_HOME>\user_projects\<instance_name>\bin\deploymentScripts\installServiceScripts

The registry file needed a clean up as some of the options are repeated two or three times.

This is the registry file I came up with, it was saved as a .reg file and executing it updated the registry with the information. If you intend on using it then you will need to update the middle home directory and maybe the domain name if you use anything other than epmsystem1 as the usual domain name in an EPM deployment is EPMSystem.

One of the nice features of using this method is you get the option of generating logs like the other EPM products that use a windows service using the SysErrFile and SysOutFile options

The final step is to generate the windows service and this can be done by using the command line utility SC.

When I started up the service I did notice some errors in the log relating a performance pack which stressed that performance could be degraded, this didn’t stop the managed server from starting up and working but it needed fixing, I went back to starting up the managed server by the standard batch file and the same error was being generated so it wasn’t down to the registry file I had created.

To fix this issue I just added an extra path to the –Djava.library.path option in the registry

The path added that was added was <MIDDLEWARE_HOME>\wlserver_10.3\server\native\win\x64

I did spot one more issue which only occurred if I set the JVM maximum size over 1.5GB then an out of memory error was generated in the log and the web application would terminate.

The issue seems to be common when using jrocket as the JVM, if the maximum size was set over 4GB then the error goes away but I found it was possible to also get around the issue without having to set the maximum size to 4GB by adding an extra option in the registry which is passed into the managed server.

An extra JVMOption was added with a value of –XXcompressedRefs:size=32GB (if you want to read in-depth details on why this option may have to be used then have a read here)

As an extra option was added the JVMOptionCount in the registry has to be incremented by 1.I have not seen any other issues and the managed server is running well when started from a service.