OBIEE - Connection Pools

Apart from creating your connection pool, filling in the type of database, username and password, do you give much thought to the connection pool.

If you have heavy usage, you should increase the maximum number of connections from the default of 10.
You will definately need a connection pool seperate from the others to set your session variables.
You will also need a separate connection pool for usage tracking.
Keep a separate connection pool for write back.

Just a few thoughts

OBIEE - Custom Login Message

OBIEE - Customised Login Message

The first thing your users see if they need to login id the login screen and with a little effort you can customise this to "up" the wow factor and provide information.

We will customise the following file.
OBIEE_HOME\Oracle_BI1\bifoundation\web\msgdb\pages\common\signin.html

and as always !!!BACKUP!!! before making changes.

On our non production environments we have a message like below.
...
<div align="center" class="centerDiv">
<table width="180" border="0" cellpadding="0" cellspacing="0">
   <tr>
      <td class="lefttop"></td>
      <td class="topmiddle" width="100%" height="12"><span style="background-color:#F6CED8;text-align:center;font-weight:bold;color:#000000">
        You are connecting to a Non-Production environment!
   </span></td>
      <td class="righttop"></td>
   </tr>

   <tr>...

Customised Login Images

You can go further by adding images

Locate the <form id="logonForm" tag, then the table tag below it:
            <table width="100%" cellpadding="0" cellspacing="0">

Underneath add the following lines (assuming that Your_Logo.png is the image):

<tr>
<td>
<img src="fmap:login/Your_Logo.png" style="visibility: visible;" class="defaultHidden" width="280" align="bottom" height="120" alt="Description of Your Logo"/>
</td>
</tr>

Remember if you are uploading an image to put the "Your_Logo.png" file in the following three locations

OBIEE_HOME\user_projects\domains\bifoundation_domain\servers\bi_server1\tmp\_WL_user\analytics_11.1.1\7dezjl\war\res\sk_blafp\b_mozilla_4

OBIEE_HOME\user_projects\domains\bifoundation_domain\servers\bi_server1\tmp\_WL_user\analytics_11.1.1\7dezjl\war\res\sk_blafp\login

OBIEE_HOME \Oracle_BI1\bifoundation\web\app\res\sk_blafp\login

OBIEE - Sample Administration Documentation

As I mentioned in Part 1 of a previous article here, you really need to have documentation around your OBIEE environment.


Not the most glamerous of suggestions surely, but your boss and sysadmin will love you. Start by documenting where to find stuff middleware home, logfiles, config files (instanceconfig.xml etc.), the URLs used for administration.

Then move on to documenting the config changes made after the install, what settings were changed and if known what the default values were before and what they are now. What are the connection details for your RCU schemas (BIPLATFORM and MDS). Capture things like server names and directory structures.

Now comes the living documents which you can generate periodically and version. Run off a repository report and catalog reports. This will give you (and your colleagues) a better understanding of what the repository looks like and also what in the catalog is where on the dashboards.

As an added benefit you can now work backwards from the catalog reports through the repository reports to see where data comes from to fill reports, and vice-versa, from a physical column work your way through the repository to the catalog report to see where the data is used.

Remember, having no documentation means a risk to your business.

And keep it up to date, mark your calendar for a monthly review, most times , no change, but there will be that month.......

Here's a suggestion of some topics to get you started!

General Info about your OBIEE Install

Server
URL
DNS Shortcut
WebLogic Console
Enterprise Manager
Repository Name
Catalog Path

Install Type Information

Type
OS
Install Dir

OBIEE Configuration

writeback
EVALUATE_SUPPORT_LEVEL
Usage Tracking
Repository Monitoring

Users/Passwords

Schema Prefix
BIPLATFORM
MDS
weblogic
Repository

Custom Deployments

password_change.ear

Maps

OBIEE Lockdown - Part 1

Security Recommendations in Oracle Business Intelligence Installations

There are three key security recommendations for installing and securing OBIEE in your enterprise environment.

1.       Be serious about password management.

It is important to lock down the OBIEE environment and changing default passwords after installation.

The passwords for weblogic user should not be simple to guess or widely distributed. The best practice is to have different passwords throughout the environments. Moreover, I’d recommend replacing “weblogic user” with another obfuscated username. The username and password combination should be different throughout the environments (at least the password).

Change the default passwords for the RPD, as everyone knows “Admin123.”  If you are promoting an RPD, your password for Dev, Test, and Prod RPDs should be different as well to avoid a possibility of a developer making changes in a wrong environment.

Do not use the administrative account to present reports to the users and avoid providing it to users, there is high risk of breaking/deleting something by accident. Consider automating deployments to avoid having to deal with passwords manually.

2.       Take the authentication and authorization outside of OBIEE

Use whatever is standard in your organization for managing authentication (be it OID, Active Directory, or some other sort of LDAP). Not only does it improve user experience by removing the need to memorize yet another username/password, but it also saves time for the development team. Remember: They are not in the user management business. Another great use case is the ability to push this functionality further by automating users’ authorization by managing LDAP groups’ memberships and mapping them to the OBIEE’s application roles.

3.       RPD Security Objects

Unfortunately, the Administration Tool does not allow development separation within the repository objects (one needs to be an administrator to edit the RPD file – no way around it), hence anyone with the RPD/Admin password can do pretty much anything within the RPD. At this time, there are limited built-in options to audit or keep track of the RPD development changes. One must rely on a custom developed solution if this functionality is important. An easy and practical option is to keep an XLS spreadsheet of the major development milestones. It’s simple; however, its disadvantage is, that there is an overhead associated with maintaining it, especially during active development periods. Another option would be to use an Administration tool utility to create metadata repository document on a regular basis and track deltas. Finally, more advanced options would include MUDE (multi user development environment) projects and XML export.

OBIEE - Increase Map Joins

OBIEE has a default limit of 500 joins to a map.

There are occasions where you may need to up this limit and you will need to make changes to this setting if more points of contact to the map exist.

You will need to add something like the below into your instanceconfig.xml file

<SpatialMaps>
<ColocatedOracleMapViewerContextPath>/mapviewer</ColocatedOracleMapViewerContextPath>
<RemoteOracleMapViewerAbsoluteURL/>
<LayerDataLayout>
<MaxRecords>1500</MaxRecords>
</LayerDataLayout>
</SpatialMaps>

OBIEE Repository Variable Report

You can create a report to show what your repository variables are set to by doing something like below:

Create a 'dummy' report with a static text view and enter something like below and make sure you have selected the contains HTML Markup box.

[u][b]Predefined Presentation Variables[/b][/u][br/]
[b]session.language:[/b] @{session.language}[br/]
[b]session.locale:[/b] @{session.locale}[br/]
[b]DISPLAYNAME:[/b]@{biServer.variables['NQ_SESSION.DISPLAYNAME']}[br/]
[b]USER:[/b]@{biServer.variables['NQ_SESSION.USER']}[br/]
[b]GROUP:[/b]@{biServer.variables['NQ_SESSION.GROUP']}[br/]
[b]ROLES:[/b]@{biServer.variables['NQ_SESSION.ROLES']}[br/]
[b]ROLEGUIDS:[/b]@{biServer.variables['NQ_SESSION.ROLEGUIDS']}[br/]
[b]PERMISSIONS:[/b]@{biServer.variables['NQ_SESSION.PERMISSIONS']}[br/]
[b]USERGUID:[/b]@{biServer.variables['NQ_SESSION.USERGUID']}[br/]

Update: See more on System Variables here.

OBIEE - Repository System Session Variables

Session variables are similar to dynamic repository variables in that they obtain their values from initialization blocks. Unlike dynamic repository variables, however, the initialization of session variables is not scheduled. When a user begins a session, the Oracle BI Server creates new instances of session variables and initializes them.

Two types of session  variables:

• System Session Variables
  
• Nonsystem Session Variables
  

Sytem Session Variables : 

System session variables are session variables that the Oracle BI Server and Oracle BI Presentation Services use for specific purposes. System session variables have reserved names that cannot be used for other kinds of variables (such as static or dynamic repository variables and nonsystem session variables).

When you use these variables for Oracle BI Presentation Services, preface their names with NQ_SESSION. For example, to filter a column on the value of the variable LOGLEVEL, set the filter to the variable NQ_SESSION.LOGLEVEL.

 

Variable	Description
USER	Holds the value the user enters as his or her logon name. This variable is typically populated from the LDAP profile of the user.
PROXY	Holds the name of the proxy user. A proxy user is a user that has been authorized to act for another user.
GROUP	Contains the groups to which the user belongs. Exists only for compatibility with previous releases. Legacy groups are mapped to application roles automatically.
WEBGROUPS	Specifies the Catalog groups (Presentation Services groups) to which the user belongs, if any. Note that the recommended practice is to use application roles rather than Catalog groups.
USERGUID	Contains the global unique identifier (GUID) of the user, typically populated from the LDAP profile of the user.
ROLES	Contains the application roles to which the user belongs.
ROLEGUIDS	Contains the global unique identifiers (GUIDs) for the application roles to which the user belongs. GUIDs for application roles are the same as the application role names.
PERMISSIONS	Contains the permissions held by the user, such as oracle.bi.server.impersonateUser or oracle.bi.server.manageRepository.
DISPLAYNAME	Used for Oracle BI Presentation Services. It contains the name that is displayed to the user in the greeting in the Oracle BI Presentation Services user interface. It is also saved as the author field for catalog objects. This variable is typically populated from the LDAP profile of the user.
PORTALPATH	Used for Oracle BI Presentation Services. It identifies the default dashboard the user sees when logging in (the user can override this preference after logged on).
LOGLEVEL	The value of LOGLEVEL (a number between 0 and 5) determines the logging level that the Oracle BI Server uses for user queries. This system session variable overrides a variable defined in the Users object in the Administration Tool. If the administrator user (defined upon install) has a Logging level defined as 4 and the session variable LOGLEVEL defined in the repository has a value of 0 (zero), the value of 0 applies.
REQUESTKEY	Used for Oracle BI Presentation Services. Any users with the same nonblank request key share the same Oracle BI Presentation Services cache entries. This tells Oracle BI Presentation Services that these users have identical content filters and security in the Oracle BI Server. Sharing Oracle BI Presentation Services cache entries is a way to minimize unnecessary communication with the Oracle BI Server.
SKIN	Determines certain elements of the look and feel of the Oracle BI Presentation Services user interface. The user can alter some elements of the user interface by picking a style when logged on to Oracle BI Presentation Services. The SKIN variable points to an Oracle BI Presentation Services folder that contains the nonalterable elements (for example, figures such as GIF files). Such directories begin with sk_. For example, if a folder were called sk_companyx, the SKIN variable would be set to companyx.
DESCRIPTION	Contains a description of the user, typically populated from the LDAP profile of the user.
USERLOCALE	Contains the locale of the user, typically populated from the LDAP profile of the user.
DISABLE_CACHE_HIT	Used to enable or disable Oracle BI Server result cache hits. This variable has a possible value of 0 or 1.
DISABLE_CACHE_SEED	Used to enable or disable Oracle BI Server result cache seeding. This variable has a possible value of 0 or 1.
DISABLE_SUBREQUEST_CACHE	Used to enable or disable Oracle BI Server subrequest cache hits and seeding. This variable has a possible value of 0 or 1.
SELECT_PHYSICAL	Identifies the query as a SELECT_PHYSICAL query..
DISABLE_PLAN_CACHE_HIT	Used to enable or disable Oracle BI Server plan cache hits. This variable has a possible value of 0 or 1.
DISABLE_PLAN_CACHE_SEED	Used to enable or disable Oracle BI Server plan cache seeding. This variable has a possible value of 0 or 1.
TIMEZONE	Contains the time zone of the user, typically populated from the LDAP profile of the user.

The SELECT_PHYSICAL command provides the functionality to directly query objects in the Physical layer of the metadata repository, and to nest such a statement within a query against the Business Model and Mapping layer or the Presentation layer.

Syntax for the SELECT_PHYSICAL Statement

Basic syntax for SELECT_PHYSICAL queries is equivalent to  basic syntax of select statement  with the term

SELECT_PHYSICAL replacing the word SELECT, namely:

SELECT_PHYSICAL [DISTINCT] select_list
FROM from_clause
[WHERE search_condition]
[GROUP BY column {, column}
     [HAVING search_condition]]
[ORDER BY column {, column}] 

 Source:

http://download.oracle.com/docs/cd/E14571_01/bi.1111/e10540/variables.htm#BIEMG3104