John Goodwin walks through integrating OBIEE 188.8.131.52 with a EPM 184.108.40.206 environment using Oracle as the database repository...
It wasn't so long ago I wrote a post about integrating EPM 220.127.116.11 workspace with OBIEE 18.104.22.168, now with the recent release of OBIEE 22.214.171.124 I have to keep up the tradition and test out if the integration is still working, if I don’t then I will just get asked the question so I thought I would get there before it gets asked.
Once again I am not going to go into too much detail because I have covered it all before and you can read about it in the following blogs:
OBIEE 126.96.36.199 integration with EPM 188.8.131.52
OBIEE 184.108.40.206 integration with EPM 220.127.116.11
Issues with OBIEE/Workspace when using SQL Server
EPM 18.104.22.168 workspace integration with OBIEE
For the integration I am going using a clean install of OBIEE 22.214.171.124 with a EPM 126.96.36.199 environment and using Oracle as the database repository.
The Oracle OBIEE documentation covering the integration has not changed from 188.8.131.52 so I am assume the process much be the same and here is a high level walk through of the steps, if you want further information check out my previous blogs.
Configure same MSAD configuration in EPM Shared Services and OBIEE WebLogic Admin Server
I didn't think I would get stuck at the first step as I have never head issues before but I got stalled at hooking up OBIEE to the AD, it wasn't a problem with the configuration as both EPM and OBIEE were configured exactly the same as in previous versions.
There were no problems returning the users in Shared services or logging in with an AD user.
Both the WebLogic Admin console and Enterprise Manager were returning the AD users and I could log into both using an AD user.
The problem was logging into OBIEE with an AD user, it would just fail and in the logs complain about the user not being found in the identity store.
After wasting too much time I noticed the following in the issues list in the documentation which I wasn’t expecting:
1.4.38 Authentication Fails Against Third Party LDAP When Virtualize is Set to True
Impacted Releases: 184.108.40.206
When using Microsoft Active Directory as the Identity Store and also using the virtualize=true option, users are unable to login to Oracle Business Intelligence. This relates to Bug 20188679 - authentication fails against 3rd party ldap when virtualize=true set. Customers should check the availability of a patch for this issue on their installation platform before continuing to upgrade to 220.127.116.11.0.
This was exactly my issue and I would say it is quite a serious bug because it is so widely used.
At the time I first tested this out there was no patch available so I used a workaround but now the patch is available.
Fortunately applying the patch resolved the issue so on with the next steps.
Update reg.properties with version from EPM environment
Copy css.jar, interop-sdk.jar and registry-api.jar from 18.104.22.168 EPM environment to equivalent OBIEE environment locations
I questioned whether this would be still required, I thought the files in OBIEE 22.214.171.124 might been updated to match EPM 126.96.36.199.
Not so lucky, looking at the version of the files in the OBIEE instance highlights this:
The files have not been updated since EPM 188.8.131.52, not sure why they have not been updated but I suppose it depends on which version of workspace you intend integrating with.
Well it answers the question, you still need to copy the files across.
On to the next step.
Run utility to share encryption key between EPM and OBIEE
No problems there.
Remove applicationID from OBIEE EPM registry
Use the EPM system registry tool to do this.
Registry OBIEE in workspace by updating registration.properties and running HSSRegistration register
The properties file requires updating with information to the EPM instance, run the utility to register.
Run EPM configure web server to add in OBIEE proxy information.
Proxy information added to the OHS configuration file.
At this point the OBIEE menus should be available in workspace and provisioning available in Shared Services, please note that the provisioning is only to provide access to users to the OBIEE menus in workspace and is totally separate to OBIEE provisioning.
Enable SSO authentication using fusion middleware control
Enable SSO, apply and activate changes.
Update instanceconfig.xml to add the HyperionCSS authentication schema
Update bridgeconfig.properties to enable Hyperion CSS authentication.
Restart EPM and OBIEE, provision AD user in Shared Services with OBIEE roles.
Tested logging into workspace with newly provisioned user
Good sign the OBIEE menus were available.
No problems then the single sign is working as expected.
If you are intending to use Essbase, HFM or Planning as data sources in OBIEE and want to use single sign on then set SSO in the connection pools.
The following Java system property requires adding to the setDomainEnv script