Compare features in OBIEE 10g and 11g

Hi friends,Thanks for the support you provided for my Differences Between Oracle 10g and 11g and Differences between OBIEE 10g and 11g security models? post.Here I am posting the difference in features available in OBIEE 10g and OBIEE 11g.When we compare OBIEE 10g and OBIEE 11g, there is lot of enhancements in services provided by OBIEE 11g and some changes in terminology is also there in OBIEE 11g.

Some important points/enhancements in OBIEE 11g when compared to OBIEE 10g are listed below

1. OBIEE 11g uses WebLogic Server as the application server as compared to Oracle AS or OC4J in OBIEE 10g.

2. The clustering process in much easier and automated in OBIEE 11g.

3. We can now model lookup tables in the repository.

4. The new UI called Unified Framework now combines Answers, Dashboards, and Delivers.

5. A new column called the hierarchical column in introduced.

6. BI Publishers is fully and seamlessly integrated with OBIEE 11g.

7. New time series functions PERIOD ROLLING and AGGREGATE AT are introduced.

8. In OBIEE 11g we can create KPIs to represent business metrics.

9. The aggregate persistence wizard creates indexes automatically.

10. The session variables get initialized when they are actually used in OBIEE 11g unlike OBIEE 10g where they were initialized as soon as a user logs in.

11. OBIEE 11g now supports Ragged (Unbalanced) and Skipped Hierarchy.

12. You can also define Parent-Child hierarchy in OBIEE 11g as well.

13. SELECT_PHYSICAL command is supported in OBIEE 11g.

In OBIEE 11g there are some changes in the terminology as well.

iBots are renamed as Agents. Requests are renamed as Analyses.

Charts are renamed as Graphs.

Presentation Columns are renamed as Attribute Columns.

Explain about the Types of Hierarchies in OBIEE with example.

A hierarchy is a cascaded series of many-to-one relationships and consists of different levels.  Example, a region hierarchy is defined with the levels Region, State, and City

Types of Hierarchies1. Balanced hierarchy2. Unbalanced hierarchy3. Ragged hierarchy

1. Balanced hierarchyA balanced hierarchy is one in which all of the dimension branches have the same number of levels. In other words, the branches have a consistent depth. The logical parent of a level is directly above it.A balanced hierarchy can represent a date where the meaning and depth of each level, such as Year, Quarter, and Month, are consistent.

 2. Unbalanced hierarchyA hierarchy is unbalanced if it has dimension branches containing varying numbers of levels.An unbalanced hierarchy has levels that have a consistent parent-child relationship, but have a logically inconsistent level. The hierarchy branches also can have inconsistent depths. An unbalanced hierarchy can represent an organization chart.

3. Ragged hierarchyA ragged dimension contains at least one member whose parent belongs to a hierarchy that is more than one level above the child. Ragged dimensions, therefore, contain branches with varying depths.A ragged hierarchy is one in which each level has a consistent meaning, but the branches have inconsistent depths.A ragged hierarchy can represent a geographic hierarchy in which the meaning of each level, such as city or country, is used consistently, but the depth of the hierarchy varies.

Dimension Hierarchies in OBIEE:Level-Based Hierarchy and Parent-Child Hierarchy

A hierarchy is a cascaded series of many-to-one relationships and consists of different levels.                                                  Example, a region hierarchy is defined with the levels Region, State, and City.In the Business Model and Mapping layer, a dimension object represents a hierarchical organization of logical columns (attributes). One or more logical dimension tables can be associated with at most one dimension object. Common dimensions might be time periods, products, markets, customers, suppliers, promotion conditions, raw materials, manufacturing plants, transportation methods,

media types, and time of day. Note that dimensions exist in the Business Model and Mapping (logical) layer and in the Presentation layer.There are two types of logical dimensions:

1.       Dimensions with level-based hierarchies (structure hierarchies).2.       Dimensions with parent-child hierarchies (value hierarchies).

Level-based hierarchies are those in which members are of several types, and members of the same type occur only at a single level. In parent-child hierarchies, members all have the same type. Oracle Business Intelligence also supports a special type of level-based dimension, called a time dimension, that provides special functionality for modeling time series data.

Level-Based HierarchiesA dimension contains two or more logical levels. For example, a Time hierarchy might have three levels for Year, Quarter, and Month. Level-based hierarchies can also contain parent-child relationships. The recommended sequence for creating logical levels is to create a Grand Total level and then create child levels, working down to the lowest level.Level-based Dimension hierarchy levels allow:

to perform aggregate navigation, to configure level-based measure calculations,

users from Dashboard and Answers to drill down from one parent to a child level.

The following are the parts of a dimension:

Grand Total level : A special level representing the grand total for a dimension. Each dimension can have just one Grand Total level. A Grand Total level does not contain dimensional attributes and does not have a level key. However, you can associate measures with a Grand Total level. The aggregation level for those measures will always be the grand total for the dimension.

Level : All levels, except the Grand Total level, need to have at least one column. However, it is not necessary to explicitly associate all of the columns from a table with logical levels. Any column that you do not associate with a logical level is automatically associated with the lowest level in the dimension that corresponds to that dimension table. All logical columns in the same dimension table have to be associated with the same dimension.

Hierarchy : Each dimension contains one or more hierarchies. All hierarchies must have a common leaf level and a common root (all) level.

Level keys : Each logical level (except the topmost level defined as a Grand Total level) must have one or more attributes that compose a level key. The level key defines the unique elements in each logical level. The dimension table logical key has to be associated with the lowest level of a dimension and has to be the level key for that level.

Time dimensions and chronological keys : You can identify a dimension as a time dimension. At least one level of a time dimension must have a chronological key.

The following is a list of some guidelines you should use when setting up and using time dimensions:

Unbalanced (or ragged) hierarchy : A hierarchy in which all the lowest-level members do not have the same depth For example, a site can choose to have data for the current month at the day level, previous months data at the month level, and the previous 5 years data at the quarter level.

For example, a Time hierarchy might have data for the current month at the day level, the previous month's data at the month level, and the previous 5 years' data at the quarter level. This type of hierarchy is also known as an unbalanced hierarchy.

Note that unbalanced hierarchies are not necessarily the same as parent-child hierarchies. Parent-child hierarchies are unbalanced by nature, but level-based hierarchies can be unbalanced also.

Skip-level hierarchy : A skip-level hierarchy is a hierarchy where there are members that do not have a value for certain higher levels. . For example, in the United States, the city of Washington in the District of Columbia does not belong to a state. The expectation is that users can still navigate from the country level (United States) to Washington and below without the need for a state.

                                           Hierarchy with Unbalanced and Skip-Level Characteristics 

  Parent-Child HierarchiesA parent-child hierarchy is a hierarchy of members that all have the same type.It is a value-based hierarchy — Consists of values that define the hierarchy in a parent-child relationship and does not contain named levels. This contrasts with level-based hierarchies, where members of the same type occur only at a single level of the hierarchy.For example, an Employee hierarchy might have no levels, but instead have names of employees who are managed by other employees. Employees can have titles, such as Vice President. Vice Presidents might report to other Vice Presidents and different Vice Presidents can be at different depths in the hierarchy. The most common real-life occurrence of a parent-child hierarchy is an organizational reporting hierarchy chart, where the following all apply:

Each individual in the organization is an employee. Each employee, apart from the top-level managers, reports to a single manager.

The reporting hierarchy has many levels.

These conditions illustrate the basic features that define a parent-child hierarchy, namely:

A parent-child hierarchy is based on a single logical table (for eg, the "Employees" table)

Each row in the table contains two identifying keys, one to identify the member itself, the other to identify the "parent" of the member (for example, Emp_ID and Mgr_ID)

                                        Multi-Level Parent-Child Hierarchy

In level-based hierarchies, each level is named, and occupies a position in the hierarchy that corresponds to a real-word attribute or category that is deemed useful for analysis. Unlike level-based hierarchies, where the number of levels is fixed at design time, there is no limit to the depth of a parent-child hierarchy, and the depth can change at run time due to new data.

Types of Security in OBIEE with example

Why do we need security in OBIEE?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 thereby we can protect reports belonging to a group of users from the users of other groups.

Users and Groups in OBIEEEnd 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. It’s 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 & AuthorizationAuthentication 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.Now we can understand these terms in detail.

Types of Security in OBIEESecurity in Oracle BI can be classified broadly into the following three types.1. Object Level security (Authorization) Read More2. Data Level security (Authorization) Read More3. User Level Security (Authentication) Read More

Object Level Security in OBIEE

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, and Project Specific shared folders. Object-level security controls the visibility to business logical objects based on a user's role.

You can set up Object-Level Security for :

Repository level: In Presentation layer of Administration Tool, we can set Repository level security by giving permission or deny permission to users/groups to see particular table or column.

Web level: This provides security for objects stored in the Presentation Catalog, such as dashboards, dashboards pages, folder and reports. You can only view the objects for which you are authorized. For example, a mid-level manager may not be granted access to a dashboard containing summary information for an entire department.

Data Level Security in OBIEE

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.

Data-level security controls the visibility of data (content rendered in subject areas, dashboards, Oracle BI Answers, and so on) based on the user's association to data in the transactional system.

This controls the type and amount of data that you can see in a report. When multiple users run the same report, the results that are returned to each depend on their access rights and roles in the organization. For example, a sales vice president sees results for all regions, while a sales representative for a particular region sees only data for that region.

ExampleHere we will look at creating and using a session variable and how to implement row level security. This is mainly used to restrict data based on the user rights. The row level security will be useful in situations like:1. Allowing user to see data that she has access to.2. Showing data based on current date.3. A sales manager can be shown data in his region only. A CEO can be shown data for all regions.

In this post we look at showing units ordered in the current month. We use a security filter to filter data for the current month.Steps:1. The first step is to create the session variable for the current month. To do soa. In the Administration window, click on Action - > New -> Session -> Variable.Give CURRENT_MONTH as the name of the variable. Click on 'New' near the initialization block.b. Give CURRENT_MONTH_INIT as the name of the initialization block. Click on Edit Data Source.c. A new window opens. Select the connection pool by using the browse button. d. Use database as the data source type. e.Type in the following query:" select month(curdate()); " in the default initialization string.f. Click Ok to close the dialog.g. In the Session variable initialization block, click on edit data target. h. select the CURRENT_MONTH variable. Click on Ok.i. Click on ok to create the session variable.

2. The next step is to use this session variable to filter the result for this month.a.In the Administration tool. click on Manage -> Security.b.Create a new User called MonthlyUser.c. Create a new group called MonthlyUserGroup. Assign MonthlyUser to this group.d.Open the MonthlyUserGroup dialog and click on Permissions.e.Click the tab that says filters. Click on 'Add'f.In the name of the filter select the name of the table that you want to apply the filter on.g.Click on the ellipsis in the business model filter column.Apply the filter h. The group is now created. 

3. Login to BI answers using the MonthlyUser user. Select the columns from the store database. view results. You will notice that the results show data for the current month only.If you login by a user from the administrators group, data for all months will be visible.

User Level Security in OBIEE

User Authentication in OBIEEThe goal of the authentication configuration is to get a confirmation of the identity of a user based on the credentials provided.In OBIEE, the credentials provided are hold in this two variables:

USER  PASSWORD

The authentication process in OBIEE is managed by the BI Server.OBIEE Support four types of authentication

1. LDAP Authentication : Users are authenticated based on credentials stored in LDAP.This is the BEST method to do authentication in OBIEE and it supports company’s Single Sign On (SSO) philosophy as well.

2. External Table Authentication : you can maintain lists of users and their passwords in an external database table and use this table for authentication purposes.

3. Database Authentication : The Oracle BI Server can authenticates user based on database logins. If a user has read permission on a specific database. Oracle BI Presentation Services authenticates those users.

4. Oracle BI Server User Authentication : You can maintain lists of users and their passwords in the Oracle BI repository using the Administration Tool. The Oracle BI Server will attempt to authenticate users against this list when they log on.

Blink Characters in OBIEE

We can make the characters blink in OBIEE Answers/Dashboard by making use of the specified CSS style in the column properties tab.The CSS style that should be used is “text-decoration:blink;”

Blink Characters in OBIEE

How to Configure Write Back in OBIEE Report?

Follow the steps, screenshots and other referenced posts to configure write back in OBIEE reports.

Table PropertiesFirst, you should choose a report in Answers to be able to writing back to the database.

1. Go to the Table Component 2. Click on the write back properties icon.Remark that each column have on this head a

letter C and a number (Ex. c1, C2, … )

1. Fill the template name with for example:SetWriteBackValue. (This name will indicate later the statement to update or insert in the database)

 

Column Properties

1. Set to “write back” the value integration type of the column you want to be able to update.

Setting or Creating an Implicit Fact Column in OBIEE

To set an implicit fact column follow the steps and screenshot Create a Dummy Fact column in a Physical Layer called Implicit Fact Column and map

that column to any number of your choice

Creating Implicit Fact Column Join all Dimensions to this Fact column in BMM Layer

In presentation layer, double click the presentation catalog/ go to properties of presentation catalog.

In the general tab, find the Implicit Fact Column section.

Selecting Implicit Fact Column from Presentation Catalog Click on Set button, this will open the browse window

Select a fact column from the fact tables available in the presentation catalog.

Click OK.

Ensure that the selected Implicit Fact Column is displayed in the Implicit Fact Column section in the general properties of Presentation Catalog.

Click OK.

Save your changes in the repository.

Dimension Hierarchies in OBIEE:Level-Based Hierarchy and Parent-Child Hierarchy

A hierarchy is a cascaded series of many-to-one relationships and consists of different levels.                                                  Example, a region hierarchy is defined with the levels Region, State, and City.In the Business Model and Mapping layer, a dimension object represents a hierarchical organization of logical columns (attributes). One or more logical dimension tables can be associated with at most one dimension object. Common dimensions might be time periods, products, markets, customers, suppliers, promotion conditions, raw materials, manufacturing plants, transportation methods, media types, and time of day. Note that dimensions exist in the Business Model and Mapping (logical) layer and in the Presentation layer.There are two types of logical dimensions:

1.       Dimensions with level-based hierarchies (structure hierarchies).2.       Dimensions with parent-child hierarchies (value hierarchies).

Level-based hierarchies are those in which members are of several types, and members of the same type occur only at a single level. In parent-child hierarchies, members all have the same type. Oracle Business Intelligence also supports a special type of level-based dimension, called a time dimension, that provides special functionality for modeling time series data.

Level-Based HierarchiesA dimension contains two or more logical levels. For example, a Time hierarchy might have three levels for Year, Quarter, and Month. Level-based hierarchies can also contain parent-child relationships. The recommended sequence for creating logical levels is to create a Grand Total level and then create child levels, working down to the lowest level.Level-based Dimension hierarchy levels allow:

to perform aggregate navigation, to configure level-based measure calculations,

users from Dashboard and Answers to drill down from one parent to a child level.

The following are the parts of a dimension:

Grand Total level : A special level representing the grand total for a dimension. Each dimension can have just one Grand Total level. A Grand Total level does not contain dimensional attributes and does not have a level key. However, you can associate measures with a Grand Total level. The aggregation level for those measures will always be the grand total for the dimension.

Level : All levels, except the Grand Total level, need to have at least one column. However, it is not necessary to explicitly associate all of the columns from a table with logical levels. Any column that you do not associate with a logical level is automatically associated with the lowest level in the dimension that corresponds to that dimension table. All logical columns in the same dimension table have to be associated with the same dimension.

Hierarchy : Each dimension contains one or more hierarchies. All hierarchies must have a common leaf level and a common root (all) level.

Level keys : Each logical level (except the topmost level defined as a Grand Total level) must have one or more attributes that compose a level key. The level key defines the unique elements in each logical level. The dimension table logical key has to be associated with the lowest level of a dimension and has to be the level key for that level.

Time dimensions and chronological keys : You can identify a dimension as a time dimension. At least one level of a time dimension must have a chronological key.

The following is a list of some guidelines you should use when setting up and using time dimensions:

Unbalanced (or ragged) hierarchy : A hierarchy in which all the lowest-level members do not have the same depth For example, a site can choose to have data for the current month at the day level, previous months data at the month level, and the previous 5 years data at the quarter level.

For example, a Time hierarchy might have data for the current month at the day level, the previous month's data at the month level, and the previous 5 years' data at the quarter level. This type of hierarchy is also known as an unbalanced hierarchy.

Note that unbalanced hierarchies are not necessarily the same as parent-child hierarchies. Parent-child hierarchies are unbalanced by nature, but level-based hierarchies can be unbalanced also.

Skip-level hierarchy : A skip-level hierarchy is a hierarchy where there are members that do not have a value for certain higher levels. . For example, in the United States, the city of Washington in the District of Columbia does not belong to a state. The expectation is that users can still navigate from the country level (United States) to Washington and below without the need for a state.

                                           Hierarchy with Unbalanced and Skip-Level Characteristics 

  Parent-Child HierarchiesA parent-child hierarchy is a hierarchy of members that all have the same type.It is a value-based hierarchy — Consists of values that define the hierarchy in a parent-child relationship and does not contain named levels. This contrasts with level-based hierarchies, where members of the same type occur only at a single level of the hierarchy.For example, an Employee hierarchy might have no levels, but instead have names of employees who are managed by other employees. Employees can have titles, such as Vice President. Vice Presidents might report to other Vice Presidents and different Vice Presidents can be at different depths in the hierarchy. The most common real-life occurrence of a parent-child hierarchy is an organizational reporting hierarchy chart, where the following all apply:

Each individual in the organization is an employee. Each employee, apart from the top-level managers, reports to a single manager.

The reporting hierarchy has many levels.

These conditions illustrate the basic features that define a parent-child hierarchy, namely:

A parent-child hierarchy is based on a single logical table (for eg, the "Employees" table)

Each row in the table contains two identifying keys, one to identify the member itself, the other to identify the "parent" of the member (for example, Emp_ID and Mgr_ID)

                                        Multi-Level Parent-Child Hierarchy

In level-based hierarchies, each level is named, and occupies a position in the hierarchy that corresponds to a real-word attribute or category that is deemed useful for analysis. Unlike level-based hierarchies, where the number of levels is fixed at design time, there is no limit to the depth of a parent-child hierarchy, and the depth can change at run time due to new data.

SQL Functions: MONTHS_BETWEEN

MONTHS_BETWEEN Returns the number of months between two date values. The return value can be negative or positive depending on

Select MONTHS_BETWEEN (end_date,start_date) from emp;

SQL Functions: LAST_DAY

LAST_DAY: Takes date as input and returns the last day of month corresponding to that date. Return type is always DATE.

Select LAST_DAY (LAST_ACCESS_DATE) FROM EMP;

SQL Functions: CARDINALITY

CARDINALITY:Returns the number of elements in a nested table column. Returns NULL if the table is empty.

Select emp, CARDINALITY (COL) FROM emp;

This will give the number of elements in the nested table column COL

How to get SQL from OBIEE Reports?

There are many ways to get the SQL from OBIEE Reports1. Modify the request and click Advanced in that you get xml code and also the actual

SQL.

2. In the catalog Manager click Tools –>Create Report .In the Create Report Window –> Click Request SQL and save the SQL to the physical path in your PC.

3. Enable Loglevel to 2 in the OBIEE Admin Tool from Mange -> Security and enable the log level to 2 by clicking properties for the user, then go to the NQQuery.log in BI_HOME/OracleBI/Server/Logs.You will find the SQL for that User.

4. By clicking Administration ->Manage sessions -> View SQL

Execute Direct SQL (Direct Database Request) feature in OBIEE

The Direct Database Request permits you to perform SQL statement directly to a data source. The Oracle BI Server sends unprocessed, user-entered, physical SQL directly to an underlying database. The returned results set can be rendered in Oracle BI Presentation Services, and then charted, rendered in a dashboard and treated as an Oracle BI request.The Execute Direct SQL (Direct Database Request) feature is seen in Answers page.Under the Subject Area. 

Direct Database RequestIn Answers with the help of this feature Administrator can debug some issues like….

1. Check physical connectivity to the database.2. Check report or dashboard performance (Performance Tuning)

Mostly this feature is not allowed or not considered as a good practice to Production users. The reasons are

1. User can by-pass a data level security defined in the repository.2. They can overload  production database

3. Users can delete some important database object.

4. They can see some other tables which they are not permitted to see.

We can disable” Execute Direct SQL” by following the path below:Answers > Settings > Administration > Manage Privilege.

 

How Write Back Works in OBIEE

If a user has the Write Back to Database privilege, then the write-back fields in their analyses can display as editable fields if properly configured. If the user does not have this privilege, then the write-back fields display as normal fields.

If the user types a value in an editable field and clicks the appropriate write-back button, then the application reads the write-back template to get the appropriate insert or update SQL command. It then issues the insert or update command. If the command succeeds, then it reads the record and updates the analysis. If there is an error in either reading the template or in executing the SQL command, then an error message is displayed.

The insert command runs when a record does not yet exist and the user enters new data into the table. In this case, a user has typed in a table record whose value was originally null.

The update command runs when a user modifies existing data. To display a record that does not yet exist in the physical table to which a user is writing back, you can create another similar table. Use this similar table to display placeholder records that a user can modify in dashboards.

Write-Back Template Example in OBIEE

The write back template is an custom messages (XML-formatted) file that contains SQL commands needed to insert and update records in the write back table and columns you have configured. It must be store in the directory"OracleBI\web\msgdb\customMessages"

The line <WebMessage name="SetQuotaUseID">

contain the value of the template name. This value must match with the value filled in the table properties.

The line <writeBack connectionPool="Supplier"> contain the value of the connection pool. You must have the same name in the repository.

The line <update>UPDATE regiontypequota SET Dollars=@{c4} WHERE YR=@{c0} AND Quarter=@{c1} AND Region='@{c2}' AND ItemType='@{c3}'</update>

contain the SQL statement to update the database.

Values can be referenced either by position (such as @1, @3) or by column ID (@{c0}, @{c2}).

A write-back template might resemble the example given below

<?xml version="1.0" encoding="utf-8" ?><WebMessageTables xmlns:sawm="com.siebel.analytics.web/message/v1"><WebMessageTable lang="en-us" system="WriteBack" table="Messages"> <WebMessage name="SetQuotaUseID"> <XML> <writeBack connectionPool="Supplier"> <insert>INSERT INTO regiontypequota VALUES(@{c0},@{c1},'@{c2}','@{c3}',@{c4})</insert> <update>UPDATE regiontypequota SET Dollars=@{c4} WHERE YR=@{c0} AND Quarter=@{c1} AND Region='@{c2}' AND ItemType='@{c3}'</update> </writeBack> </XML> </WebMessage> <WebMessage name="SetQuota"> <XML> <writeBack connectionPool="Supplier"> <insert>INSERT INTO regiontypequota VALUES(@1,@2,'@3','@4',@5)</insert> <update>UPDATE regiontypequota SET Dollars=@5 WHERE YR=@1 AND Quarter=@2 AND Region='@3' AND ItemType='@4'</update> </writeBack> </XML> </WebMessage>

</WebMessageTable></WebMessageTables>

Write-Back Limitations in OBIEE

Users can write back to any data source (except for an ADF data source) that allows the execution of SQL queries from the Oracle BI Server. As you configure for write back, keep the following limitations in mind:

Numeric columns must contain numbers only. They should not contain any data formatting characters such as dollar signs ($), pound signs or hash signs (#), percent signs (%), and so on.

Text columns should contain string data only.

You can use the template mechanism only with table views and only for single-value data. The template mechanism is not supported for pivot table views or any type of view or for multiple-value data.

All values in write-back columns are editable.

Any field in an analysis can be flagged as a write-back field, even if it is not derived from the write-back table that you created.

A template can contain SQL statements other than insert and update. The write-back function passes these statements to the database.

Presentation Services performs only minimal validation of data input. If the field is numeric and the user enters text data, then Presentation Services detects that and prevents the invalid data from going to the database

The template mechanism is not suitable for entering arbitrary new records. In other words, do not use it as a data input tool.

Write-back analyses do not support drill-down. Because drilling down modifies the table structure, the write-back template does not work.

Execute Direct SQL (Direct Database Request) feature in OBIEE

The Direct Database Request permits you to perform SQL statement directly to a data source. The Oracle BI Server sends unprocessed, user-entered, physical SQL directly to an underlying database. The returned results set can be rendered in Oracle BI Presentation Services, and then charted, rendered in a dashboard and treated as an Oracle BI request.The Execute Direct SQL (Direct Database Request) feature is seen in Answers page.Under the Subject Area. 

Direct Database RequestIn Answers with the help of this feature Administrator can debug some issues like….

1. Check physical connectivity to the database.2. Check report or dashboard performance (Performance Tuning)

Mostly this feature is not allowed or not considered as a good practice to Production users. The reasons are

1. User can by-pass a data level security defined in the repository.2. They can overload  production database

3. Users can delete some important database object.

4. They can see some other tables which they are not permitted to see.

We can disable” Execute Direct SQL” by following the path below:Answers > Settings > Administration > Manage Privilege.

 

Create OBIEE Report Using Two Subject Areas

From the Criteria Pane of the Report Created from First Subject Area come to the bottom of the page and click combine request. But the options are limited for combining like union,minus etc.

Purging Options in OBIEE

Invoking ODBC Extension FunctionsThe following ODBC functions affect cache entries associated with the repository specified by the ODBC connection. You can call these functions using the nqcmd.exe command-line executable.

The syntax of the call will be as follows:nqcmd -d "Analytics Web" –u administrator –p sadmin –s purge.txt.Where purge.txt contains the call (for example, call SAPurgeAllCache())

The different Purging options in OBIEE are; 1. SAPurgeCacheByQuery Read More 2. SAPurgeCacheByTable Read More 

3. SAPurgeAllCache Read More 

4. SAPurgeCacheByDatabase Read More

5. SAPurgeCacheByQuery 6. Purges a cache entry that exactly matches a specified query.The following call

programmatically purges the cache entry associated with this query:Call SAPurgeCacheByQuery(‘select lastname, firstname from employee where salary >100000’ );

SAPurgeCacheByTable 7. Purges all cache entries associated with a specified physical table name (fully

qualified) for the repository to which the client has connected.8.

This function takes up to four parameters representing the four components (database, catalog,schema and table name proper) of a fully qualified physical table

name. For example, you might have a table with the fully qualified name of DBName.CatName.SchName.TabName. To purge the cache entries associated with this table in the physical layer of the Siebel Analytics repository, execute the following call in a script: 

9. Call SAPurgeCacheByTable(‘DBName’, ‘CatName’, ‘SchName’, ‘TabName’);10.11. Wild cards are not supported by the Siebel Analytics Server for this function.

Additionally,DBName and TabName cannot be null. If either one is null, you will receive an error message.

SAPurgeAllCache 12. Purges all cache entries. The following is an example of this call:13. Call SAPurgeAllCache();

SAPurgeCacheByDatabase

Purges all cache entries associated with a specific physical database name.A record is returned as a result of calling any of the ODBC procedures to purge the cache.

This function takes one parameter that represents the physical database name and the parameter cannot be null. The following is an example of this call:

Call SAPurgeCacheByDatabase( ‘DBName’ );

How to query a repository using Query Repository Tool?

Before reading how to query a repository know about Query Repository Tool and its use Read More

1. In the repository, right-click any object and choose Display Related > [type of object on which you want to search].

2. In the Query Repository dialog box, the type of object is prefilled

3. In the Query Repository dialog box, complete the query information using QueryRepository Fields & Buttons Table as a guide. This table contains a description of most fields and buttons in the Query Repository dialog box.

4. Click Query.

5. To save a repository query to an external file, click Save.

6. In the Save As dialog box, choose a type of file and an Encoding value.

7. To add additional columns of information to the results, click Add Columns.

8. In the Select information to add to the report dialog box, select the columns you want from the list and click OK.

9. You can re-order the columns by selecting a checked column and clicking Up or Down.

10. In the Save as dialog box, type a file name and select a Save as type.

11. Click Save.

Query Repository Tool

Query Repository Tool in OBIEE and its use with example

It is utility of Seibel/OBIEE Admin tool which allows you to examine the repository metadata tool.You can query for objects in the repository using the Query Repository tool.

You can query a repository for objects in the repository based on name, type (such as Catalog, Complex Join, Key, and LDAP Server), or on a combination of name and type. You can then

edit or delete objects that appear in the Results list. You can also create new objects, and view parent hierarchies.

Query Repository Tool

Types of Testing in OBIEE Report Environment

There are 3 types of testing in the OBIEE application development.

Unit Testing: The developer will test the own stuff. Peer-Reviews: Test the application within the organization as the application

developed. The application will be reviewed by your team member ( third party developer )

UAT(User Acceptance Test):This is a client test testing, the application will be tested by some other company. This test is carried out in the presence of client side technical users to verify the data migration from source to destination.