Uncategorized

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:
http://www.rittmanmead.com/2013/09/outer-join-lts-pruning-its-here/

Second one is from Jeff McQuigg on dimensionsal hierarchies and – by extension – the “dreaded” content level tab:
http://greatobi.wordpress.com/2013/09/10/the-single-most-important-thing-to-know-about-the-obi-rpd/

Both of these posts touch on subjects which are the subject of questions about 10 times a week on forums.oracle.com and comunities.oracle.com …each!
LTS modelling (one vs several), non-conformed dimensionalities in business models (leading to nQSError: 14025 and his buddies) and all the other beautiful and powerful options that the RPD gives you are still amongst the least understood subjects.

These are basics which must be understood. Comprehension is mandatory! Not just slavish adherence to “best practice guides” or “replicating what the guy before you did”.

Uncategorized

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.

Now imagine that you bypass this “because it’s so convenient to just have the email in the data”. And now imagine me doing this:

update MYTABLE set EMAIL = ‘uber.h4xx0r@somenastyplace.thief’;
commit;

I think this should be answer enough as to why you do NOT want to be able to do this.
At all.