Why do we need security in OBIEE?

This is a rather very basic question but to them who have just started working on OBIEE, this is very  important to understand. OBIEE is a reporting tool wherein multiple users belonging to multiple groups create multiple reports and dashboards. Reports created by a particular group of users should be visible to that particular group only or some specific data should be visible to only a specific set of people. So, to achieve this we need to have some sort of security in place using which we can protect reports belonging to a group of users from the users of other groups.

Users and groups in OBIEE?

End users who make use of OBIEE for reporting need to be defined somewhere. These users can be defined either in the OBIEE RPD, External database tables, LDAP Servers or in Active directories with their respective passwords.

The users belonging to same business unit can be clubbed and Groups can be created for them. Its not always necessary to create users in the RPD  but its necessary to create the groups in the RPD. Infact, creating several users in the RPD can be a cumbersome job and it will also increase the size of the RPD, so, according to the best practice create the users and groups on the DB(or add in AD/LDAP) and associate them with the RPD groups by creating groups of the same name on the RPD as in DB.

Authentication and Authorization?

Authentication means validating the user while logging in the OBIEE application. When a user logs in the OBIEE application a request is sent to the BI Server asking that whether this user is a valid user or not. When BI Server validates the user then only the user is able to login in the application.

Authorization means a user is authorized to view what all objects. Example, User A might be authorized to view only particular set of reports and dashboards based on the security applied.

Types of Security in OBIEE?

There are basically 2 types of security in OBIEE:

1. Object Level Security
2. Data Level Security

Lets understand these terms in detail.

Object Level Security:

As the name states, Object level security refers to restricting access to OBIEE objects between different users and groups. The access to following objects can be restricted using object level security: Presentation tables, Presentation table columns, Subject Areas, Reports, Dashboards, Project Specific shared folders.

Data Level Security:

Data Level Security is basically securing the data. Users belonging to particular group should see a certain set a data whereas users outside that groups shouldn’t see that data. Example: Users belonging to Asia group should see only the data for Asia region whereas users belonging to US region should see data for US region.

 I have tried to give a brief overview of Security in OBIEE. In the upcoming posts we will learn more about it.

Till then keep posting!!!

We can change connection pool properties like DSN, username and password dynamically by using URL or passing value through URL. I used the same for changing the Database connections dynamically from which my reports were being generated.

This requires making changes in RPD and instanceconfig.XML. The steps for the same are listed below:

Step 1

Create a Session Init block called ‘Populatevar’ as shown below to populate a session variable ‘Var’.

“Select 0 from dual“ will always give the result 0 which will act as the default value for ‘Var’. This variable will be used to store the value that we will be passing through URL.  Please make sure to check the checkbox “Enable any user to set the value” as this will allow the users to set the value of this Session Variable from the URL.

Step 2

Create a table in database eg: Table A with following columns:

(Note: It’s not a best practice to store passwords in database)

Step 3

Create a Session Init block ‘ENVVAR’(as shown below) to populate PROJECT_DSN, PROJECT_USER and PROJECT_PWD variables using the above TableA. These 3 variables will store the values required to login into the database.

Set the default values for the variables PROJECT_DSN as DB1, PROJECT_USER as USER and PROJECT_PWD as XYZ. This is required so as to ensure that the default values get picked up when Init blocks are not fired. Always set the defaults to the default database connections from which you want the users to run the reports.

Step4

Change connection pool details as below:

Data source name: VALUEOF(NQSESSION.PROJECT_DSN)

User name:  VALUEOF(NQSESSION.PROJECT_USER)

Password: VALUEOF(NQSESSION.PROJECT_PWD)

Step 5

Add following entries in the instanceconfig.xml file:

<ParamList> <!–  IMPERSONATE param is used to get the authenticated user.s username and is required –>

<Param name=”NQ_SESSION.Var” source=”url” nameInSource=”DB” /> </ParamList>

The above tag is used to pass the database ID present in URL to ‘Var’ session variable.

Step6

Now, construct your links like the ones shown below and it will dynamically pick source db details according to DB value.

• http://test50656:9704/analytics/saw.dll?Dashboard&DB=2
• http://test50656:9704/analytics/saw.dll?Dashboard&DB=3

How exactly it works???

The entire idea behind this approach is to make use of Session variables in connection pools and then initialize the session variables to change the database connection by passing values through URL.

Now, when a user tries to login using a URL with a specific database id, the Session Variable “Var” will be initialized with the value which was passed from the URL.

Then, the value of the “Var” Session variable will be used in the Init Block ENVVAR through the below query:

select SCHEMA_NAME, DSN_NAME, SCHEMA_PWORD from TableA WHERE ENV_ID =  TO_NUMBER(VALUEOF(NQ_SESSION.Var))

The above query will assign values of SCHEMA_NAME, DSN_NAME and SCHEMA_PWORD fetched from TableA to the variables associated with the ENVVAR Init block i.e. PROJECT_USER will be assigned value from SCHEMA_NAME, PROJECT_DSN will be assigned value from DSN_NAME and PROJECT_PWD will be assigned value from SCHEMA_PWORD.

These Session variables will then be used in a connection pool to connect to the database.

The values of these Session variables can be changed based on the database id passed from the URL and hence the connectivity to the database can be changed.

Here I am with a new post and a rather interesting one. In this post we will understand that how can we actually assign values dynamically to session variables and how these variables can be further used in data level security implementation.

Before starting with this, we also have to understand the concepts of Session Variables and Row-wise initialization as they act as the baseline for this approach.
What is a Session Variable?

A Session variable is a variable which stores the values fetched from the initialization block and it gets initialized when a new session starts. Whenever, a user starts a session, OBIEE server creates a new instance of the session variable and initialize it with a value. This value is retained in the Session Variable till the session ends.

What is Row-wise Initialization?

As per what the name suggests, Row-wise initialization feature allows you to assign a list of values(present in some database table) to a single session variable. It also allows you to create multiple session variables dynamically and set their values when the session starts. This feature is present in the Session Variable initialization block in the RPD and is used to initialize a variable. The Session variable initialization blocks run for every new session created.

How to create Row-wise Session Variables?

Row-wise Session variables are dynamic session variables which are created dynamically when the Session Variable initialization block initializes. Below examples shows how to create Row-wise Session variable dynamically.

Example 1- Create multiple dynamic session variables and initialize them with values

In the RPD,  under variables, create a new Session Variable Init Block ‘Test’ with the following query-

Select ’1′,’RJ’ FROM DUAL UNION Select ’2′,’SJ’ FROM DUAL

Then, assign a connection pool to the init block and set the Variable Target as Row-wise Initialization.

Now, when this session variable init block will run, it will create 2 dynamic session variables ’1′ and ’2′ with the values ‘RJ’ and ‘SJ’. Below images show how to display the same in Answers:

Diag1                                                                                                                          Diag2

Example 2- Create single Session variable and initialize it with multiple values

This technique is generally used to assign multiple security groups to a single user while implementing Data Level Security. The below example shows how assigning multiple values to a single session variable can used in implementing Data Level Security:

Create a Session variable Init block named ‘Test1′ and add the below query.

Select ‘VAR’,'VAR1′ FROM DUAL UNION Select ‘VAR’,'VAR2′ FROM DUAL

This will assign values ‘VAR1′ and ‘VAR2′ to dynamic Session variable ‘VAR’ and when we will test this Init block, the result will be displayed in multiple rows. like:

Create another Session Variable Init block named ‘Test3′  and add the below query in that. Then, assign this Session Variable Init block to a variable ‘NEW’:

Select ‘VALUEOF(NQ_SESSION.VAR)’ FROM DUAL

Now, the point to note here is that, in previous scenarios we haven’t assigned the Init block a variable but in this scenario we are doing it. This is required because, since, we have to assign multiple groups to a single user, we should get the data in a single row instead of multiple rows. So, assigning the ‘Test3′ Init block to a variable ‘NEW’ and fetching the values of ‘VAR’ session variable in the query will bring the data in a single row in the ‘NEW’ session variable. The same can be seen in the below images:

So, the above images show that when we test the Session Variable Init block ‘Test3′ the values ‘VAR1′ and ‘VAR2′ are stored in the Session variable ‘NEW’ in a single row. The other image shows that the same can be used and displayed in answers.

This variable then can be further used for Data Level Security as filters can be applied on users and groups in RPD based on this variable. And this is how we make use of Row-wise initialization for Data Level Security.

Questions and comments are invited….

Today’s topic is a rather common one and could be found on most of the blogs. After a long time, I again implemented the same so thought of sharing it with all.

Most of the BI projects have numerous dashboards and the business owners want them to get displayed in a list form such that all the related dashboards(present under same shared folder in catalog) should be showed under one link. This can be achieved by changing some configuration in the instanceconfig.xml file located in the folder <OracleBIData>\web\config\.

Stop the Presentation services and add the below tag in the instanceconfig.xml file:

<DashboardMaxBeforeMenu>2</DashboardMaxBeforeMenu>

and restart the Presentation services.

This tag will change the existing dashboard display and will list the dashboards present in single shared folder under one link.

Hope this helps.

I have got a number of requests to write on this topic, so here I am with Level Based Measures in OBIEE. As usual to start with lets understand what does this mean and how is it created in OBIEE.

What are Level Based Measures?

For all my new readers I would like to first explain what is a Measure. A Measure is any measurable entity and aggregation functions can be applied on them. In other words any entity which is  viewed/compared with respect to dimension columns is a measure. eg: Total Sales, Dollar Amount are measures which can be viewed against Time, Region Dimensions.

Now, Level Based Measures as their name state are calculated at a particular level. It can be better understood with the following example:

Lets assume there is a company ABC which has its Sales extended in many  regions, countries and cities. Now, the CEO of the company wants to see the Total Sales at Country Level(Western Region has US and Canada as countries) i.e. one level below Region and one level above Cities. So, here our measure Sales has to be summed up to the Country level. Similarly, the same Sales measure can be viewed against Time Dimension at any particular level. Eg: Quarterly Sales.

These type of measures are called the Level Based Measures.

How are Level Based Measures created?

Before understanding how is it created we have to understand the concept of Dimension Hierarchies.

A Dimension Hierarchy is basically a drilldown(from top to detail) of a dimensional attribute. As explained in my previous example (company ABC), while analyzing Total Sales against Region Dimension we saw three levels of Region Dimension, the topmost level was Region, the second was Country and the last was City.  These 3 levels will become the levels of our Dimension Hierarchy across which the Total Sales can be viewed. Similarly, the Time Dimension can have Total, Year, Quarter, Month and Date as its levels.

The Dimension Hierarchy is created in the BMM Layer in the OBIEE RPD and based on it we can decide at which level of a particular dimension do we actually need to see the measure.

Now again coming back to our question How are Level Based Measures Created. Once the Time Dimension Hierarchy is created, we need to set the content level of the Total Sales measure to a particular level(present in the Time Dim Hierarchy) to make it a Level Based Measure. This can be done by double clicking on the Total Sales column and then setting the level in the Levels tab. The setting of content level can be better explained by the below image.

How do Level Based Measures Work?

When we dont set any level in the RPD for Total Sales measure and create a report with columns Per Name Year and Total Sales, we get the below output. The Total Sales is aggregated at the Year level.

But after setting the content level at Month in the RPD, if we run the report, then the report will show the Total Sales at Month level and the data doesn’t get aggregated at the Year Level. In the below image you can see 12 records for year 2008.

 Another interesting thing to note with Level Based Measures is that when we drill below the Month Level in the report, the values for corresponding measure keeps on repeating, restricting the users drilling capabilities below Month Level. This can be understood by the below images.

 The above image shows the drill from year to month level. Please note that the Total Sales corresponding to Per Name Month 2008/01 is 43810.

 The above image shows the drill from Month Level to the Week Level. But the values for Total Sales column remain the same as in the previous image even after drilling to a lower level restricting the users from viewing the detail data.

This can also be used for security restricting the inappropriate users from viewing the detail data.

 This is all about the Level Based Measures. I hope it helps you to understand the basic logic behind using them.

Please let me know your feedback and keep posting…

I think most of you must be familiar with the term MUDE in OBIEE and for those who aren’t, its Multi User Development Environment.

It is a very commonly used technique while development but still I am writing this post here because some people still dont know how can we make use of it. MUDE in OBIEE is a very useful technique for the Dev Teams. As the name states, by using MUDE “Multiple users can work on the RPD simultaneously“.

How does it work??

Say for example, 3 people are working in a team and all 3 have to work on the same RPD and make some changes to it. In normal scenerio, one will start working and other 2 have to wait until the first person completes his work. This is a time consuming and inefficient process. Whereas, using MUDE all 3 can work on the same RPD simultaneously by checking out the objects, making changes to them and checking them back in to the Master Repository.

An important concept to understand here is ‘Creating Projects in RPD‘ . We need to create Projects in the RPD because the entire MUDE process revolves around checking out Projects and checking them back in the RPD by the users.

The checkout and checkin process works by using the concept of Master and Local copies of the RPD. When a person checks out a project in RPD in MUDE mode, a Local copy of the RPD is created on the machine on which that person is working. The Master copy remains intact until the changes are merged with the Local changes and published on the network. We will understand the detailed process while moving ahead.

Implementation??

Implementation is very simple. We need to follow the below steps:

1) The first thing that we need to do in RPD is to create projects(assuming that the tables are imported in Physical layer and BMM layer is setup accordingly). Go to Manage>Projects and create a new projects.

Projects are nothing but a grouping of one or more than one Logical Fact Tables. These projects need to be created so that users working on different Logical Fact tables can be assigned different projects.

2) Setup a shared directory where the Master RPD will be placed. Copy the Master RPD into the directory.

3) In the RPD go to Options>Multiuser and set the path of the shared drive(created in step 1 above) in Multiuser Development Directory. The same thing should be done on all the systems using the MUDE.

4) Now open the Admin tool on your system and go to File>Multiuser and then select Checkout. A list of projects on which you have permissions will be visible to you. Select the Project(containing Logical fact table) on which you have to work. This will checkout the Project and will create 2 RPDs on your system in Repository folder. One is the subset.rpd, containing the extracted project and other is the originalsubset.rpd which is the original copy of the RPD.

5) Once the project is checked out, you can make your changes to the underlying objects.

6) Now, to checkin your changes, go to File>Multiuser>Merge Local Changes. Now, as and when you try to Merge Local Changes with the Master RPD, a lock is placed on the master RPD. This is to ensure the version control and to prevent the code overwrites while merging. A screen will popup which will show you the lock information and you can enter your change details into it (functionality of typical version control tool). The lock prevents other users from checking in their changes and also view changes made by you.

7)  When we merge the local RPD with Master RPD a merge screen will appear. Normally, in case of no conflicts, it merges automatically. But, in case of conflicts with other users, you manually have to resolve the conflicts.

8 ) Now, to release the lock from the Master RPD you have to Publish your changes on the network. When we Publish the changes on the network. The local copy of the Master RPD will be copied to the shared drive and the lock will be removed. Also, the local copy will be deleted from the Repository folder after publishing the changes.

After this 2 excel log files will be generated, one in your local folder and other in the shared drive. These will contain the information about the merge process.

Advantages??

• Useful and efficient development technique.
• Saves time and allows many people to work on the same RPD at the same time.
• Version control and merge is handled by OBIEE itself.

This is how the MUD actually works in OBIEE. I hope it will be helpful for all my readers and also will prove an efficient development methodology.

Table of contents for Clear Prompts

1. Refresh Prompts while navigating Dashboard Pages
2. Refresh Prompts while navigating Dashboard Pages-1

Hi Friends,

Sometime back I posted about clearing the prompts while navigating between the Dashboard pages. In that post I mentioned about modifying the instanceconfig file and adding the below tag :

<PersistPageState>FALSE</PersistPageState>

The only drawback with the above method is that it has an Application wide impact. This means that once we update the instanceconfig file, it will be applicable to all the dashboards accross the application.

Sometimes, there are requirements where in we have multiple Dashboards in an application and in some Dashboards users want the prompts to be cleared while navigating between the pages whereas in others, users want the prompt values to persist. To cater such scenerios, we can make use of the below alternative.

Requirement: I have 2 Dashboard Pages, Page 2 and Page 3. I have selected a value in the prompt on Page 3. Now, when I navigate to Page 2 and navigate back to Page 3, I want my prompts to be clear.

It can be implemented as below:

1) Create Page 3 with prompt and report.

2)  Create a link on Page 2 by using “Link or Image” dashboard object. This link should navigate to Page 3 i.e. the destination should be entered as Page 3.

3) Now, select a value in Prompt on Page 3 and click GO. This will set the selected value in Prompt.

4)  Navigate to Page 2 from Page 3. This can also be done using a link but I am not covering the same in this example.

5) Navigate back to Page 3 by clicking the Link on Page 2.  

You will see that the prompts on Page 3 are cleared.

The above approach can be used for clearing the prompts while navigating between the dashboard pages. It is a rather simple approach but might be useful for some of you.

Few days back I got a requirement from one of my friends according to which he wanted to have the value of  Presentation Variable(selected from prompt) being passed amongst the underlying Multi Select prompts on the Dashboard.

Requirement:

Each national Promotion have NP Relase date and NP End date ,so, the requirement is to show the National Promotion in Multi Selector which the NP Relase date or NP End date between the Start date and End date (selected promt values).

Requirement

I think the above requirement can be achieved in Dropdown prompts but not in the case of Multi Select Prompts.

Any help or suggestions regarding this will be appreciated.

Thanks

Sometime back I was under the impression that the Java Host server is only used for displaying Charts,Graphs and all those flashy images, but, after the below incident I found one more usage of the Java Host server.

Today, I had a requirement to create some reports in BI Publisher. When I logged in to OBIEE and tried to access BI Publisher from More Products then I got the below error:

“An error occurred during execution of “connect“. No connection could be made because the target machine actively refused it”

I was amazed when I got this idiotic error as I just did a fresh OBIEE install. Another interesting thing was that I was able to access the BI Publisher Standalone application and was able to login into the application successfully.

When I read the error, it said ‘target machine refused to connect’ which meant the server is shut down but that was not the case as I was able to login in standalone application. So, this thing brought up more confusions.

After all this confusion, I went and checked all the servers and found that except Java Host server all the servers were started. So, just as a trial I started the Java Host Server and to my surprize my problem got resolved.

I think this post might not be that helpful for some people but it can avoid you from wasting some time.

Table of contents for Architecture

1. Insight of OBIEE Architecture
2. Insight of OBIEE Architecture-II
3. Insight of OBIEE Architecture-III
4. Insight of OBIEE Architecture-IV

Hey Friends,

We have been discussing the OBIEE Architecture and we have covered 3 segments. So, here I am with the 4th segment DataSources.

This is a rather simple one as we all know till now that OBIEE is a reporting tool and works on data from  underlying Databases, so here DataSources are the underlying Databases with which the OBIEE server interacts. OBIEE is a very smart tool and it has got the capability of reporting on multiple Databases and also multiple types of Databases like XML, Oracle, SQL Server etc.

Now, in the previous posts you have seen what is an OBIEE Repository and what is the Physical Layer and what are connection pools. I am reminding you of these things because our current segment is based on this and we will see how.

Now, when we design the OBIEE Metadata or repository for reporting, we import the tables on which we need to perform reporting into the physical layer from the respective DBs. And then we apply appropriate joins between the tables and furthur pull them to BMM and then to Presentation Layer for reporting.

 The question that comes out here is “How does the BI Server interacts with the underlying DBs for showing the reports???”

The answer to this question lies in the Connection Pools. If we open the Connection Pool we can see that we need to select the Call Interface, give the name of the DSN, give a Username and password. These things help up to connect to the Database.

Call Interface – There is a drop down from where we can select the appropriate Call Interface. Some examples are ODBC, OCI etc. Both ODBC and OCI can be used for Oracle. The main difference between using them is, In ODBC we need to create a DSN in the system where the server is installed but OCI is a native DSN and we can use it directly without creating the DSN in the system.

DSN- This is the name of the DSN which OBIEE uses to connect to the underlying DB.

Username- The user with which OBIEE connects the DB. Generally the user used for reporting should only have the read priviledges on the DB.

Password- Password of the user with which OBIEE connects to the DB.

 Now, when a user runs the report in Answers the OBIEE server accesses the DB using the connection pool with the specified Call Interface and username and returns the data.

The next question is “How does the BI server takes care of a report formed using columns and tables from multiple DBs???”

As I have told you earlier also that BI server is very intellegent and is built in such a way that it can process request formed form multiple DBs. When the user generates a report involving multiple DBs, the request navigates to the Navigator section in the BI Server which checks the underlying DBs with which OBIEE needs to interact to. Then the BI server generates separate queries for the DBs and fire them on the respective DBs. Then it fetches the data from the underlying DBs and combines the result set in its own memory and displays the result in the report.

With this post we have covered the 4 segments of the OBIEE Architecture. I hope this will help you alot in understanding the BI Architecture and also in understanding the OBIEE behaviour. In the upcoming posts I will also try to go into the details and throw some more light on the BI Server components.

Till then Keep Posting….