Cross drilling! Or in star schema design, otherwise known as “Drilling Across”. This is where you want to report off metrics from 2 or more fact tables in the same report. This is easy when your report is using all conformed dimension attributes. But in most cases, the requirement is for these fact tables’ metrics and some non-conformed dimension attributes.
Row-level security in OBI is a very powerful tool. It is used to limit data seen by users/groups/roles based on a business’s security model. It really is not hard; but, you need to understand when and how data filters will be applied. This is the key that is not documented thoroughly (or that I have seen by searching on the web for clarification). So I did the work to clarify it for you, or I hope I am in this writing. Note: I said it is easy, because once you understand how OBI works in this regard it pretty much is.
OBIA comes with a set of domain values, dependent on the bi app that will be implemented. These domain values are distinct sets of values/codes that act as conformed warehouse code sets. In the sense, that multiple sources can map their codes to warehouse specific codes (source independence); thus, giving the ability to utilize multiple sources with one code set. The OOTB domain value sets are used to create and calculate prepackaged metrics which are used in OOTB reports. Now there are cases where the source data can not be easily mapped to a domain value or the list of available domai
It has been awhile, I think a year now, since my last blog. It has just been a very busy past year. In any event, I came across a problem that involves presentation hierarchy columns. The ever-beloved new feature of 11g , which all users and clients love to use for pretty much all reports.
The issue: How to create a navigational report which will filter the presentation hierarchy column based on the selected record from the calling report? This is otherwise known as report navigation via action links.
During RPD migrations we constantly need to change metadata for the target environment such as physical connection pool(s) and LDAP source(s). To do this manually is time consuming and open for error. Thus, there needs to be a way to script or automate this process. This document will address the automated solution using what is termed in OBI as the patching process.
There seems to always be the occasion where you want to create a report, which will need the use of selection steps to include all the available members; but you want to override the values to keep/use with those of a dashboard prompt. Currently, as of 188.8.131.52, the UI does not make it easy enough to do this. As the Start with all members dialog does not have the Override with prompt checkbox; like, the Start with selected member does. Nor does the Start with selected member option have the ability to specify or check you want all members. So you have
Problem and challenge came up recently to pull and set a multiple value parameter from OVD (or LDAP source) and set session variable (row-wise session variable to be specific) to be used by report writing. Well in OBI 10g, I usually have done that by using my custom LDAP table function to use along with setting row-wise variable(s) in an init block. I looked to see if anything has changed along the lines of accessing LDAP data sources and pulling parameters. There is no problem pulling scalar parameters and mapping them to session variables, only when it is comes to trying to pull multi-
Thought some developers may find this useful and save time trying to work around, fix or look for answers. Users of the latest OBIEE 11g release 184.108.40.206 may get this error going against OLAP source systems.
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A
general error has occurred. [nQSError: 43113] Message returned from OBIS.
[nQSError: 22068] No more than 1 hierarchy from the same dimension Instrument
can be referenced.
The current global go script I have not only produces one ‘go’ button for all prompts on a page; but, it also has code to create required fields and required field validations. The one thing that was brought to my attention was that my current script treated the prompt collective on the page to have dashboard scope. To read about prompt scope, read here. So whether or not you had one or all set for page scope the global go button disregarded and made it act like dashboard scope.
Some may think that the scope of the prompts do not work and are broken; but, they do work and are not broken!