Accessing Groups in LDAP for use in Oracle Business Intelligence

This one is useful if you’re trying to set-up BI to work with LDAP

Oracle BI allows for integration with LDAP servers for authentication and security
out-of-the-box. This document articulates the solution for retrieving Security Groups
defined within LDAP and reuses them within the context of Oracle BI repository
seamlessly. This document assumes that the users are using an Oracle Database and can
leverage the DBMS_LDAP package built into the Oracle Database for this

Typically Organizations use LDAP servers as a central infrastructure for storing the
Users security credentials and use these servers to authenticate and authorize users
access to various applications within the organization. Tapping into this security
infrastructure helps the organization maintain its security in a central infrastructure.

Currently, OBI EE can connect to an LDAP server and authenticate a user with
user and password credentials, but it is limited in its ability to extract the groups
defined within the LDAP server and to leverage these groups in the repository.

Scope and Application

The work around suggested in this paper would allow the admin to reuse the
groups in the LDAP server using the DBMS_LDAP package available within the
Oracle Database.

Accessing Groups in LDAP for use in Oracle Business Intelligence

The goal is to allow access to the Users and Groups defined within LDAP Server,
without having to redefine these in a database. This allows the enterprise to
leverage a single common security infrastructure and allows OBI EE to plug into
this infrastructure.
The following are the high level steps to access the Groups defined within the
LDAP server.
1. Using the DBMS_LDAP package provided within the Oracle Database,
write a stored function to connect to the LDAP Server and expose the
Groups as a virtual table.
This PL/SQL package creates a virtual table within the database, which acts as
a gateway to LDAP server. It is now possible to write queries in standard SQL
form to this virtual table that would in turn be translated to the LDAP server.
2. Provide parameters needed to connect to LDAP for authentication. In
order to do this, open the Administration Tool used for managing the
OBI EE repository. From Manage -> Security -> LDAP Servers menu,
provide the necessary parameters needed to connect to the LDAP Server.
(for additional details follow the steps detailed in the Server Admin Guide
for OBI EE).

The above picture is a sample of properties required for connecting to a LDAP
3. The next step is to create a Session Initialization Block within the OBI EE
Admin tool and wire the LDAP server property to this initialization block.
The user id defined in the LDAP server should be associated with the “USER”
session variable. USER is a system session variable within the Oracle BI stack
and is used to store the USER information entered during login from the
presentation server.

4. Next, create another initialization block within the OBI EE Admin tool to
store the Group information. The group information will be queried from
the Virtual Table (defined as part of stored procedure/function defined in
step 1) and to get the group information using row-wise initialization. This
Initialization block should be executed after the Initialization block
defined in the previous step.

The screen shot above shows an example of the SQL query being passed to
the Oracle DB where the PL/SQL stored procedure (from step 1) was created
and extracting the Group information stored in LDAP using row-wise

Parameter For Max Number Of Rows Not Taken Into Account

This is probably helpful for someone who migrated from OBIEE 10G to 11G and need to retain the same settings. I’m still wondering who needs to see reports with 500k rows, but still.

In OBIEE 10g the ResultRowLimit was working with a value of 5,000,000 (65,000 is the default value).

We have tried to do the same in 11g through EM > BI > Core application > Capacity Management >

Performance > Maximal number of rows in a tabular view set from 65,000 to 5,000,000.

The Servers have been restarted and the report is still not running.

The SQL query fetches less than 200,000 rows. i.e. one of our reports is 172,310 rows.

Impact on Business:
This problem impacts a lot of reports through the National Healthcare agency.
These reports used to work in 10g.

View Display Error

Exceeded configured maximum number of allowed input records.
Error Details
Error Codes: EKMT3FK5:OI2DL65P
Location: saw.httpserver.processrequest, saw.rpc.server.responder, saw.rpc.server,

saw.rpc.server.handleConnection, saw.rpc.server.dispatch, saw.threadpool, saw.threadpool, saw.threads
SQL Issued: 858~k1vsg0egoo7i60qhn13qv8lj52

Moreover, the same matter occurs in a report with 49220 lines fetched from Database.

Could it be linked to the fact that these reports use a pivot table to perform a second aggregation phase?

The final Pivot view is about 10 columns by 10 lines.
The Number of Rows setting was verified within OBIEE

Capacity Management > Performance

Maximum Number of Rows Processed when Rendering a Table View

This setting limits how much data is retrieved from the BI Server and processed. The default value is 65000.

Reducing the maximum number of rows processed can significantly improve performance by reducing the system resources that can be consumed by a given user session.

Number of Rows 65000

It was found that the cause was the Pivot Table (which generally have more performance overheads when compared to a standard Table).
Within the instanceconfig.xml file in 10g you would have had to adjust the limits in your file for the parameters below.

In OBIEE 11g, these values below are discussed in the following Guides.

Oracle Fusion Middleware System Administrator’s Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1) E10541-02

18.3.1 Manually Configuring for Data in Views

If changes are made to the instanceconfig.xml file please carefully refer to the section stated below:
(Section 3.4, “Using a Text Editor to Update Configuration Settings.”)

When the following changes were made to the instanceconfig.xml file, this fixed the issue.


Oracle suggests that “These values were specific to this environment and the reports being run by that organisation. Other readers should note that increasing these values to too high a level may have an impact on performance (which is hardware dependent).”