Saturday, 30 November 2013

11.1.2.3 Planning – email configuration

To configure the email server in all planning releases prior to 11.1.2.3 it would be done through the system settings area in each application and this had to be done by the application owner.


Moving on to 11.1.2.3 and you will notice a subtle change in the system settings.


The email server option is not available anymore and if you are a planning administrator you may be wondering where it has gone.

From the release of version 11 it has been Oracle’s objective to get as much configuration information held centrally within the Shared Services registry which means all product components can share this information and there is no need for duplication which makes perfect sense.

At last planning has now moved a little step forward and can access the email configuration directly from the Shared Services registry so it only needs to be configured once and will be in sync with other EPM products.

So how is it configured, well if you have been involved with any of the EPM configuration then you will no doubt know the answer and that is it can be achieved using the EPM system configurator.

If you are not sure how to access the configurator then have a read here.


Once the configurator has started only select “Configure Common Settings


You will notice there are more email configuration options available than you will previously be used to with planning, some of the major complaints in the past with the planning email configuration was the mail server port could not be selected and anonymous authentication was the only option so this is a welcome change at last.

The biggest question I had was does the authentication option work as just because it is there a common setting it doesn’t mean it would necessarily be available to planning, it is something that I will shortly test out.

Once the email properties have been applied these will be stored in the Shared Services registry.


You can verify this by running a registry report with the epmsys_registry command line utility

The property values can also be updated directly using the utility, an example to update the email server hostname would be:

epmsys_registry.bat updateproperty SHARED_SERVICES_PRODUCT/@SMTPHostName mailserverhostname

Though for some reason there are two properties which seem to be the same SMTPHostName and SMTPMailServer so both should be updated.

To update the authentication password then the addencryptedproperty can be used which encrypt the password before writing to the registry:

epmsys_registry.bat addencryptedproperty SHARED_SERVICES_PRODUCT/@SMTPServerPassword password

It is also true that it is possible to export/import registry information using LCM though the important caveat being it doesn’t look to encrypt the password on import.


Anyway time to test out whether the email functionality is successful in planning with the authentication option enabled.


Unfortunately it seems to be that email addresses still have to be manually configured in planning and there is no option to bring this through from Shared Services which personally I think should be fully integrated by now.


For the test I enabled the due date option for a task list entry and then monitored the email server.


The email server logs confirmed the email was sent and authentication was successful.


A check of the planners email account confirmed the email was delivered so at least I know the functionality is definitely working.

Wednesday, 6 November 2013

Patch available for 11.1.2.3 EAS web console bug with Java 7 update 45

Recently I posted a blog about an issue with 11.1.2.3 EAS web console and Java 7 update 45, if the update is applied then the web console is blank when opened and cannot be used.

I just noticed that there has been new patch set updates (11.1.2.3.003) released for Essbase related products which includes the following:

Patch 17609518: PATCH SET UPDATE: HYPERION ESSBASE ADMINISTRATION SERVICES SERVER 11.1.2.3.003

The one bug fix in the PSU is to address the Java issue:

17649604 - After Java 7 Update 45 has been updated, EAS console cannot start via Web Launcher.

I thought I would test out the patch and it has resolved the issue with the Java update.


The remaining Essbase related 11.1.2.3.003 patches are:

Patch 17609530: PATCH SET UPDATE: HYPERION ESSBASE RTC 11.1.2.3.003

Patch 17609535: PATCH SET UPDATE: HYPERION ESSBASE SERVER 11.1.2.3.003

Patch 17609493: PATCH SET UPDATE: HYPERION ANALYTIC PROVIDER SERVICES 11.1.2.3.003

Patch 17609497: PATCH SET UPDATE: HYPERION ESSBASE ADMIN SERVICES CONSOLE MSI 11.1.2.3.003


There are few interesting bug fixes for Essbase server:

17649547 - In some cases, after a dense restructure the size of the Essbase index files grows more than expected.

17649545 - During a dense restructure, the restructuring in some cases can fail and give the following error message: Corrupted Node Page in the B+tree.   [adIndPromoteSafeWrite] aborted


For Provider Services:

17275594 - In some cases, when retrieving with Smart View Client can result in getting an error: Binary Spreadsheet Table Token Error

Thursday, 31 October 2013

11.1.2.3 EAS web console with Java 7 update 45

Update: PSU released to fix issue:
Patch 17609518: PATCH SET UPDATE: HYPERION ESSBASE ADMINISTRATION SERVICES SERVER 11.1.2.3.003

If you are running 11.1.2.3 and use the EAS web console with Java 7 then make sure you don’t apply update 45 or the console will stop working.

This has already been blogged about by the Proactive Support team but I thought I would give another update in case you have not seen it plus there is an Oracle support document available and the issue has now been logged as a bug.

If using Java 7 and a version prior to update 45 when opening the web console you probably see the following warning.


It is not advisable to update as if you do and start the web console you will be hit with the following:


A blank console window which you can’t do anything with or even close by hitting the X

If the java console is enabled numerous java exceptions will also be outputted.


To close the console window open Task Manager


End the javaw.exe process.

The obvious solution is not to apply update 45 as update 40 works fine but I know that is not always an easy option when updates are automatically controlled internally, alternatively the EAS thick console can be installed until the bug has been fixed, I know multiple java versions can be installed and enabled separately but I am not sure if that workaround is possible in this situation.

For further information you can check out the Oracle support document:

“Essbase Administration Services (EAS) v11.1.2.3 Console Does Not Work with Java 7 Update 45 (Doc ID 1594567.1)”
The bug reference is:

“Bug 17616538 - BLANK EAS CONSOLE AND HANG WHEN OPEN VIA WEB LAUNCHER WITH JAVA 7_45”

I will update this post when there is any further updates or a patch released to address the bug.

Saturday, 19 October 2013

Essbase 11.1.2.3.002 PSU incorrectly packaged

Update 6th November 2013: 11.1.2.3.003 PSU now available for Essbase related products and are correctly packaged.

I was intending on applying the latest patch set update 11.1.2.3.002 for the Essbase related products and noticed an issue with the Essbase Server and RTC patches which I thought I would share.

Now I know that the problem will be soon rectified and I will update this post when it has been updated in Oracle Support.

If you have applied the 002 PSU or have downloaded and are planning to then it is worth revisiting as it looks like they have been incorrectly packaged which seems to affect all platforms.


At first glance the patch on Oracle Support may look to be fine but on closer inspection it is only indicating the bugs resolved are for the previous 001 PSU


Once downloaded and extracted the patch number in the directory structure is incorrect and it is the 001 patch number not the 002 one.

If you take a look at the properties of the files in the PSU then they look to be correct.


The files are correctly displaying 11.1.2.3.002 so it looks like patch was just incorrectly packaged up.

You may be thinking you can just change the directory name to be the correct patch ID of 17417313 and then apply the patch.


If you do that the patch will be applied correctly but you will notice that it is still displaying the 001 patch ID instead of the 002 ID


Running an inventory report will output that .001 patch has been applied instead of 002 and the bugs resolved are only for .001 PSU

You may feel comfortable leaving the inventory with incorrect information but it is not an option for me so I looked into fixing it as all the Essbase product files indicate they are for the 002 release so it could be an inventory problem.

I rolled back the patch as I only applied it to demonstrate what happens.

Within the PSU directory structure under <patchid>\etc\config there is the inventory xml file.


Editing the file confirms the reference id is incorrect and is for the 001 release, the unique patch id looks to be correct as it is different than the one for the 001 release and if you search for it in Oracle Support it does correctly return the 002 PSU.


The inventory file also only contains the bugs for 11.1.2.3.001 and is missing 11.1.2.3.002

Fixing the file only requires a few changes.


The reference id number was updated to be the correct ID for the PSU which is 17417313.

As it is a cumulative patch I left in the base bug information for 11.1.2.3.001 and added in the 11.1.2.3.002 PSU information and that is pretty much all there is to it.


This time applying the patch displays the correct patch ID of 17417313


Running the inventory report confirms the patch ID is correct and the bugs fixed are for the 001 and 002 releases.

I carried out the same process for the Essbase RTC 002 release as that has been packaged up in the same way, all the other Essbase related product patches seem to be fine.

I expect the files will be fixed in Oracle support in the near future which makes this post obsolete but I thought I would share anyway.

Monday, 23 September 2013

EPM Standalone Log Analysis Utility

In 11.1.2.3 a new command line utility was released that analyses ODL compliant logs to help troubleshoot problems and find route causes.

If you are not aware of the utility here is the Oracle documented information on it:

The Log Analysis Utility is a command line utility that helps you quickly identify the cause of issues reported by EPM System components by analyzing the applicable log files. Because this utility automates log file analysis, you do not need to manually locate and scan through EPM System log files to identify issues. Information required to troubleshoot the issue or to escalate it to Oracle Support is quickly available by running this utility. Generally, run on the server where Oracle Hyperion Foundation Services is installed, this utility accesses and analyzes log files on all the servers identified in the Oracle Hyperion Shared Services Registry of an EPM System instance.

Using the Log Analysis Utility you can:

  • List EPM System errors that occurred within a time period. System issues are related to services, intercomponent communication errors, and user directory communication errors.

  • List functional issues that occurred within a time period. Functional issues are related to EPM System component functionalities; for example, failure during an Oracle Essbase calculation run or the forms load process in Oracle Hyperion Planning or Oracle Hyperion Financial Management.

  • Trace an Execution Context ID (ECID) through log files to trace user sessions across EPM System components. ECID is a unique identifier that is used to correlate events that are part of the same request execution flow. ECID is an Oracle standard unique ID.
The good news is this utility has been now been released as a standalone version that can be used to analyse logs from any 11.1.1.x to 11.1.2.x deployments and does not have to be run on EPM servers as it just requires access to the logs.

Though be aware that it is only ODL compliant logs it will run against so the older the EPM version the less of these type of logs will exist

The standalone utility can be downloaded as a patch (17425397) from Oracle support:


Once downloaded it is simple to get up and running with it.


Extract the utility and then edit loganalysis.bat/sh to set to a valid JAVA_HOME, it is worth noting that the utility is currently compiled with JDK 1.6.0_35 so I am not sure how well it will run against older versions of Java such as the default ones used in 11.1.1.x

Now I am not going to go through all the various parameters that can be used with the utility as the readme and documentation provide sufficient information to get a good understanding on what functionality is available.

I tested the utility against an 11.1.2.2 environment and at first I thought it would run just by setting the EPM_ORACLE_HOME variable but the utility errors out.


As this is a standalone utility it requires the use of –d parameter which defines the directory path to start searching from, the utility will search all the directories below the base directory.

As an example I stopped the database for all the EPM components and then started up Essbase which should generate errors because the communication to the Shared Services registry will not be available.

The command I used was:

loganalysis.bat -system -tday 1 -d E:\Oracle\Middleware\user_projects\epmsystem1\diagnostics\logs\essbase

This basically means the utility will search the logs starting in E:\Oracle\Middleware\user_projects\epmsystem1\diagnostics\logs\essbase and run a report for any ERROR and INCIDENT_ERROR types generated within the last day.



Once the utility has been run it will generate a html report in the same directory as the utility and then open it.


The report has picked up 12 errors and by looking at the messages straight away it points to an issue connecting to the Shared Services registry.

Running a similar report against the planning logs highlights issues with the database connection.

loganalysis.bat -system -tday 1 -d E:\Oracle\Middleware\user_projects\domains\EPMSystem\servers\Planning0\logs



The report also includes all the logs files which have been processed.


The utility has functionality to allow searching for a string using the –s parameter which I gave a quick test to search for the following “Out of memory” error:

[2013-09-20T19:39:20.127+01:00] [Profitability0] [ERROR] [EPMPCM-03028] [oracle.EPMPCM.web] [tid: 16] [userId: ] [ecid: 0000K1FlAWh7a6i5p7K6yY1HyxpJ0004_4,0] [SRC_CLASS: com.hyperion.profitability.web.filter.PersistenceFilter] [APP: PROFITABILITY#11.1.2.0] [SRC_METHOD: doFilter] Rolling back current transaction because of an exception[[javax.servlet.ServletException: java.lang.OutOfMemoryError: allocLargeObjectOrArray: [C, size 1179664


I ran the following:

loganalysis.bat -system -d E:\Oracle\Middleware\user_projects\domains\EPMSystem\servers\ -s "java.lang.OutOfMemoryError"


Unfortunately the utility did not pick up the error as it does not seem to search the supplemental detail in the log entry and the search needs to be focused on the initial error message for example:

loganalysis.bat -system -d E:\Oracle\Middleware\user_projects\domains\EPMSystem\servers -s "Rolling back current"


I am hoping the search functionality will be improved to allow a full search of the log entries which I understand will impact the running time but it would be nice to have the option, also allow multiple search strings and wildcards (I did not see anything mentioned about these in the documentation)

The utility does have some nice options like be able to search by different error types so it can be used to pick up functional related areas so let’s see when the last time the PLANS Essbase application was last started and its process ID

loganalysis.bat -functional -d E:\Oracle\Middleware\user_projects\epmsystem1\diagnostics\logs\essbase -s "Application [PLANS] started"


The utility can be set to run against multiple directory paths and can also analyse by ECID so in theory once you have the ECID you could trace a user’s session across the system.

So it is definitely worth having a look at the utility as it is easy to set up, it does not have to be run on an EPM server, it can be used across multiple EPM versions and certainly can save time trawling through the mass of logs.

I would be interested to know your views on the utility and how you feel it can be improved because I know the developers are looking for feedback which I will pass it on so maybe the enhancement requests will be included in future releases.

Wednesday, 4 September 2013

EAS - single sign-on to Essbase using separate Shared Services instances

I am back with a blog that was inspired from a question posted on the OTN forums, the poster asked if it was possible to use single sign in EAS to connect to two Essbase servers which are managed by separate Shared Services instances.

The initial answer is no because each Shared Services instance will use a unique CSS token encryption key but the answer changes to yes it is possible with the help of a utility.

Before I go through the process on how to achieve the single sign-on between environments I want to stress that this is just an example which may not be supported and it is not something I endorse so think about the consequences and security aspects before attempting.

I will be using 11.1.2.3 in the example but it should also be valid on 11.1.2.2

Both environments have been configured to use the same external directory in Shared Services as I don’t believe it will work with native directory accounts.


 An AD user called essbaseadmin has been provisioned with the Essbase administrator role on both environments.


I have already added the first Essbase server using SSO in EAS and as this it is using the same Shared Services instance there are no problems connecting to it.


Now let’s add an additional Essbase server which is managed by a separate Shared Services instance.


The “Use Single Sign On” option was selected.


Connecting to the Essbase server fails with the standard login fails due to invalid login credentials error.


Usually you would just add the server without using single sign-on and enter the username and password to connect with, I don’t see the problem with this and it should be the way to connect but that is just my opinion.

Anyway back to the original question and how to achieve the single sign-on, if you take a look on a foundation server in the directory:
<MIDDLEWARE_HOME>\EPMSystem11R11\common\CSS\11.1.2.0
you will see a zipped up file called regSyncUtil_EPM-to-EPM.zip


The archive file contains a pretty unknown utility which allows the migration of the CSS token encryption key between two Shared Services registries so a CSS token generated on the source environment should validate on the destination environment.

If you have ever gone through the process of single sign-on integration between Workspace and OBIEE then you will have used the same utility to migrate the encryption key.


Before running the utility there are a couple of steps that need to be completed.
  • Copy reg.properties from the source environment to the src folder.

  • Edit runRegSyncUtil.bat and update the ORACLE_HOME,ORACLE_HOME,JAVA_HOME variables to contain the correct full paths

If running the utility is successful the key should be read from the source registry and imported into the destination registry.



If you compare a registry report before and after running the utility you will see the CSSHandlerKey2 property value is updated.

Now that is done the Essbase server can be added again in EAS.


Once again the “Use Single Sign On” option is selected.


And there we go the user is able to log straight into the Essbase server using SSO.

This concept can no doubt be used for other products that generate and pass a SSO token.

Friday, 23 August 2013

11.1.2.3 PSU released for Essbase products

The first 11.1.2.3 patch set update for Essbase related products was released this week and this time they all start with a memorable .001


If you are interested here are all the patches:

Patch 13951433: PATCH SET UPDATE: HYPERION ESSBASE SERVER 11.1.2.3.001

Patch 17323312: PATCH SET UPDATE: HYPERION ESSBASE CLIENT MSI 11.1.2.3.001

Patch 13951424: PATCH SET UPDATE: HYPERION ESSBASE RTC 11.1.2.3.001

Patch 13951402: PATCH SET UPDATE: HYPERION ESSBASE ADMINISTRATION SERVICES SERVER 11.1.2.3.001

Patch 13951408: PATCH SET UPDATE: HYPERION ESSBASE ADMIN SERVICES CONSOLE MSI 11.1.2.3.001

Patch 13951415: PATCH SET UPDATE: ORACLE ESSBASE STUDIO SERVER 11.1.2.3.001

Patch 13951419: PATCH SET UPDATE: ORACLE ESSBASE STUDIO CONSOLE MSI 11.1.2.3.001

Patch 13951412: PATCH SET UPDATE: HYPERION ANALYTIC PROVIDER SERVICES 11.1.2.3.001

If you are running 11.1.2.3 then it is worth checking out the readme for each patch to see if you feel it is worth applying though they are all purely bug fixes and contain no additionally functionality

As usual the defect fix information in the readme is very vague and my personal favourite description is “Missing data after Essbase application.”, if you understand what that means then do let me know :)

One thing to watch out for if you are applying the APS patch and have the Essbase client installed is that three jar files in <MIIDLEWARE_HOME>\EPMSystem11R1\common\EssbaseJavaAPI\11.1.2.0\lib may have been installed in read-only mode and Opatch will fail trying to update them, easy to fix by removing the read-only attributes.