Tuesday, July 29, 2014

THINK and UNDERSTAND before you give "advice"


One tag. Rant.

Every now and then when I'm on the OTN forums, I run into gems like this: https://community.oracle.com/thread/3589607

The problem isn't the question - it's the "answer" which is both mind-blowingly wrong on so many levels and ends with the usual childish "Gimme points, I crave attention!" footer. I'm not going to go into details on the technical solution since that's covered in my response to the thread itself, but let me just make one thing clear:

Use content from a presentation like Jeff's without thinking just to - wrongly - "prove" your point and you will tick me off. Seriously.

Why did Jeff include the 1=1 join option? Did you see that it was an option and not the ultimate answer ® ? Do you even know what a content level is?

< / rant >

Wednesday, March 19, 2014

Purging corrupted OBIEE web catalog users

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:
  • /users/JohnDoe
  • /system/users/123456
  • /system/acocuntids/987654
This is really important since especially the third place contains the translation between the userid and the effective GUID of the user. I've written a little script which takes the absolute path to the web catalog in question as well as the user to be purged and kills everything that's necessary.

NOTE: This is a quick&dirty solution and I haven't fool-proofed it with any check like "does the folder exist" etc. so use it cautiously and on your own risk.

I may get around to rendering it safer later-on, but since I was asked for it once more just today I thought I'd put it out there.


#!/bin/bash
#
# Purpose: Completely purge a named user from the web catalog with all his content.
#
# Requires absolute path to webcat as param 1 and user name as param 2
#
#
# Author: Christian Berg
# Initial creation: 28/01/2014
# Absolutely no warranty, use at your own risk
# Please include this header in any copy or reuse of the script you make
#
# Current version: 1.0
#
# Change log:
#        CBERG 28/01/2014 Intial creation
#


########################################################################################
# Step 1: Kill the users personal folder plus content with its accompagning .atr       #
########################################################################################

cd $1/root/users

find -type d -name $2 | xargs rm -rf
find -name $2.atr | xargs rm -f

########################################################################################
# Step 2: Kill the users entries in /system/users                                      #
# Two files will be affected "username" and "username.atr"                             #
# Removal happens one-by-one                                                           #
########################################################################################

cd $1/root/system/security/users

find -name $2 | xargs rm -f
find -name $2.atr | xargs rm -f

########################################################################################
# Step 3: Kill the users entries in /system/accountids                                 #
# Two files will be affected. Accountids contains the translation from GUID to         #
# username, so the actual username resides within the files content rather than its    #
# name. Bulk removal.                                                                  #
########################################################################################

cd $1/root/system/security/accountids

grep -r -l $2 . | xargs rm -f

echo User $2 has been purged from the web catalog.

exit 0

Thursday, February 27, 2014

Working around opatch - Prerequisite check "CheckSystemSpace" failed.

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 11.1.1.7.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" )

1.) displace ./patch_storage to a mount with enough space (but keep a backup in place just in case...)
cp -r /FMWH/Oracle_BI1/.patch_storage /data/NASmnt00001/

mv /FMWH/Oracle_BI1/.patch_storage_bkp


2.) create a symbolic link to take the place of ./patch_storage
ls -s /data/NASmnt00001/.patch_storage ./.patch_storage
After this step if you execute opatch normally, it will still fail with "CheckSystemSpace" failed.


3.) Have opatch omit the space check:

opatch napply -silent /data/NASmnt00001/11.1.1.7.140114 -id 16569379,16913445,16997936,17300045,17300417,17922352,17922552,17922577,17922596 OPatch.SKIP_VERIFY_SPACE=true

Done.

(h/t @G_Ceresa for being picky and getting on my nerves with "That's not proper." ... I said it's a hack, mate ;-))

Tuesday, January 21, 2014

How-To: File hunt for OBIEE GUI changes

Among the questions I receive and that frequently come up on OTN, treated in blog posts etc. are questions pertaining to: How do I change a part of the GUI of OBIEE? Now in this post you'll find the answer to that specific question, but the point here today isn't simply to say "do X in Y", but rather "how do you get to know that you need to change X in Y?".

Mind you, I'm doing these changes quick and dirty to make them instantly visible. The proper way is to create and deploy your own style + skin package within which you do those changes (or alternative post over at my buddies at RittmanMead as well as my own one)!

The single most important things when working with anything relating to the GUI is: Firefox with Firebug (or Internet Explorer with F12 Developer Tools)

The target is to move the image in the title view to the right of the actual title text.


In order to understand what actually needs to be touched in terms of files you right-click on the logo and choose "Inspect Element with Firebug".


This will show you the detailed information on the object within the HTML with its style inheritance through the CSS and all the bits you need to dig further.


In this case you see that the table class is "TitleTable" (the two tr's you see inside are once the logo and once the title text). In order to find the file which controls this, do a search within the vanilla msgdb folder. In this example I'm using the SampleApp v309:


"viewmessages.xml" can be disregarded since it doesn't figure in the actual rendering process, but "standardviewtemplates.xml" is the one we really want.


Now that may look a bit unreadable at first glance, but following the Firebug output above, one can quickly see how the XML controls GUI generation by matching the standardviewtemplates.xml content with the page HTML:

 

Once this matching is done, you can use an editor like Notepad++ to clean the XML (indent, highlight, collapsible etc) to make the standardviewtemplates.xml more readable and manageable.
Target now is to switch the positions of the title logo and the title text, but the logo before the help icon since the help "?" should still be at the far right-hand side.
So a switch of the two respective "sawm:if name=..." is necessary...


...in order to get to a situation where the sawm:if's are in the order desired: title, logo and then help:


In my case I overwrite the existing central (vanilla) standardviewtemplates.xml with the modified version, but as said initially, I strongly suggest that all such changes should be done in custom style+skin packages!

After a bounce of the presentation server service the modified GUI is up and ready:


Cheers!

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:
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".

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


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 11.1.1.7

When upgrading existing customized installations of OBIEE to 11.1.1.7, 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 11.1.1.7 style and skin package.