Thursday, September 12, 2013

Basic. Fundamental. Kowledge.

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:

Second one is from Jeff McQuigg on dimensionsal hierarchies and - by extension - the "dreaded" content level tab:

Both of these posts touch on subjects which are the subject of questions about 10 times a week on and ...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".

Thursday, September 5, 2013

Sending OBIEE content to non-OBIEE users through agents

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';

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

Thursday, August 29, 2013

Custom style and skin in OBIEE

When upgrading existing customized installations of OBIEE to, 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+skin package and the vanilla application continues to use a lot of blafp.

Oh yes, /web/app/res also has become /web/appv2/res for some reason or another within Oracle_BI1, so here's what you find in there:

A cursory glance at the folder contents of FusionFX and blafp side-by-side shows quite some differences already:

Whipping out out trusty Firebug and what an out-of-the-box applications actually renders, we see blafp used for the application header:

while we see FusionFX being the source for the dashboards themselves:

As most GUI customizations replace first and foremost the logos in the application header and then moving on to the look & feel of the dashboards and analyses, this logically means that adapting the default FusionFX will only get you halfway to your destination.

What you need to do, in order to have a full and complete basis for your own custom skin, which contains all files and artifacts while retaining the slick FusionFX look (it does look a lot leaner and nicer now), is to merge the two into one package. doing this couldn't be any simpler than this:
1.) clone s_blafp and sk_blafp
2.) copy all the content of s_FusionFX and sk_FusionFX into the respective blafp folders, replacing all existing files

Since FusionFX is a modified subset of blafp, you'll retain all base blafp files and gain the modified and "newer" FusionFX files which supersede blafp.

All you need to do now, is rename the resulting folders...

...push them to the /analyticsRes/ directory (or whatever directory holds the deployment of your custom style and skin), reference it in the instanceconfig.xml and, voila, you've got a complete and fully customizable style and skin package.