Tuesday, 7 April 2015

EPM 11.1.2.4 workspace integration with OBIEE

In the past I have covered in detail workspace integration with OBIEE so today I am not going to go over old ground and only provide an update with integration in EPM 11.1.2.4

I suspect because OBIEE is still at 11.1.1.7.x and there not been too many changes relating to configuration with EPM 11.1.2.4 that the process should still be the same but I feel it is worth testing out to be sure.

The blogs outlining the steps in more detail are available at:

OBIEE 11.1.1.7 integration with EPM 11.1.2.2

OBIEE 11.1.1.7 integration with EPM 11.1.2.3

Issues with OBIEE/Workspace integration when using SQL Server

If you are new to the process then it is definitely worth reading through them to get a good understanding on what is required.

For today I am going to be using OBIEE 11.1.1.7.150120 with a newly built EPM 11.1.2.4 environment and using Oracle as the database repository.

Here is a high level summary of the steps that are being carried out, for a detailed breakdown of the steps please visit the blogs mentioned above:

  • Configure same MSAD configuration in EPM Shared Services and OBIEE WebLogic Admin Server

  • Extract regSyncUtil_OBIEE-TO-EPM.zip

  • Update reg.properties with version from EPM environment

  • Run utility to share encryption key between EPM and OBIEE

  • Remove applicationID from OBIEE EPM registry

  • Copy css.jar, interop-sdk.jar and registry-api.jar from 11.1.2.4 EPM environment to equivalent OBIEE environment locations

  • Register OBIEE in workspace by updating registration.properties and running HSSRegistration tool

  • Reconfigure EPM web server to add in OBIEE proxy information

  • Enable SSO authentication using fusion middleware control

  • Update instanceconfig.xml to add the HyperionCSS authentication schema

  • Update bridgeconfig.properties to enable Hyperion CSS authentication

  • Restart EPM and OBIEE

  • Test
The process is exactly the same as I carried out with 11.1.2.3 and I didn’t hit any new issues.

The good news is that once the configuration was complete and restarted the OBIEE roles were available in Shared Services.


After provisioning an AD user with OBIEE roles in Shared Services the OBIEE was available for the user in Workspace.


Selecting one of the OBIEE menu options in workspace correctly passed across the SSO token and logged into OBIEE analytics without any issues. 


This is fine is you are accessing OBIEE reports that are not using Essbase or HFM as a data source, if you are there are a few additional steps that are required to allow the full SSO which I have not covered previously.

To enable SSO each Essbase/HFM connection pool requires to be updated using the BI admin tool.


The available options are to use a fixed user name to open reports or by using the variable route of :USER and :PASSWORD which will pass the username/password of the user that is currently logged in to analytics to Essbase/HFM but this is not really a true SSO.

To use the same SSO token which has been used in the workspace integration then the SSO option should be selected and saved.

If you then try and open a report which has an essbase data source you will be confronted with an unfriendly error message.


Taking a look at the essbase log you can see that it is passing in incorrect credentials

Local/ESSBASE0///6972/Error(1051293)
Login fails due to invalid login credentials

Local/ESSBASE0///6972/Warning(1051003)
Error 1051293 processing request [LoginEx] – disconnecting


This doesn’t really provide much information but if you increase the logging levels for essbase then the shared services client security log provides further info.

[EPMCSS-99999] [oracle.EPMCSS.CSS] [tid: 26] [ecid: disabled,0] [SRC_CLASS: com.hyperion.css.facade.impl.CSSAbstractAuthenticator] [SRC_METHOD: getUserDetails] EXITING in [0]ms. RETURNING [essuser, , ldap://orclguid=11cf57e5e5b443378fc36b792d5974b2?USER, , essuser, , 1428403297072, , null|11cf57e5e5b443378fc36b792d5974b2|null|null|null|null|0|null|null|null|,|.|false|null|false|null, BnwdiigC51bzqFwG9zm41VcKutlDmFLun65iUpEpDxk=, ECID:1.fbb32e89d31ed03e:-76dffa80:14c936ca095:-8000-00000000000000b8;kXiClpjg1vC].


As you see it is trying to log in using the orclguid attribute which is the default for Oracle Internet Directory, for Microsoft it should be objectGUID.

There is a simple solution which is actually documented but I wanted to go through the error first.

In the OBIEE web logic domain an additional java system property should be added to the setDomainEnv script.

-Doracle.epm.css.identity.type=fusion


If you are on windows and using a windows service to start up OBIEE then you will also need to add the property into the registry.

Once added and OBIEE managed servers restarted then full SSO should be available from workspace.


There is also an alternative way of achieving the same result and that is by adding a new property to the OBIEE EPM registry.


I would probably stick with the first method though unless you are using a different login attribute to an external directory.

With the long overdue demise of products like Web Analysis and Interactive reporting, OBIEE is now becoming more of the norm for dashboard type reporting with EPM and it is definitely worth considering integrating with workspace.

No comments: