OBIEE 18.104.22.168 went GA yesterday and is available for download on OTN here.
Oracle Documentation for 22.214.171.124 is here.
And most importantly the 2 "New Features Guides" in detail:
Leaving some time between the trip home from OOW14 and finishing up the blog post on the 4 official days of the event has had an interesting effect: excellent write-ups of the news and announcements have already popped up, so it's a pleasure to simply link to Mark Rittman's "News and Updates" post for all your needs in that regard.
Session or rather content-wise over these four days there are a couple of things to point out:
Saturday was a rather quiet day. After having spent 2 hours on Friday night, trying to get the connectivity working in my hotel room, Friday started out with another almost 2 hours which culminated on a recabling of the room and replacement modem to finally get things working. After that I was able to put the finishing touches to my presentation.
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 126.96.36.199.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.