Category Archives: Rene Kuipers
Renaming Views in OBIEE 11.1.1.6
Up until version 11.1.1.6, it was not possible to provide custom names for views.
Now we can ! :
Press the red-bracketed button and rename the view !
Now we can ! :
Press the red-bracketed button and rename the view !
First attempt installing OBIEE 11.1.1.6
Oracle released the 11.1.1.6 version of Oracle Business Intelligence Suite just this week. Although on a skiing holiday, I could not resist the urge to download it and install it. The Repository Creation Untility is still there. Please be sure to use the 11.1.1.6 version of the RCU as well ! After kicking off the installer and choosing the Simple Install option, everything is done for you. It's smooth as silk. Unfortunately, the Internal Server Error page is still shown right after the initial startup. But F5-ing after a while shows the well-known login screen. Curious as I am, I wanted to check out the Sample Application. But unfortunately, I ended up with this error message: 
It has probably nothing to do with OBIEE: I'm looking into my browsersettings...
René
Update:
Clearing my browsersettings solved the issue !
It has probably nothing to do with OBIEE: I'm looking into my browsersettings...
René
Update:
Clearing my browsersettings solved the issue !
Update on strange security behaviour
An update, as promised...
Over and over again, this issue is reproducable.
So get rid of underscores and numbers in Application Roles' names and your life will be much more pleasant !
Thanks to everyone in my team (@bifacts, @bvdh80, Cindy and Marcel) for your valuable input in resolving this issue !
Dear followers,
Things seem to go pretty well now.
It looks as if the underscores and numbers in the Application Roles' names cause these kinds of problems.
After having removed the numbers and underscores from the roles' names the error hasn't occurred anymore.
It's a pity that the documentation does not mention this restriction or naming convention.
Still testing though... I'll keep you informed.
René
Over and over again, this issue is reproducable.
So get rid of underscores and numbers in Application Roles' names and your life will be much more pleasant !
Thanks to everyone in my team (@bifacts, @bvdh80, Cindy and Marcel) for your valuable input in resolving this issue !
Dear followers,
Things seem to go pretty well now.
It looks as if the underscores and numbers in the Application Roles' names cause these kinds of problems.
After having removed the numbers and underscores from the roles' names the error hasn't occurred anymore.
It's a pity that the documentation does not mention this restriction or naming convention.
Still testing though... I'll keep you informed.
René
strange security behaviour
Dear community,
I'm writing this because I am facing a serious issue in OBI 11g (11.1.1.5) and I can't seem to pinpoint the exact problem. I hope you can share your thoughts with me in order to come up with a solution. The situation is as follows: There seems to be a mismatch between the Application Roles assigned to a user and the way they are translated onto the ACL's in the webcatalog. I use Weblogic's default Authenticator. Users sit in a group and for every group, there is a corresponding Application Role.
For instance:
There are also A_P020 group and role and a A_P030 group and role. The Group-to-Role mapping is always 1:1.
In the catalog, access to objects is configured using Application Roles.
For instance: access to the P010 Dashboard is limited to users who are member of the A_P010 group (and as a consequence have the A_P010 application role assigned).
Now, what happens is this: a user who is assigned the A_P010 group and the A_P020 group sees the P010 and P020 Dashboards.
When I assign him membership to the A_P030 group too, he only sees the P010 dashboard....
This is reproducable behavior.
resyncing the GUID's didn't solve the problem.
In fact, when I move the webcatalog to a complete fresh installation of OBI 11.1.1.5 and create a new user and assign him the roles as described above, the same behavior occurs.
I'm lost...
The session information (under My Account) shows the correct application roles. It's the mapping onto the ACL's in the webcatalog that seems to be wrong.
Any input would be very much appreciated !
Kind regards,
René
I'm writing this because I am facing a serious issue in OBI 11g (11.1.1.5) and I can't seem to pinpoint the exact problem. I hope you can share your thoughts with me in order to come up with a solution. The situation is as follows: There seems to be a mismatch between the Application Roles assigned to a user and the way they are translated onto the ACL's in the webcatalog. I use Weblogic's default Authenticator. Users sit in a group and for every group, there is a corresponding Application Role.
For instance:
For instance: access to the P010 Dashboard is limited to users who are member of the A_P010 group (and as a consequence have the A_P010 application role assigned).
Now, what happens is this: a user who is assigned the A_P010 group and the A_P020 group sees the P010 and P020 Dashboards.
When I assign him membership to the A_P030 group too, he only sees the P010 dashboard....
This is reproducable behavior.
resyncing the GUID's didn't solve the problem.
In fact, when I move the webcatalog to a complete fresh installation of OBI 11.1.1.5 and create a new user and assign him the roles as described above, the same behavior occurs.
I'm lost...
The session information (under My Account) shows the correct application roles. It's the mapping onto the ACL's in the webcatalog that seems to be wrong.
Any input would be very much appreciated !
Kind regards,
René
OBIEE 11.1.1.3 and 11.1.1.5: different approach to AGO function
Hi again.
After spending some time on the Time Hierarchy in 11.1.1.5 I found it useful to mention that it now is possible to use the AGO function in the BMM layer whilst the underlying logical facttable has multiple sources on different grains.
What I mean is the following:
Let's say in your logical fact table there is a logical measure column called AMOUNT_SOLD. This column maps to two different columns in the physical layer: 1 comes from a table with a day-grain, the other comes from a table with a month-grain. (In cases where you only have a limited set of day-based data and an infinite set of month-based data, this will occur...)
In your BMM layer, the logical fact table has 2 sources: the DAY-based table and the MONTH-based table. When you specify the content correctly for both LTS's, (map them to the corresponding levels in your logical Calendar hierarchy), drilling down on a dashboard from year via quarter to month level causes OBI to query the physical MONTH-based table. Drilling down to the day-detail level, OBI queries the physical DAY-based table. That is, if the logical table for your calendar has a seperate logical source for the DAY level, next to a logical source for the month level and up.
So far, so good.
But, in order to use time-series calculations you would want to use the AGO function in the BMM layer. Something like AGO("Measure","Calendar Level",1).
This does not work in 11.1.1.3, since the logical table for the Calendar has multiple logical sources. (because of the double-source nature of the AMOUNT_SOLD measure)...
Creating a single logical source for the Calendar table does not solve the issue, because now, you're limited to the lowest level of the calendar. Meaning that you wil always query the DAY-based physical table...
In 11.1.1.5 you can combine both.
You CAN use a single logical table source for your calendar and still have 2 physical sources for your AMOUNT_SOLD measure. Specify the correct Calendar level for both individual logical table sources and it works !
Kind regards,
René
After spending some time on the Time Hierarchy in 11.1.1.5 I found it useful to mention that it now is possible to use the AGO function in the BMM layer whilst the underlying logical facttable has multiple sources on different grains.
What I mean is the following:
Let's say in your logical fact table there is a logical measure column called AMOUNT_SOLD. This column maps to two different columns in the physical layer: 1 comes from a table with a day-grain, the other comes from a table with a month-grain. (In cases where you only have a limited set of day-based data and an infinite set of month-based data, this will occur...)
In your BMM layer, the logical fact table has 2 sources: the DAY-based table and the MONTH-based table. When you specify the content correctly for both LTS's, (map them to the corresponding levels in your logical Calendar hierarchy), drilling down on a dashboard from year via quarter to month level causes OBI to query the physical MONTH-based table. Drilling down to the day-detail level, OBI queries the physical DAY-based table. That is, if the logical table for your calendar has a seperate logical source for the DAY level, next to a logical source for the month level and up.
So far, so good.
But, in order to use time-series calculations you would want to use the AGO function in the BMM layer. Something like AGO("Measure","Calendar Level",1).
This does not work in 11.1.1.3, since the logical table for the Calendar has multiple logical sources. (because of the double-source nature of the AMOUNT_SOLD measure)...
Creating a single logical source for the Calendar table does not solve the issue, because now, you're limited to the lowest level of the calendar. Meaning that you wil always query the DAY-based physical table...
In 11.1.1.5 you can combine both.
You CAN use a single logical table source for your calendar and still have 2 physical sources for your AMOUNT_SOLD measure. Specify the correct Calendar level for both individual logical table sources and it works !
Kind regards,
René
