Advertisements

Creating a Custom Landing Page or Custom Home Page for your OBIEE / OBIA environment

Your organization may want to have a custom home page or landing page for your OBIEE or OBIA environment.  (I will use the term “Landing Page” going forward to not confuse it with the OBIEE delivered “Home Page”).  When users log in, they need to be automatically taken to this custom landing page instead of to the delivered OBIEE Home Page.

This post describes some of the reasons you may want a custom landing page, the content that could be on the page, how to automatically navigate users to the page, and security associated with the page.

Why would you want to create a Custom Landing Page?  The reasons will vary by organization, but these could be some of the reasons:

  1. Deliver the look and feel that your company or users desire.
  2. Allow for a place that serves as a central location for the content you want to emphasize, in the way you want to display it.
  3. Provide a central place for messages of any kind for your users.

What content will be on this Custom Landing Page?  Some of the possibilities are:

  1. Create a page with your custom logos, images, and colors that are in line with your company’s or department’s branding.
  2. A section with messages for your user community. This information could include things such as:
    1. The date/time of the last data load?
    2. The sources of the information displayed on your dashboards
    3. Information about recent dashboard releases
    4. Upcoming downtime
    5. Upcoming events such as user training events
    6. Action needed by the user community
  3. A section that lists links to useful resources, such as:
    1. user’s guides or tutorials
    2. dashboard and report glossary
    3. analysis/report request forms
    4. Security/Access Request forms
    5. general OBI information
  4. A section with Contact Information – containing information about who, what, when, how to contact people for help or information, or how to submit new requests for data/analyses/reports, maybe by functional area, etc.
  5. An area to display your company’s or division’s top key performance indicators (KPIs). These should be limited to just a few – I would say not more than 5 – and they should be relevant company-wide or “OBI user community-wide”.
  6. Links to dashboards. You may create an area or areas of links to various dashboards. Your dashboard list may include many of your dashboards or just a select few that you know are frequently used or that you want to emphasize.

All users that are authorized to use the OBI system will have access to this page.  So, maybe BI Consumer role will be provided access.

However, you will need to set security on the sections containing links to dashboards to allow access only to those authorized for the each set of dashboards.

Once your custom landing page is ready, you will then need to set it as the default page for users (or a subset of users).  To do this you will need to create an initialization block that sets the PORTALPATH built-in OBI variable to point to the new landing page dashboard page.

One final note … you can have multiple custom landing pages if you desire, for example, a different page for each division or a different page for each major group of users.  You would then need to set the PORTALPATH variable based on the user’s profile.

Good luck with your custom landing page project.

Advertisements

OBIEE Performance Tuning

This post describes a few tips and things to keep in mind for OBIEE Performance Tuning.

Be Proactive when possible
The need to performance tune can be proactive (tune before a major issue arises) or reactive (tune after a problem is reported by users for example).  It is best to be proactive – so performance tuning should be built into your OBIEE maintenance schedule. For example, OBIEE’s Usage Tracking functionality should be used regularly to identify reports whose performance can be improved and then performance steps should be carried out on the worst performers.

Iterative Process – change one thing or set of things at a time
One of the first things to keep in mind is that performance tuning is an iterative process.  And there is typically no one silver bullet that will resolve all your performance problems.  You may need to analyze and make changes to multiple parts of the system, but you want to make the changes methodically.  It is best to change one parameter or setting at the same time (or one related set of parameters).  Adjust and test the settings for that one parameter/setting (or set of parameters) before moving on to another.  If you change too much at one time, you may have a difficulty determining what is helping from what is hurting your efforts.

Fix user complaints first, worst performers next, and then the next bad performers down the list
Another thing to keep in mind, tune what users are reporting first, then tune the worst problems second, then move on to the next.

Team Effort – problem could be anywhere along the technology stack
Performance problems could be anywhere along the technology stack:
• OBIEE
• Database
• Server
• Network
Due to that span of technology, performance tuning is a team effort.  OBIEE Admins and Developers, DBAs, and ETL Developers can all be key to solving performance issues.
Logs from all components may need to be reviewed depending on the scenario.

Try to isolate or narrow-down the source of the problem
For example, run the report SQL directly on the database and see if you have the same problem. If there is no issue when run directly on that the database, then you have eliminated the database as the problem.
Determine if other applications have been also been experiencing slowness which could indicate the possibility of a network problem.

If your users have reported an issue, then you need to get as much details as possible about the performance problems they are experiencing.  When did this start happening?  Is it just one report or many?  Is it localized to one business area or multiple?  Is it all the time or sometimes?  Knowing this will help you to know where to focus.

Other questions to ask as you try to identify the source of the problem include but not limited to:
Has anything changed?  If reports were running fine, but are now slow, the first thing to ask is …
When the issue start?  Determining exactly when it started might be helpful when correlating with other system or company activity)
What has changed recently?  Has there been any system changes, data changes, database updates, network changes, etc. (even if they seem unrelated)?  For example, rolling into a new calendar year will cause new “Year” value(s) to be included in the data and can impact performance if statistics are not gathered.
Is there a possibility that an index was dropped and not recreated as expected?

Use OBIEE’s Usage Tracking information to analyze specific reports, analyze long running reports, or frequently run reports.  You will want to capture and analyze the SQL from these reports to determine what can be done to improve their performance.

Database
DBAs can monitor the system in real-time, use various tools, or review logs for information that can be helpful in the tuning effort.  Tools such as Oracle Enterprise Manager (EM) or SQL Tuning Advisor can be used to identify, analyze and tune high-load SQL.
OBIEE Usage Tracking can also be used to identify high-load SQL.
Without getting into much detail, these are some database features that could be used to help improve performance:
• Gather Statistics
• Results Cache database feature
• Partitioning

Servers
The System Admins can monitor the server resources to determine if there is an issue there.
• Use fast disk for the OBIEE cache and/or temporary files.

 

OBIEE-specific performance tuning tips

• OBIEE Caching
Are the tables being used set to cacheable?
Is caching turned on at the application level?
You may consider seeding the cache daily.
CACHE Settings:
o MAX_ROWS_PER_CACHE_ENTRY
o MAX_CACHE_ENTRY_SIZE
o MAX_CACHE_ENTRIES
o ——————-
o USE_ADVANCED_HIT_DETECTION

• Use Aggregation: Aggregate data when applicable
o You can use Aggregate tables or materialized views to realize this benefit.
o Aggregate Fact tables and corresponding Aggregate Dimensions.
o Make sure aggregation rules are applied to Fact table measures.
o Don’t necessarily merge all measures into a single fact.

• Joins and Indexes
o Do not create unnecessary joins.
o Verify that the joins on the tables being investigated are appropriate.
o Performance Indexing could be helpful.  Again, this is an iterative process.

• Prompts and Filters
o Use LOV tables to drive prompt values when possible, instead of building prompts from large transactional data tables.
o Force filter selection / entry by making prompt values required.  Do not allow open ended run of reports.

• Filter out unneeded data.  If there is a significant amount of data that is not being used in one or more tables (especially if they are frequently used), then that data should be filtered out by the ETL before it gets joined in SQL, and then has to be filtered out in the RPD or at the report level.

• Enter the “Number of Elements at this level” value in the logical level in hierarchies.
• Also ensure that all logical level keys are unique.

• Avoid function in the where clause when possible.

• Be careful of sub-queries.

• Check out the features of the OBIEE Performance Monitor
http://server:port/analytics/saw.dll?Perfmon  (enter your OBI server and port)

• When possible, do comparison analysis to determine for example, why is this report running fine, but this other seemingly similar report is not.

• Use fast disk for the OBIEE cache and/or temporary files.

Sometimes a complete overhaul might be required
Review the users’ workflow and determine if new and improved queries can be written or if the number of queries can be reduced.
Present information from a summary level first, and then provide increasing levels of details as requested by users through drill down or navigation.  Basically, present detailed information only when necessary, and minimize the amount of detail provided at a time by filtering on user selections.

Oracle’s OBIEE Performance Tuning Guide
Apply recommendations from the “Best Practices Guide for Infrastructure Tuning Oracle® Business Intelligence Enterprise Edition 11g Release”.  I would recommend applying 1 – 3 changes or set of changes at a time; don’t apply everything at the same time because if there is a problem, it will be more difficult to determine which change caused it.
https://blogs.oracle.com/proactivesupportEPM/entry/wp_obiee_tuning_guide

New OBIEE Tuning Guide (Version 4) – released Jan 2014

A new version of the OBIEE Tuning Guide (Version 4) was released in January, 2014.  It is suitable for OBIEE 11.1.1.6 and 11.1.1.7 versions.

It can be found on Oracle Support under Document ID 1333049.1.   Or here is a direct link to the document (PDF).

—————————————-

New highlights from the previous document include:

  •     Optimized JVM switches for JRockit / Sun JVM / IBM JVM
  •     New tuning parameters settings / values for JavaHost / OPIS / OBIS components.
  •     Improved performance monitoring techniques.
  •     IBM WebSphere tuning parameters.
  •     More WebLogic Server tuning parameters.
  •     Windows Server 2012 tuning parameter.
  •     New optimized Linux / AIX tuning parameters.
  •     Additional Essbase ASO tuning parameters.
  •     libOVD authenticator search tuning

—————————————-

As always, this document provides us with recommended baselines or starting points, but the appropriate settings for each environment will vary.

It’s all about the users – Identifying Users for your OBIEE application

One of the first things you will need to do before developing your Oracle Business Intelligence (OBIEE) application is … identify who will use it.  You need to identify who will be using the application – what business areas they belong to, what groups they belong to, what are the various functions or roles within those groups, and eventually, who are the actual people.  After identifying the various roles (groups of users typically associated with a business process or function), then you can identify their needs.  Starting any development before knowing who will be using the system could result in a lot of wasted time and effort or a sub-optimal system.  The grouping of information on dashboards, the available functionality and security will be driven by these roles and their respective needs.

After identifying the various functions or roles that users posses, then it is important to understand how each role performs their job functions.  You need to understand what information they need and in what order, how it’s used, and the level of detail required at various stages. With this information, you will determine the dashboards, dashboard pages and their order, the information on each dashboard page and its precedence and level of detail, and what detailed information is needed via drill down. Basically, you will be creating the analytic workflows for the identified roles and the various processes, functions and tasks that they perform.

When performing the above exercise, please be as discrete as possible.  For example, even if someone doubles as an AP/AR Analyst, you should still analyze and plan for 2 separate roles – AP Analyst and AR Analyst – because those are 2 separate functions.  Later, the individual or group can be granted permissions to both roles.  From a security standpoint in general, you will create the necessary OBIEE application roles to support your business roles.  And then assign security based on these roles.

In general, always keep the focus on the users, what they need to accomplish, and the most efficient ways to help them perform their job.  When you build the OBI system to meet those needs and usage scenarios, it will result in higher and faster user adoption.  This will take time, so do not rush the process.  Get detailed information about all the steps in their workflow upfront, document it, and then build around it.  However, on the other hand, you do not have to document to perfection upfront, you can take a more agile approach of developing based on fairly good user profiles to give users working prototypes, and then adjusting as new information and feedback is received from the users.

Good luck identifying your users and their needs as you get your OBIEE project rolling.  And remember, it’s all about the users!

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.

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.

Data Federation, Horizontal Federation and Vertical Federation in OBIEE

Data Federation is the process of and implementation of integrating metadata from multiple data sources into a single metadata database to allow for the integrated reporting of the data from those multiple sources. In OBIEE terms, Data Federation involves bringing in the metadata from multiple sources into the physical layer of the RPD (BI Repository) and integrating the metadata into a single business model and possibly a single subject area.  In OBIEE, the data sources can be relational (OLTP databases or star-schema data warehouses), multidimensional (OLAP), or files (such as Excel or flat files); and the data can be of varying levels of aggregation in these sources.  This is one of the most powerful features of OBIEE.

When an Analysis (report) is run from Answers that uses data from these sources, the BI Server creates the appropriate SQL (OLTP) or MDX (OLAP) statements to retrieve the data from the appropriate source and then integrates the data for display to the user.  The user does not need to know what the source of the data is, how many sources there are, or how the data is retrieved.

There are two common patterns of how data can be federated in OBIEE for reporting – these patterns/methods are termed Horizontal Federation and Vertical Federation. I will explain them here.

Horizontal Federation involves setting multiple data sources for a common single logical table object in the Business Model and Mapping (BMM) layer of the RPD, such that the granularity of the data from the various sources is at the same level, and some columns of the single logical table come from one source, and some from another source(s) – basically each source adding columns (not rows) to the logical dataset.  A typical scenario for this pattern is where there is related data in multiple sources for a particular subject, but no single source holds the entire body of data for that subject – and this helps to bring all the descriptive data for the subject together into one.

Vertical Federation involves setting multiple data sources for a common single logical table object in the BMM layer of the RPD, such that the data for each columns could be coming from multiple sources, but at varying granularity levels – basically each set adding rows (not columns) to the logical dataset.  A typical scenario for this pattern is where data at an aggregated granularity is sourced from an aggregated OLAP data source or an aggregated OLTP data source, while data at a detailed granularity is sourced from the transaction level (OLTP or detailed-level star-schema) data source.