New apartment

I moved to a new apartment this past week-end. I’m now closer to DC and my commute time has been cut in half. It only takes me 30 minutes door-to-door. And it costs slightly cheaper too – $5.80 round-trip as opposed to $8 before (bus and metro). It’s also my first time living in a building with concierge and amenities (small gym, sauna, swimming pool, party-room). Parking is still a little uncomfortable in a garage – I’m on the lowest level, and the marks on the walls made me nervous when driving down there first time. There’re a lot of diplomats living in the building, a lot of nice older folks, and I’ve seen young people as well. Everyone seems to be friendly. I can’t wait to get online, but that should happen today (I’m getting FIOS – I think it stands for Fiber Internet Optic Service – which I’ve been happy with at my old place). Please don’t think that this was another blogging slump. Have a wonderful week everyone.

Washington DC, Maryland Virginia OBIEE user group

I’m going to send e-mail now and maybe try to set up a meeting!

There was a comment by Mary in the Training post that made me thinking. There must be some OBIEE people in DC / Maryland / Virginia region who would want to meet each other informally. If you’d be interested in something like this, please leave a comment. If there’re enough people – we could start meeting on a regular basis. I think this would be great for networking as well as for transferring knowledge.

importance of defining dimensional hierarchies

Dimensional modeling is very important in OBIEE. Many mistakes happen because of incorrectly defined time dimension or other dimensions. This service request below is a demo of how an incorrectly defined key in the beginning can block the development efforts in the future.

Overview:
========

Modified rpd and added a new dimension for Key Accounts (Sales.”Key Account”.”Key Acct”) into the Sales subject area . After this change when building a report with Sales.Brand and drillingdown on Brand to show Brand_SKU ( a different dimension throws an error in Answers.

ERROR
===========-
[nQSError: 14020] None of the fact tables are compatible with the query request Brand.Brand.

STEPS
===========
By following these steps the issue can be reproduced:

1. Add dimension called Sales.”Key Account”.”Key Acct into sales subject area in rpd
2. save rpd and checkin changes
3. create answers report with a different dimension Brand.
4. Drilldown on Brand to show the next level “Brand”.”Brand_SKU”.
5. Get the error mentioned above

EXPECTED BEHAVIOR
===========
The report should work fine because the “Brand”.”Brand_SKU” was not modified at all.

Business Impact
===========
This is a very important issue that is holding up all BI projects. You cannot move forward until this issue is fixed.
Cause

The error thrown when drillingdown from Brand to Brand_SKU is caused because of incorrect definition of level keys in your rpd. The issue is, that by definition, a key is the lowest level of a table. Any higher levels are made up of aggregating the lowest or detail level. Since Brand and Product have the same detail key, there should be some consistency between the detail or lowest level of their respective hierarchies. There is not. The lowest level of the Brand hierarchy has a level key of CHILD_KEY_WID. The lowest level of the Product hierarchy has a level key of ‘SKU Nbr’ which is mapped to LVL6_KEY. It seems that the navigator is expecting the same detail key but is not seeing it. This seems to be the cause of the navigation error.

As confirmed by reviewing your rpd inhouse, the level keys are not properly defined for Brand and Product dimensions.
The levels were not defined according to best practices. The document from Engineering that lists the issues in your rpd that dont meet best practice is attached to the SR.
Solution

Please follow these steps in order to fix the error “[nQSError: 14020] None of the fact tables are compatible with the query request Brand.Brand”

1) Open rpd using Admin tool
2) Select BMM layer and delete the current hierarchy created for Brand
3) Make the following change to Product Dimension

–Dimension –Logical File –Physical File
Product Product HSAMI_SKU_DH and
HSAMI_BRAND_SKU_DH

The Product Dimension has two hierarchies, CMDYGRP and BRAND:
ALL
CMDYGRP
COMMODITY
SKU
BRAND
SKU

So now both hierarchies are constructed in one dimension over
one logical dimension table, with multiple phyiscal source tables.

4) Save changes to rpd
5) Test in Answers by creating report with Brand and Product columns
6) Navigation/Drilldown from brand and product should work fine.

OBIEE Training

I decided to write this post after seeing numerous basic OBIEE questions on OTN OBIEE forums. I think people are answering those easy questions (including myself) because of easy points (i noticed that frequently those don’t get assigned) and because of experts’ generosity. Problem is that most of the time, those questions can be easily found using search feature. Moreover, 80% of the time, just searching the documentation would do the trick.

OBIEE has become an attractive career opportunity and numerous course offerings have come out.

I just wanted to warn fellow consultants about some companies promising to make anyone an OBIEE expert in a week. Remember that when something sounds too good to be true – it probably is. OBIEE is a rather complex tool by itself, not only that – one also needs to know about various ETL processes, dimensional modeling, databases and more.

Mark Rittman published a very thorough article on what’s required to be a successful Oracle BI Developer – What Skills Does an Oracle BI Developer Need in 2009? By the way, congratulations on the new US office!

Some of the things he mentioned include OWB and Hyperion Essbase (I realized need to work more on my Hyperion skills – I was putting it away) .There’s no way one can learn those in 1 week.

Again, there’s nothing wrong with training, especially taken from reputable vendors, however, I suggest you conduct a throrough research first.

Also, I don’t want to discourage anyone, but I believe that theoretical training by itself is mostly useless unless followed or accompanied by real-life problems and examples.

Is it possible to use Dashboard Prompts to override Session Variables?

This is a two step process:

1) Tick “enable any user to set variable” checkbox in the RPD for the session variable
2) When you create a dashboard prompt, in the Set Variable list, choose to populate a variable for the dashboard prompt using a server request variable.

If you set a server variable it will override explicitly the value of this variable set via the initialization block.

The variable is changed in the dashboard that uses the prompt( where the variable is set).