OBIEE Dashboard & Report Design Challenges & Tips

By Kevin McGinley, Accenture

In the book that I co-authored with Amy Mayer, Oracle BI Enterprise Edition Dashboard & Report Design Best Practices, we laid out a number of things you can do when building dashboards and reports in Oracle Business Intelligence Enterprise Edition (OBIEE) to give them a clean, crisp look and optimize their effectiveness. This article will build upon that premise, targeting a few key areas I see users having challenges in OBIEE. Those areas are: 1. Avoiding the Wheres Waldo effect 2. Dashboard page arrangement 3. Dashboard prompt performance 4. Understanding the Answers subject areas 5. Developing bad habits in Answers 6. Managing report development 7. The artistic side of BI Please note: I presented this content at Oracle OpenWorld 2010 under the session name Oracle Business Intelligence Dashboard Best Practices. The same is true with dashboards like the one in Figure 1. How do you derive any insight from a dashboard like that? Where are you supposed to look first? Which prompt are you supposed to use? There are too many options and too many cells for it to be of any value to the average user. Remember what a dashboard is supposed to be (according to Wikipedia): provides decision makers with the input necessary to drive the business. may be laid out to track the flows inherent in the business processes that they monitor. user interface that (similar to an automobiles dashboard) is designed to be easy to read. Graphically, users may see the high-level processes and then drill down into low level data. The key takeaways are that a dashboard should contain business relevant information that is easy to read and is presented at a high level, with the ability to drill down into detailed information when needed. The Wheres Waldo dashboard is quite the opposite; its the throw-everythingup-there-and-see-what-sticks model. Now, I can already hear the objection youre thinking: But thats what the users asked for. Its a common argument and in a world of IT order-takers, a fair one. But it isnt one you have to live with. Here are some tips to get around this problem: 1. Be prescriptive users are often asking for things from their limited Excel spreadsheet experiences, but as a BI professional, you know better. Dont hesitate to recommend best practices to the business. 2. Prototype positive role models in the traditional IT development cycle, requirements gathering is all about interviews and note taking, but you can actually use OBIEE to build quick prototypes to zero-in on requirements much faster. Introduce the tool early in the project. 3. Use iterative build cycles much like #2 above, I often see BI follow the traditional development lifecycle of requirements/design/build/test. But BI is a little different than your average IT project and sometimes users dont know exactly what they want until they can see something to poke holes in. OBIEE development is fast; get the users feedback during build reviews instead of waiting for testing. 4. Talk training Wheres Waldo dashboards require much more training than their easy-to-use counterparts.

aVOIDING THE wHEREs walDO EFFECT

I see it everywhere I go: giant dashboards with one mega report and one mega prompt:

Figure 1: Look familiar?

I call it the Wheres Waldo dashboard. If youre not familiar with the popular childrens game/book, Waldo is a normal guy with glasses, a striped shirt, and a hat. This unassuming man is then placed somewhere in a very dense picture and your job is to find him. Sometimes this is an easy task, other times you might spend an hour trying to calm your child while you pull your hair out because you cant find him.

24 | Fourth Quarter 2010 | ODTUG Technical Journal

5. Talk performance Wheres Waldo dashboards are more likely to have performance issues, and spending your time trying to tune them is not the best use of your time. 6. Ask, so what? if the insights arent readily apparent on the dashboard, or it isnt obvious what the user should look at next, then it isnt a very good dashboard design.

DasHBOaRD PaGE aRRaNGEMENT

Heres a common problem: the OBIEE team has figured out how to use a session variable to default users to a specific dashboard when they login, but they cant figure out how to direct them to a specific dashboard page (tab) other than the first one. If a user doesnt care about that first dashboard, he needlessly executes the requests on that dashboard, wasting precious server and database resources. Sadly, there is no way to set a default dashboard page when accessing a dashboard; a user will always land on the first page. You can direct a user to a specific page if youre using a portal or similar technology, but that explanation is for a different article. Instead what you can do is build a landing page or a home page as the first page on the dashboard. This page will have low-latency information, like data refresh dates, document links, help links, news about new features, and more. Low-latency means that the dashboard page does not have to execute large database queries to display the information. The information is either hard-coded text or dynamic text from small tables, like ETL control tables. An example is shown in Figure 2 below:

There is no single solution to this challenge, but the two more obvious solutions are 1) only use constrain when you really need it, or 2) break-up the prompt into multiple prompts to avoid joins to the fact table (for example, place Region and District in their own prompt). If you think about the first option, it really boils down to the purpose of constrain on a prompt avoiding No Results on the dashboard. But No Results can sometimes be an insight itself, or you may not want to suffer the performance hit in the offchance a user does pick an invalid combination, so there are reasons to avoid using constrain. There is another option, though. This option is based on how OBIEE performs the filtering of a report by a value selected in a prompt. When a user selects a value in a prompt, OBIEE appends a WHERE clause to the logical SQL generated by the request. The WHERE clause is comprised of three things: the table.column name, the condition, and the value(s) all of which come from the prompt. This means that if the table.column name stays the same from the prompt to the request, it doesnt matter which subject area each comes from. OBIEE can use a column from subject area A to filter a report from subject area B as long as the full table.column name is the same in both subject areas. This allows for the construction of a prompt table and prompt subject area based on your most commonly used columns in your dashboard prompts. The table itself, an example shown in Figure 3 below, is nothing more than a factless aggregate fact table with keys replaced by descriptions the descriptions prompts typically prompt on. You build this table by picking the fact table that best represents the type of intersection you need and selecting all of the distinct combinations of dimensional attributes from that table for the prompt columns you need. This will likely be a smaller table than the fact table because it will probably be aggregated across one or more dimensions, due to the fact that good prompts generally arent prompting for the lowest level values across all dimensions. The smaller size, combined with the lack of a need to join it to another table to retrieve description values, means it should be able to constrain very quickly.

OBIEE Dashboard . . . (Continued)

Figure 2: An example low-latency Home Page as the first page on a dashboard

DasHBOaRD PROMPT PERFORMaNCE

Another area where users face challenges on a dashboard is with the performance of prompts (especially large ones like Figure 1). This challenge can often be attributed to the use of the constrain feature in the prompt builder. Whats often not understood about this feature is that it doesnt just constrain the columns that make sense (show only the Districts in the selected Region), but it constrains across the entire prompt. When combining attributes on a single prompt from multiple dimensions, the only way to perform this constraint is to query through the fact table to find the proper intersections. The problem is, the prompt builder doesnt choose which fact table to perform the intersection, OBIEE does, which can lead to unintended constraints. Since the constraint query has to perform joins to a fact table, performance can sometimes suffer.

Figure 3: Example prompt table pre-constrains the distinct prompted descriptions from a given fact/dimension table join

Once your table is built (and refreshed as needed), the next step in the exercise is to build metadata against the table, remembering to use the same table.column names that are used in the presentation/business models that already exist to build your reports. The last step is to build the prompt off your new subject area, rather than the subject area(s) you use to build the reports.

Fourth Quarter 2010 | ODTUG Technical Journal | 25

Whats nice about this approach is that you can build as many of these tables/subject areas as you need based on the fact tables you need to constrain through, and you can also hide these subject areas from Answers users through Manage Privileges if needed.

UNDERsTaNDING THE aNswERs sUBJECT aREas

OBIEE Dashboard . . . (Continued)

One struggle that users often face is the complexity of the subject areas built by IT in the metadata repository. Sometimes even IT developers struggle with the definitions of columns and where they come from. In one of the patch releases of OBIEE 10g, Oracle introduced a feature called the Answers Metadata Dictionary. The dictionary is basically a giant wiki that allows you navigate through the three layers of the metadata using hyperlinks to understand how a column is defined and how it came to be. Users can access the wiki through Answers by hovering over a column in the pick-list and clicking the icon that appears. The interaction is shown across the screenshots in Figures 4a-c:

To build the dictionary and allow your users to access it, you follow must follow these steps: 1. Export the dictionary using the Admin tool (Tools > Utilities) 2. Copy the output to a directory accessible to the presentation server 3. Edit the instanceconfig.xml to reflect the location of the dictionary (the path in blue might be different in your environment) a. SubjectAreaMetadata> <DictionaryURLPrefix>/analytics/res/dictionary/</Dic tionaryURLPrefix> </SubjectAreaMetadata> 4. Restart the presentation server Every time you promote a new RPD to production, simply execute steps #1 and #2 again to refresh the static pages. You can also choose to limit the users or groups who can view the metadata dictionary through Manage Privileges in the front-end administration area.

DEVElOPING BaD HaBITs IN aNswERs

Figure 4a-c: Clicking the icon beside 8-X1 Book to Bill Ratio opens the wiki and hyperlinks offer the ability to drill down into more details, like underlying formulas and physical tables

While Answers is a powerful tool to build ad hoc queries and presentation views with, there are definitely ways to abuse that power. Unfortunately, these abuses can lead to poor performance for end users. Here is a laundry list of things you can do in Answers to clean up these bad habits: 1. Avoid report criteria overload. Its very easy to build a request with more columns in the criteria tab that what is actually needed in the views on the compound layout. Unfortunately, those extra columns can be included in the physical SQL and affect the performance of the entire request. Make sure to clean up your criteria tab once youve settled on your compound layout. 2. A compound layout does not equal a dashboard. Because of the flexible nature of the compound layout, I see many developers try to build their entire dashboard in the compound layout and then add just the one report in the dashboard editor. This is

26 | Fourth Quarter 2010 | ODTUG Technical Journal

problematic for several reasons. First, a compound layout is retrieved all at once, whereas multiple reports on a dashboard can display when they are finished, regardless of the status of other running reports. Second, a dashboard-like compound layout typically requires including a lot of columns in the criteria tab, which can affect the performance of the request. And finally, its harder to control the space a giant compound layout occupies on a dashboard. You may introduce unwanted horizontal scrolling. 3. Is Prompted filters can wreak havoc in Answers. While most developers are taught to use the Is Prompted option when having dashboard prompts influence request filters, what few people think about is what happens when a user with Answers access runs that report from the shared folder in Answers. If all or most of the filters are set to Is Prompted, then its possible the report may try to pull back a large amount of data. What some developers dont realize is that a dashboard prompt can still influence a filter using a condition other than Is Prompted. In fact, Is Prompted is not required at all. Just by the existence of a filter on the report is enough for a prompt to influence it (unless you protect the filter). That means you can have your filters set to hard-coded values (or even better dynamic variables) for the users who launch it from Answers and still allow those accessing the report via Dashboards to control the filtering with a dashboard prompt. 4. Know when to use a table versus a pivot table. I see a number of developers build pivot tables by default, even when a pivot table is not required. If you ask them why, sometimes youll get an answer like, I always build pivot tables. While there is nothing inherently wrong with a pivot table, its important to understand that each view behaves differently, and there are reasons why you may not want to use a pivot table, especially if youre not using the pivot functionality. Those reasons may include, but are not limited to, pivot tables automatically return all rows at once, pivot tables generate different physical SQL, pivot tables do not allow users to change the sort option on the dashboard, and more. The important thing is that you use the right view for the job, not just the view you like to use the most.

Most administrators of OBIEE are familiar with the Usage Tracking feature that creates a log of all the reports users have accessed over time. This feature can also write the contents of the log into a database table for querying through OBIEE; Oracle even provides pre-built metadata and some sample reports if you choose this option. If you dont have Usage Tracking turned on, its a good idea to do so. The minimal overhead it adds to the entire environment is worth the added value of knowing what your users are doing in the system. What administrators are less familiar with is the option in Catalog Manager to generate reports, or flat files, with contents from the OBIEE catalog (see figure 5 below). Using this feature, you can create files that detail every report and every dashboard in the catalog and the relationships between them. If youre handy with SQL*Loader for Oracle databases (or the equivalent for your favorite database), you can also load these files into database tables for querying through OBIEE. With a little metadata work, you can even join this information to the Usage Tracking table on the SAW_SRC_PATH field so you can view richer content alongside the Usage Tracking information, including what reports in the catalog are not being run at all. Now that we have a way for administrators to under-

OBIEE Dashboard . . . (Continued)

MaNaGING REPORT DEVElOPMENT

One of the most challenging aspects about growing a BI environment within an organization is the accumulation of content within the system. Its not uncommon for organizations to amass thousands upon thousands of reports and lose touch with what they have, who accesses them, and what isnt being used. Contributing to this challenge is the question of who should develop reports and how. Should business users develop reports, or just IT? And if business users do develop reports, how does IT keep the number of reports they have to support from spiralling out of control? These are all good questions; lets try to tackle them in an orderly fashion. First, lets deal with the issue of knowing what reports you have, who access them, and which ones arent being used. For the sake of simplicity, I will refer to the generic term reports to represent the larger category of content the end-users access in OBIEE.

Figure 5: Creating a report in Catalog Manager to export a list of your reports and dashboards

stand what is out there, what is being used, and what isnt being used, we can now turn to the question of how to keep the volume to a useful, manageable level. To address this question, we must first take a look at the most commonly used report development models available to us, as shown in Figure 6:

Fourth Quarter 2010 | ODTUG Technical Journal | 27

are responsible for their personal reports after the upgrade is completed. The second type of report is, of course, the standard report. These reports are: Built in development Saved in secured Shared folders Are governed for standards and best practices Are supported

OBIEE Dashboard . . . (Continued)

Figure 6: The most common report development models used in BI

So which model is the best? Sadly, there is no easy answer to that question. Each one can work well when implemented properly. The key to deciding which one to use in your organization is to look at a few factors: 1. Does IT or the Business have the bandwidth to own development entirely? 2. Does the Business have the aptitude and/or the skills required to participate in development? 3. What is the historical precedence? Was it successful? 4. What level of collaboration exists between IT and the Business? All of these factors come into play when deciding which model to leverage in your organization. The good news is, youre not stuck with one model forever, nor are you limited to a single model at one time. Some organizations will implement one model with one group of Business users, and another model with another group. These three models arent a secret or a new revelation, either. But laying them out in a diagram like Figure 6 emphasizes the fact that IT and the Business tend to build reports in different places and different ways. Because of this, its critical for IT to differentiate between two different types of reports when the Business is involved in development: Personal reports and Standard reports. Personal reports are: Built in production Saved in the My Folders area (or a small group Shared folder) Not governed for standards and best practices Not supported That last bullet point is often overlooked. When companies upgrade their BI environment or move to a new platform, the first thing that happens is to take an inventory of the reports to determine what the scope of the upgrade is. This usually results in thousands of reports being identified, with a lengthy process to determine where reports are duplicated and what isnt being used anymore. Many of the reports that are analyzed and sometimes even upgraded are reports built by individuals for themselves or a small audience. These are personal reports and should not be included in the scope of what IT supports because it is very costly for IT to support little one-off reports that a user created on a whim and will never use again. Dont analyze them for an upgrade; inform users (through SLAs) that they

That third bullet is key, because this is the bullet that allows even a large number of standard reports to be manageable. Make someone own this bullet. Call them a report gatekeeper or something similar. Their job is to make sure that new reports dont already exist somewhere else, that they push calculations to the metadata as often as possible, and that they are following standards. What kind of standards? Standards around: Properties (colors, fonts, alignments) Data (formats, symbols) Layout (headers, footers) Visualizations/Views Prompts/Controls Which tool to use when (answers, BI Publisher)

This person also needs to make sure that developers arent using too many crazy workarounds to meet requirements. OBIEE is a very flexible tool, and very smart people have written many blogs on the internet demonstrating how you can make OBIEE bend this way and that way to meet a requirement, but the constant use of workarounds creates a support nightmare. This report gatekeeper needs to make sure that all workarounds are reviewed, approved, documented, and re-addressed during upgrades to see if the workaround can be eliminated. At the end of the day, as long as you have a process for Business users to promote their personal reports to standard reports, its very easy to have SLAs that differentiate how you manage one-off reports that benefit the few versus standard reports that large numbers of users rely on consistently.

THE aRTIsTIC sIDE OF BI

I recently read an interview that discussed why Apple and Steve Jobs are so unique and successful at what they do. The conclusion, according to the person being interviewed, was one single word: design. Apple is first and foremost a design company, not a technology company. BI developers should take note, because BI is one of the few IT disciplines that is as much an art as it is a science. Its one thing to identify and collect the data to be reported, but its quite another to determine how to present that data in such a way that makes it easy to use and attractive to look at. How do you achieve this? The table below offers some tangible solutions.

28 | Fourth Quarter 2010 | ODTUG Technical Journal

Most importantly: get feedback. And not just from your business users or fellow BI developers, but also from your spouse and your friend on the web developer team. Using BI is a lot like using the web, and it needs to be so simple that even your spouse can use it. Yes, that same spouse who cant really describe what it is you actually do for a living

sUMMaRY

OBIEE Dashboard . . . (Continued)

Figure 7: BI design balances ease of use against an attractive, engaging design

OBIEE is a fantastic BI tool that has a lot of potential to transform how business people gain business insight within your organization. But like any tool, its very easy to abuse it and let the environment spiral out of control. Someone once told me, I want you to tell me how to create an OBI environment that I dont have worry about. Thats the wrong mentality. You must be intentional, purposeful, and relevant when growing a successful Oracle BI environment. Manage it; dont let it manage you.

emb

er

about The author

Kevin McGinley has been helping companies large and small implement BI and Data Warehousing for the last fourteen years. He has co-authored one of the few books available on best practices for Oracle BI Enterprise Edition and is a Senior Manager in Accentures Oracle BI practice. Kevin can be contacted by emailing him at kevin.mcginley@accenture.com.

Fourth Quarter 2010 | ODTUG Technical Journal | 29