Author: normatthedatacommunity

Business Intelligence Platform, Data Security September 16, 2013October 10, 2019

Creating a new Security Realm in OBIEE 11g

When setting up security in OBIEE 11g, you may modify the default security realm (myrealm) that installs with OBIEE. But even better, you may create a new security realm and leave the default realm untouched.

My preference is to leave the default realm untouched and create a new realm – this is a best practice in my opinion. I think it is helpful to always be able to go back and look at the features and settings of the default security realm. And you can name your new security realm more appropriately, such as, ABCIncSecurityRealm.

The link below (Paul Cannon’s Blog) brings you to a blog post about configuring OBIEE to use LDAP authentication, and the first part of the post covers creating the new security realm. It is very detailed. I used it the first time I created a new security realm.

http://paulcannon-bi.blogspot.com/2012/07/configuring-ldap-authentication-for.html

Good luck creating your new security realm.

Business Intelligence, Business Intelligence (BI) Development, Business Intelligence Platform June 19, 2013October 10, 2019

How to collapse or minimize a dashboard section by default in OBIEE

In OBIEE, you can easily set a dashboard section to be “Collapsible” which allows a user to collapse or minimize that section when desired. By default, when a dashboard page is opened, the sections are maximized or expanded (i.e., not collapsed).

But what if you have a requirement to have a section minimized or collapsed by default? There is no flag or option to do that. This post shows you how to make a section minimized / collapsed by default.

I found the solution for making a dashboard section collapse by default here… http://www.orakelite.com/2013/01/iii-javascriptcss-tips-to-obiee-ui.html
However, the author did not include some details which I will cover here.

First, you need to make the section collapsible, by simply editing the dashboard…

… and then setting the “Collapsible” property of the relevant section.

You will need to add the following Java Script to the section you want to minimize by default.
The text highlighted in the Java Script is the Section ID of the section to be minimized by default. So first you will need to find this Section ID.
——–

var sectionId = “d:dashboard~p:ve9fga7bp3omltnr~s:9qfn1ms6bco9bsva“;
var sectionDiv = document.getElementById(“Embed”+sectionId);
var plusImg = document.getElementById(sectionId+”Max”);
var minusImg = document.getElementById(sectionId+”Min”);
var contentsTable = document.getElementById(sectionId+”Contents”);
minusImg.style.display = “none”;
contentsTable.style.display = “none”;
plusImg.style.display = “”;
sectionDiv.setAttribute(“minimized”, “true”);

——–
To determine the value of the Section ID, you need to go to the dashboard page and from the browser menu, select View –> Source.

Search for the section by name, or just search for the word “section”. This should help you to identify what Section ID is related to the section you are interested in. (In example below, the black arrow points to the SECTION ID, and the red arrow points to the user given section name that can be used to search. )

Use your Section ID in the Java Script code above.

Place the Java Script code in a “Text” dashboard object inside the section you want to control.

Save your dashboard page changes.

Now when you reopen the dashboard page, the section will be minimized / collapsed by default.

Business Intelligence (BI) Development, Business Intelligence Platform, Data Integration (ETL) May 28, 2013October 10, 2019

Informatica Transformations Frequently used in OBIA

These are some of the Informatica transformations that are frequently used in Oracle Business Intelligence Applications (OBIA). The OBIA SDE and SIL mappings used to load the Oracle Business Analytics Warehouse (OBAW) are built using these and other transformations.

1. Source Qualifier
The Source Qualifier transformation is used to bring data from one or more tables from the same source into the mapping. If being used for more than one table, then a join condition needs to be defined between the tables. The typical naming convention for a Source Qualifier transformation is SQ_* or sq_*.

2. Joiner
The Joiner transformation is used to join tables in different data sources. The typical naming convention for a Joiner transformation is JNR_* or jnr_*.

3. Expression
The Expression transformation is used to perform simple row-based calculations or derivations. The typical naming convention for an Expression transformation is EXP_* or exp_*.

4. Filter
The Filter transformation is similar to a where clause in SQL – it adds a conditional filter to the data passing through the mapping. The typical naming convention for a Filter transformation is FIL_* or fil_*.

5. Aggregator
The Aggregator transformation is used to perform aggregate calculations on the data passing through the mapping, for example, performing a sum or max. The typical naming convention for an Aggregator transformation is AGG_* or agg_*.

6. Lookup
The Lookup transformation is used to lookup values based on another known/submitted value, and pass the looked up value into the mapping. There are 2 types of Lookups – connected and unconnected. The typical naming convention for a Lookup transformation is LKP_* or lkp_*.

7. Update Strategy
The Update Strategy transformation is used to determine and perform the appropriate course of action for data in the mapping. Based on the determined state of the data, the transformation is used to insert, update, delete or reject records. The typical naming convention for an Update Strategy transformation is UPD_* or upd_*.

Business Intelligence, Reporting January 31, 2013March 1, 2020

Developing requirements for an OBIEE project

Eliciting and creating requirements for an OBIEE project is a very important step in creating a successful, pervasive OBIEE system in an organization.

Throughout the requirements elicitation and creation process, you need to keep in mind that all requirements must be testable. The only way to verify if a requirement has been met is to successfully test it, and therefore, all requirements must be specific and detailed enough to allow for a QA person to verify it.

A huge and essential component of OBIEE projects is the reports being delivered in one form or another – and therefore, another set of characteristics to keep in mind are that the reports and their form of delivery need to be: accurate, relevant, timely, and actionable.

Typically an OBIEE project involves significant effort, and can take several months to complete, but visible progress can be made in a shorter time. Requirements may need to be prioritized to handle the most critical ones first (a phase 1 for example), and postpone some for later in the project – a phase 2 for example. However, it should not take months to see some results, because OBIEE is a great platform for an agile methodology – allowing the project to show some results early and ongoing, as the project becomes more and more completed.

To elicit requirements, there are a number of methods that can be used. You will need to choose the most appropriate method based on the particular scenario – who is the user, what area does the requirements cover, etc. Some of the methods used can include: interviews, observation, reviewing existing reports (from a previous system for example); soliciting information from colleagues in other companies; and developing/showing report concepts and getting feedback; brainstorming – from strategic goals and reporting needs to tactical/operational. However, you should try to learn as much as possible about the business, processes and people beforehand; and always try to be a good listener.

Requirements for an OBIEE project can be grouped into the following groups of questions:

What information does the business users need to see?

This is often driven by the company’s strategic goals. The data needs to be in aid of answering business questions that users will need to aid their decision making in order to realize operational and tactical goals that support the strategic goals.

The information could be enterprise wide, departmental, or specific subject matter.

The reporting requirements could also be classified as strategic, tactical, or operational. The strategic requirements are usually enterprise wide, while the tactical and operational requirements are usually relevant to a departmental, group or individual role. Strategic requirements can at times be monitored and tracked via Key Performance Indicators (KPIs) which can be developed and presented in OBIEE. Operational requirements at times will need Agents or iBots that trigger some action based on an event. And tactical requirements are usually satisfied using reports that display valuable metrics about the business operations.

What are your business objectives and what metrics will help you to monitor progress toward those objectives? What information do you wish you had to do your job better?

Where will the data be sourced from? In other words, what are the source systems?

The answer to this question could include Data warehouses or data marts, ERP systems, Line of Business systems (LOBs), Flat files, External sources, OLTP, OLAP, etc.

The data sources need to be defined in the OBIEE BI Repository (RPD) via Connection Pools, and the metadata for the relevant tables imported. OBIEE data sources can be relational (OLTP), multi-dimensional (OLAP) or files (Excel, XML, ADF). The OLAP data sources supported by OBIEE are Oracle Essbase, Oracle OLAP, Microsoft SQL Server Analysis Services, and SAP BW.

However, for better performance, it is best if the data sources are multi-dimensional – either star-schema relational or OLAP.

What data is required from those systems? And what data needs to be calculated or derived?

Analysis needs to be done to determine what subset of data (if not all) is needed from each of the source systems. What measures, dimensions, hierarchies, and attributes are required? What lookup tables are required?

And it’s always a good idea to ask “Why?” Why is this data needed? How will it be used?

This involves reports, and it is important to keep in mind that all report/reporting data need to be accurate, relevant, timely, and actionable.

What data that is not in the source system but can be derived? Calculations, Associations, mappings, etc – these derived items can be created in the OBIEE repository BMM layer, and exposed to users as necessary.

What granularity of data is needed? Summary, Detail, both

What time range (including the time granularity) of data is needed? Historical, Current, Real-time, Day, Month, Quarter, Year

What KPI’s are required to track the state of the business?

What data needs to be filtered out/in from each data source tables in the various scenarios?

What are some of the frequently used filter criteria? à this could drive some of the repository variables created in OBIEE

What are some frequently used values for analysis? à this could drive dashboard prompts in OBIEE

Will the business users need to perform data mining or need the results of data mining?

How frequently does the data need to be updated?

If the data is not directly connected to the source, then how often should the data be updated – real-time, hourly, daily, weekly, monthly, on-demand, etc?

Who needs to see what data? And who needs access to what functionality?

This is in essence a security question. What are the various groups/roles that need access to data, and what data should each group/role have access to?

Can the reporting system be integrated with the company’s existing LDAP? This is typically the case for most modern reporting systems including OBIEE which integrates with popular LDAP systems including Active Directory.

Does row-level security need to be implemented? OBIEE allows for row-level security.

Can all users use all features of the reporting platform? Or will only specific users be granted access to specific functionality?

What dashboards and reports will each group of users be able to see?

How will the information be shared with business users? What modes of information delivery need to be used?

Will reports be shared? email, saved to a directory, web dashboard, file (pdf, word, excel, html)?

Do users need to be proactively notified of events? – for example, a user or group needs to be notified if stock levels fall below a threshold.

The answers to this question will drive the Agents/iBots that need to be created.

Will the reports be run on a predefined schedule or based on some predefined condition? Or will they be run on-demand? This will also drive Agents/iBots and Conditions.

Do users need to download information? This will drive the ‘report links’ that are placed on the dashboard pages.

Do report results need to be preserved or can/should they be overwritten?

Will users be allowed to create their own analyses or perform adhoc analysis? And if yes, how will that activity be monitored and supported?

What visualization features are required for each report or set of data? Dashboards, Scorecards, Charts, graphs, tables, pivots, gauges, icons, colors, fonts, etc.

Will the users need to be able to drill from summary to detail reports? Rollup from detail to summary?

Will the users be able to interact with the data? Prompts, View Selectors, Column Selectors, etc

What are some of the system level requirements?

What level of system performance is required?

Dashboard and report creation tools

Does the reporting system need to be able to access/connect to multiple data sources at a time? OBIEE allows for multiple data sources connected at the same time.
Does the reporting system need to be able to access/connect to relational, multi-dimensional, and file data sources?

Does the reporting system need data mining capabilities?

Does the system need to support drill-down, rollup functionality?

What are the critical usage times for the system? In other words, what are times when the system must be available? For example, during the month-end close process or during the holiday sales season. This will drive when changes can be made to the system.

What are the highest usage times for the system? What hardware do we need to support that usage?

How will changes be handled? In other words, what is the change control process?

It is very important that all the relevant players are included in the requirements process – business leaders and business users, SMEs, technical staff, database administrators, OBIEE Developers (report developers, rpd developers), OBIEE architect, ETL developers, ETL architect. Before development officially starts, it is important to get all relevant sign-offs on the requirements. This will ensure that everyone is on the same page, and that the business users are getting what they need.

This post will be a “living” document, as I will be coming back and updating this post from time to time to add more detail and more OBIEE specifics.