Pages

Wednesday, 10 October 2012

Guided Navigation


Guided Navigation:

is a way of making OBIEE dashboards and reports more dynamic, personal and relevant to the current user viewing the dashboard.

For example - specific regions of the dashboard can be made to 'only' appear when there is important information to report.

To do this you create a condition based on either an Analysis or KPI, where the result is boolean (true/false).
i.e. a count > 20 or no rows returned.

The conditions can be used to determine:

  • If agents should run and /or to who they should deliver their contents.
  • If action links are displayed
  • If reports are shown


For example if the sales department has a target to meet, an anlysis could be built to only show a report if sales targets are not met and also send out an email report via the agent showing underperforming sales. If targets are met, then no email is sent, or a 'nice' email is sent out.

There are two types of condition - Named and Inline.

Inline Conditions:

If you only ever intend to use a condition once - and this condition is only for dashboard reporting, you can create an inline condition. This is created within the dashboard page when you build and design the layout and is saved as part of the page.

Named Conditions:

A Named Condition is created from the New dropdown or from the create --> more panel on the home page. It is as its name suggests, named, and therefore saved. This means that the same condition can be used in many places to guide action links, raise alerts or expose parts of the dashboard.

A judicious use of guided navigation using conditions can improve the entire BI experience for your users, but as always, too much of a good thing will confuse rather than clarify the story you tell using the dashboard as your canvas.

Friday, 5 October 2012

ODBC or OCI?


How should you set your connection pool - OCI or ODBC?

When possible, configure your connection pools to use a “native driver” to connect to your physical databases.  For example, use OCI for connecting to an Oracle database rather than ODBC

The native drivers understand the database better than ODBC. ODBC is the lowest common denominator and uses "simple" statements to select data and then passes the load to the business intelligence server for aggregation and transformation.

The native drivers allow the load to passed from the application server to the database, and the database then returns only the result required.

A simple example would be to ask for a sales total.

Using ODBC

In ODBC the query pushed to the database would be to select the relevant sales. The sales then are returned to the BI server and the total is calculated and sent on to the dashboard. YOu may even find that all the sales records are returned to the BI server, then filtered for the relevant records, before any aggregation takes place.

Whereas:

Using OCI

Using a native driver helps the OBI server understand what the database, where the data resides, is capable of. Just how much complexity can be pushed down and passed to the database, relieving the load on the OBI server.

You will find filters, aggregations and complex calculations appearing in the physical queries being passed down with the native drivers (eg. OCI for Oracle). I have examined some queries in the process of 'debugging' various parts of the repository and been surprised with new ways and functionality in SQL that the OBIEE server passes down. I have been writing SQL queries for a good many years and OBIEE still finds ways to expand my knowledge.

Monday, 1 October 2012

No more Complex Joins please!


Avoid Physical Layer Complex Joins.

While it is perfectly acceptable to use complex joins in the physical layer, this can (and usually does) result in poor query performance when OBIEE generates the query against the database. Far better to use the foreign key joins that should be implicit in the star/snowflakes of your data model.

For example where the complex join involves a between condition, then you are looking at index range scans on the database, repeat this several million times when you need an average on a large dataset, and you are potentially going to be looking at a spinning clock symbol for a long time.

Any work that has to be done by the BI server costs time. Much as you tune a query in the database to avoid making function calls in the 'WHERE' clause, so you should aim to do the same in your physical joins. - No more BICOLUMN = TRUNC(DATECOLUIMN) or BICOLUMN = SUBSTR(CHARCOLUMN,1,4).

Wednesday, 19 September 2012

Lack of Data Security Filters


Area of Impact is Data Integrity and Performance

Data Security Filter Consequence

A lack of data visibility filters will enable all users who have access to specific subject areas to have access to all records, regardless of any visibility restrictions which may be implemented within the source applications. It can potentially impact the overall performance of such queries, as the user may return a larger dataset than what they are permitted in seeing.

What should be done :
The following provides a high level summary of the functionality provided by data security filters:

When a user logs in, the following two processes should take place:
Authentication
• Verifies the user has the right to log in to the system
Authorization
• The process of defining which “Application Roles” should be assigned to the user once they have successfully authenticated

Once the above two processes have taken place, there are three OBIEE components that apply “security policies” based up the user’s Application Roles:
• Presentation Catalogue > Dashboard/report access and front-end privileges
• BI Repository > RPD metadata access and data-visibility
• FMW Policy Store > Access to BI Server (e.g. impersonation) and BI Publisher features

The default Roles has the following privileges in Oracle BI EE 11g:
BIAdministrator

  • Manage BI Repository (RPD)
  • Administer BI Publisher

BIAuthor

  • Privileges defined in BI Presentation Catalog
  • BI Publisher Develop / Design / Schedule Reports

BIConsumer

  • Privileges defined in BI Presentation Catalog
  • BI Publisher Excel / On-line Report Analyzer


Data filters can then be set within the OBIEE RPD via the Application Roles and Users through the “Manage > Identity” menu option.

The development team should use the above details provided and check whether similar security can be defined for the existing sources which are loaded into the data warehouse.

Further details on this topic can also be found in the following sections:
• Oracle® Fusion Middleware > Security Guide for Oracle Business Intelligence Enterprise Edition > 11g Release 1 (11.1.1)

Wednesday, 12 September 2012

Set a Dashboard Landing Page for all Users

If you want all your default and new users to go to a specific page when they login, and they have not set a specific page or their 'home' page is set to default then they can be directed via the PORTALPATH setting.

PORTALPATH

The PORTALPATH setting will only work if the user has not set a new default home page in their account settings.

You will need to make a few changes in the repository to enable this setting.

Open the repository and go to manage --> variables

Navigate the tree displayed and open up Session and then Variables and then System
You will create a new Session Variable here

Right click on the right hand side and select the new PORTALPATH or create a new variable PORTALPATH if no option is presented.

In the Default Initialiser - give the path to the required dashboard. eg /shared/samplesales/_portal/landingpage

Close the repository and those users without a default page in their account setting will instead land on the new landing page.

Monday, 3 September 2012

Patching support for OBIEE 10.1.3.4.1 ends on 30th September


Patching support for OBIEE 10.1.3.4.1 ends on 30th September 2012.


After September, there will be no more one-off patches available for OBIEE 10.1.3.4.1 or lower versions. If you wish to continue receiving one-off patches, should the situation arise, please apply the OBIEE 10.1.3.4.2 patch set.

Thursday, 16 August 2012

Calendar Date and Time Functions


Calendar Date/Time Functions

The calendar date/time functions manipulate data of the data types DATE and DATETIME based on a calendar year. You must select these functions together with another column; they cannot be selected alone.

Functions

Current_Date
Current_Time
Current_TimeStamp
Day_Of_Quarter
DayName
DayOfMonth
DayOfWeek
DayOfYear
Hour
Minute
Month
Month_Of_Quarter
MonthName
Now
Quarter_Of_Year
Second
TimestampAdd
TimestampDiff
Week_Of_Quarter
Week_Of_Year
Year





CURRENT_DATE

Returns the current date. The date is determined by the system in which the Oracle BI Server is running.

Syntax

Current_Date


CURRENT_TIME

Returns the current time. The time is determined by the system in which the Oracle BI Server is running.
Note: The Analytics Server does not cache queries that contain this function.

Syntax

Current_Time(integer)
Where:
integer
Any integer that represents the number of digits of precision with which to display the fractional second.


CURRENT_TIMESTAMP

Returns the current date/timestamp. The timestamp is determined by the system in which the Oracle BI Server is running.
Note: The Oracle BI Server does not cache queries that contain this function.

Syntax

Current_TimeStamp(integer)
Where:
integer
Any integer that represents the number of digits of precision with which to display the fractional second.


DAY_OF_QUARTER

Returns a number (between 1 and 92) corresponding to the day of the quarter for the specified date.

Syntax

Day_Of_Quarter(dateExpr)
Where:
dateExpr
Any expression that evaluates to a date.


DAYNAME

Returns the name of the day for a specified date.

Syntax

DayName(dateExpr)
Where:
dateExpr
Any expression that evaluates to a date.


DAYOFMONTH

Returns the number corresponding to the day of the month for a specified date.

Syntax

DayOfMonth(dateExpr)
Where:
dateExpr
Any expression that evaluates to a date.


DAYOFWEEK

Returns a number between 1 and 7 corresponding to the day of the week, Sunday through Saturday, for a specified date. For example, the number 1 corresponds to Sunday and the number 7 corresponds to Saturday.

Syntax

DayOfWeek(dateExpr)
Where:
dateExpr
Any expression that evaluates to a date.


DAYOFYEAR

Returns the number (between 1 and 366) corresponding to the day of the year for a specified date.

Syntax

DayOfYear(dateExpr)
Where:
dateExpr
Any expression that evaluates to a date.


HOUR

Returns the number (between 0 and 23) corresponding to the hour for a specified time. For example, 0 corresponds to 12 A.M. and 23 corresponds to 11 P.M.

Syntax

Hour(timeExpr)
Where:
timeExpr
Any expression that evaluates to a time.


MINUTE

Returns the number (between 0 and 59) corresponding to the minute for a specified time.

Syntax

Minute(timeExpr)
Where:
timeExpr
Any expression that evaluates to a time.


MONTH

Returns a number (between 1 and 12) corresponding to the month for a specified date.

Syntax

Month(dateExpr)
Where:
dateExpr
Any expression that evaluates to a date.


MONTH_OF_QUARTER

Returns the number (between 1 and 3) corresponding to the month in the quarter for a specified date.

Syntax

Month_Of_Quarter(dateExpr)
Where:
dateExpr
Any expression that evaluates to a date.


MONTHNAME

Returns the name of the month for a specified date.

Syntax

MonthName(dateExpr)
Where:
dateExpr
Any expression that evaluates to a date.


NOW

Returns the current timestamp. This function is equivalent to the function current_timestamp .

Syntax

Now()


QUARTER_OF_YEAR

Returns the number (between 1 and 4) corresponding to the quarter of the year for a specified date.

Syntax

Quarter_Of_Year(dateExpr)
Where:
dateExpr
Any expression that evaluates to a date.


SECOND

Returns the number (between 0 and 59) corresponding to the seconds for a specified time.

Syntax

Second(timeExpr)
Where:
timeExpr
Any expression that evaluates to a time.


TIMESTAMPADD

Adds a specified number of intervals to a specified timestamp, and returns a single timestamp. Passing a null intExpr or timeExpr to this function results in the return of a null value.
In the simplest scenario, this function simply adds the specified integer value to the appropriate component of the timestamp, based on the interval. Adding a week translates to adding seven days, and adding a quarter translates to adding three months. A negative integer value results in a subtraction (such as going back in time).
An overflow of the specified component (for example, more than 60 seconds, 24 hours, twelve months, and so on) necessitates adding an appropriate amount to the next component. For example, when adding to the day component of a timestamp, this function makes sure that overflow takes into account the number of days in a particular month (including leap years). Similar measures are used to make sure that adding a month component results in the appropriate number of days for the day component (such as adding a month to '2010-05-31' does not result in '2010-06-31' because June does not have 31 days). The function also deals with the month and day components in a similar fashion when adding or subtracting year components.

Syntax

TimestampAdd(interval, intExpr, timestamp)
Where:
interval
The specified interval. Valid values are: SQL_TSI_SECOND, SQL_TSI_MINUTE, SQL_TSI_HOUR, SQL_TSI_DAY, SQL_TSI_WEEK, SQL_TSI_MONTH, SQL_TSI_QUARTER, SQL_TSI_YEAR.
intExpr
Any expression that evaluates to an integer value.
timestamp
Any valid timestamp.

Examples

Select {TimestampAdd(SQL_TSI_DAY, 3, TIMESTAMP'2000-02-27 14:30:00')}
From Employee where employeeid = 2;
In the above example, the query asks for the resulting timestamp when 3 days are added to '2000-02-27 14:30:00'. Since February, 2000 is a leap year, the query returns a single timestamp of '2000-03-01 14:30:00'.
Select {TimestampAdd(SQL_TSI_MONTH, 7, TIMESTAMP'1999-07-31 00:00:00')}
From Employee where employeeid = 2;
In the above example, the query asks for the resulting timestamp when 7 months are added to '1999-07-31 00:00:00'. The query returns a single timestamp of '2000-02-29 00:00:00'. Notice the reduction of day component to 29 because of the shorter month of February.
Select {TimestampAdd(SQL_TSI_MINUTE, 25, TIMESTAMP'2000-07-31 23:35:00')}
From Employee where employeeid = 2;
In the above example, the query asks for the resulting timestamp when 25 minutes are added to '2000-07-31 23:35:00'. The query returns a single timestamp of '2000-08-01 00:00:00'. Notice the propagation of overflow through the month component.


TIMESTAMPDIFF

Returns the total number of specified intervals between two timestamps. Passing a null timestamp to this function results in a null return value.
This function first determines the timestamp component that corresponds to the specified interval parameter, and then looks at the higher order components of both timestamps to calculate the total number of intervals for each timestamp. For example, if the specified interval corresponds to the month component, the function calculates the total number of months for each timestamp by adding the month component and twelve times the year component. Then the function subtracts the first timestamp's total number of intervals from the second timestamp's total number of intervals.
The TimestampDiff function rounds up to the next integer whenever fractional intervals represent a crossing of an interval boundary. For example, the difference in years between '1999-12-31' and '2000-01-01' is 1 year because the fractional year represents a crossing from one year to the next (such as 1999 to 2000). By contrast, the difference between '1999-01-01' and '1999-12-31' is zero years because the fractional interval falls entirely within a particular year (such as 1999). Microsoft's SQL Server exhibits the same rounding behavior, but IBM's DB2 does not; it always rounds down. Oracle does not implement a generalized timestamp difference function.
When calculating the difference in weeks, the function calculates the difference in days and divides by seven before rounding. Additionally, the function takes into account how the administrator has configured the start of a new week in the NQSConfig.ini file. For example, with Sunday as the start of the week, the difference in weeks between '2000-07-06' (a Thursday) and '2000-07-10' (the following Monday) results in a value of 1 week. With Tuesday as the start of the week, however, the function would return zero weeks since the fractional interval falls entirely within a particular week. When calculating the difference in quarters, the function calculates the difference in months and divides by three before rounding.
Oracle BI Server pushes down the TIMESTAMPADD and TIMESTAMPDIFF functions to Microsoft's SQL Server and ODBC databases by default. While Oracle BI Server can also push to IBM's DB2, the features table is turned off by default due to DB2's simplistic semantics. (IBM's DB2 provides a generalized timestamp difference function, TIMESTAMPDIFF, but it simplifies the calculation by always assuming a 365-day year, 52-week year, and 30-day month.) The features table is also turned off by default for Oracle, since Oracle databases do not fully support these functions.

Syntax

TimestampDiff(interval, timestamp1, timestamp2)
Where:
interval
The specified interval. Valid values are: SQL_TSI_SECOND, SQL_TSI_MINUTE, SQL_TSI_HOUR, SQL_TSI_DAY, SQL_TSI_WEEK, SQL_TSI_MONTH, SQL_TSI_QUARTER, SQL_TSI_YEAR.
timestamp1
Any valid timestamp.
timestamp2
Any valid timestamp.

Examples

Select {TimestampDiff(SQL_TSI_DAY, TIMESTAMP'1998-07-31 23:35:00', TIMESTAMP'2000-04-01 14:24:00')}
From Employee where employeeid = 2;
In the above example, the query asks for a difference in days between timestamps '1998-07-31 23:35:00' and '2000-04-01 14:24:00'. It returns a value of 610. Notice that the leap year in 2000 results in an additional day.


WEEK_OF_QUARTER

Returns a number (between 1 and 13) corresponding to the week of the quarter for the specified date.

Syntax

Week_Of_Quarter(dateExpr)
Where:
dateExpr
Any expression that evaluates to a date.


WEEK_OF_YEAR

Returns a number (between 1 and 53) corresponding to the week of the year for the specified date.

Syntax

Week_Of_Year(dateExpr)
Where:
dateExpr
Any expression that evaluates to a date.


YEAR

Returns the year for the specified date.

Syntax

Year(dateExpr)
Where:
dateExpr Any expression that evaluates to a date.