Sometimes it can happen that user profiles within a web catalog become corrupted for any number of reasons. In order for these user profiles to be correctly re-initialized, there's more to be done than just drop /users/JohnDoe from the web catalog.
All in all there are three distinct places which need to be cleaned:
I recently ran into the situation where the primary mount for a Linux tech account running an OBI install was just way too small to get OBIEE 22.214.171.124.140114 through.
Prerequisite check "CheckSystemSpace" failed.
The details are:
Required amount of space(17499.766MB) is not available.
So with a bit of hacking I got around it by displacing the ./patch_storage directory and forcing opatch to stop doing a file system check (basically no "df -h" )
Currently, I'm a happy camper since two blog posts were recently written on absolutely fundamental subjects which for me fall into the category: "Know and understand these concepts or just please don't touch any OBIEE RPD, thanks."
First post is from Andy Rocha over at RittmanMead and concerns LTSs and outer join pruning:
I often get to hear the following question concerning OBIEE agents:
"Why can't we send out personalized content (filtered data / row-level security) to non-OBIEE users by simply using their email address residing in the data?"
Killer answer: Security!
Think about it: If you use "Get Recipients from the Analysis used in the Agent Condition", it will actually perform a complete login with authentication + authorization through the security realm and only the fetch the data.
When upgrading existing customized installations of OBIEE to 126.96.36.199, one thing that you may run into is a subtle change in the usage of the vanilla style and skin of the application.
FusionFX has become the default, but isn't immediately or better directly suited as a basis for your own custom style and skin.
The reason for that is, that FusionFX itself is only a subset of a full style+sin package and the vanilla application continues to use a lot of blafp.
Just a quick note on some security-related things to watch out or during/after an in-place upgrade to OBIEE 188.8.131.52. These were experienced on a 184.108.40.206.3 to 220.127.116.11.0 upgrade on 64bit Linux:
1.) Application Policies:
All custom-created application policies were dropped during the upgrade, leaving only the vanilla ones. Affected file: system-jazn-data.xml.
2.) Application Roles (this one is a bit queerer):
Affected file: system-jazn-data.xml.