The new model takes the traditional universe and breaks it down into three components:  the Connection, the Data Foundation, and the Business Layer.  These components all existed in some form in previous versions, but now they each get their own editor and a host of new features and options.  Let’s review these in a bit more detail.  (Note that the screenshots below are from the ramp-up version of this software and could change in the final release).

The Connection

The Connection is a named set of parameters that define how one or more SAP BusinessObjects applications can access relational or OLAP databases.  The big news in the 4.0 release is that a universe can have multiple connections to different data sources!  Previously this was only possible with Data Federator, but federation is now built into the universe layer.  More on this in the next section…

From a designer’s perspective, perhaps the best change is that the Connection now gets a proper editor instead of the old wizard dialog from previous versions.  This interface is much easier to use, especially if you need to quickly change something about the connection, such as changing the driver from ODBC to OLE DB.  More importantly, there is a Show Values tab where you can browse the schema, view the data, and even do basic queries right from within the Design Tool.

The Data Foundation

The Data Foundation contains a schema of relevant tables and joins from one or more relational databases that are used as a basis for one or more  Business Layers.  This looks and feels much like the old universe designer tool, but with an improved interface.  Users of the previous version of Universe Designer know that the interface hasn’t changed much since the early days of BusinessObjects 5.x and 6.x, so this revamp is a welcomed change.

As expected, you use the Data Foundation editor to define your database structure and joins as well as row-level security.  As mentioned above, you can even add data from another secondary source and map a join between the two sources.  This is as simple as adding the second connection to your project and creating the join.  The Information Design Tool treats the data as if it were all from a single source.  This is a very powerful feature, indeed.

Another big area of improvement is the context menu options when right-clicking a table in the designer.  You can now quickly replace a table with another, search for related tables, or even add a calculated column.  All this adds up to more rapid development and deployment and less time struggling with the quirks of the tool.

The Business Layer

The Business Layer is a collection of metadata objects that map to SQL or MDX definitions in a database, for example, columns, views, database functions, or pre-aggregated calculations.  This is the same as the left Universe panel on the previous designer tool, but with additional functionality.  The editor allows you to quickly view the query and values behind each object you create.  There is also an area to provide metadata describing the source of the object, including technical information, mapping, and lineage.

Aside from creating the various dimensions and measures that make up the Business Layer, the designer can also create and save queries using the traditional query panel to test their universe using specific use cases.  The query can be executed directly from within the Information Design Tool and the developer can do some analysis to make sure they are getting the correct results.

For More Information

For more information and to get a better look at the Information Design Tool, check out this great set of tutorials provided by the SAP Developers’ Network.

Related posts:

1. Exploring 4.0: BI Launchpad
2. SAP BusinessObjects Enterprise 4.0 Ramp-up and Analysis!
3. Xcelsius … Crystal Dashboard Design … Xcelsius 2008 Fix Pack 3.2 Now Available!

BI Launch Pad (Formerly InfoView)

With a brand new name and a change to the look and feel, BI Launch Pad offers a redesigned interface and new functionality that builds upon InfoView and includes the following:

• Tabbed Browsing that works and feels much like a web browser
• Accordion Menu (or drawers as SAP calls them) for My Documents, Folders, Categories and Search
• Dialog boxes for scheduling, properties, preferences, etc. much like the look and feel of the CMC for 3.x
• Session Notifications that count down the time you have left before your session times out!!!!
• Easier more intuitive access to web-applications
  • Modules / BI Workspace
  • Advanced Analysis
  • Interactive Analysis

Central Management Console

Two new additions to the Central Management Console stand out like a sore thumb. First, an administrator will no longer have to drill into every SAP BusinessObjects job, event, processing and cache server to turn on auditing. This all will be done on a centralized auditing page and will have a default auditing profile when installed.  Second, a monitoring page  allows an administrator to view how the system is performing live or how it has performed historically.

Information Design Tool (New and Improved Universe Designer Tool)

While the Designer application still does exist and is available as a client tool, a new universe design application called the Information Design Tool is now available to offer new and exciting features when it comes to designing your metadata layer. When building a universe (.unx) using Information Design, you have 3 different files that need to be created:

• Connection (.cnx)
• Data Foundation (.dfx)
• Business Layer (.blx)

While that is a big change on how the universe development process is currently done, the biggest addition has to be the best piece of functionality that we have found to date. With the Information Design Tool universe developers will be able to define multiple sources in the connection file. This will allow universes to be developed utilizing multiple relational databases!

Dashboard Design (Formerly Xcelsius/Crystal Dashboard Design)

Dashboard Design is adding new functionality that is geared toward making it more efficient for developers to build dashboards. The biggest addition to the application has to be the ability to create queries directly in Dashboard Design and allow developers to map data directly to components without having to go through the excel model. One thing to note, the Query as a Web Service application is still available as a client tool and will have to be used when referencing legacy universes due to the fact that the built in query tool in Dashboard Design seems to only  acknowledge 4.0 universes (.unx).

Interactive Analysis / Web Intelligence

Web Intelligence may have been the biggest transformation in the whole 4.0 release. The name is still up in the air from what I understand so when the full release comes out it may be Interactive Analysis or Web Intelligence. Besides the pending name change, WebI has been completely reworked and has a whole new look and feel when it comes to developing and viewing reports.

On the development side, the toolbars are now in ribbon form like Office 2007 and above. Once getting to know where everything was, it was just like riding a bike. The second thing that is really helpful is  the query panel now incorporates a data view that lets you see the raw data before ever putting it onto the report. The last thing I want to share is the ability to add a web service as a data source.

For report viewers, the visualization of the report for charts and tables has been greatly enhanced. This should help developers be able to create meaningful and elegant reports that meet any report viewers request.

Desktop Intelligence

The last thing I wanted to touch on was the fact that with the 4.0 release Desktop Intelligence will have reached the end of it’s life.  Anyone who utilizes DeskI and wants to move up to Enterprise 4.0 will have to convert their existing DeskI reports over to either Crystal Reports or Interactive Analysis / Web Intelligence

Don’t forget to check back often for more information on SAP BusinessObjects 4.0.

Related posts:

1. SAP BusinessObjects 4 Teaser
2. BusinessObjects Enterprise XI 3.1 Service Pack 2 Now Available!
3. Exploring 4.0: Information Design Tool

I recently published the post 5 Reasons Why You Should Use an SAP BusinessObjects Universe to highlight some of the core benefits you’ll see when implementing the semantic layer for you organization.  The post was derived from speaking with organizations new to the Business Objects world about the benefits of leveraging the semantic layer. Throughout those talks, I also get to hear a lot of misconceptions about SAP BusinessObjects Universes.  Sometimes they are born out of a simple lack of understanding of the SAP BusinessObjects architecture, while other times they are propagated by competing business intelligence vendors.  (Shocking, I know.)

In any case, I’m here to set the record straight.  While the universe semantic layer isn’t perfect, it is pretty good at what it does and keeps getting better.  Here are some common misconceptions that I’ve heard over the years.  Did I miss any?  Let me know in the comments…

Universes affect query performance by adding unnecessary overhead.

False. In its simplest form, a universe is merely a semantic layer that maps your database objects to standard business terminology to provide an intuitive way to work with information.  When queries are refreshed, the business terminology is turned back into SQL and executed on the appropriate database directly.  If your query has three items in it, so will the resultset coming back from the database.  There aren’t any middleware components or services that add overhead to this process.

The Universe is simply a cube of my data, formatted for reporting.

False. (See above.)  The data returned by your universe continues to reside wherever it does today.  The universe semantic layer simply defines how those tables are joined, how the objects are defined, etc…

I need to have a data warehouse or data mart to be able to use a Universe.

False. While query performance will generally be better if running against a schema designed for reporting (i.e. data mart/data warehouse), as a technology Universes are equally at home pointing directly to data contained in CRM, ERP and other transactional systems.  We often use this method when implementing operational reporting, where our client needs real-time access to their raw transaction information.

I can’t use a Universe because I want to aggregate by different dimensions depending upon the report.

False. When developing a universe, you simply define how objects should aggregate – sum, avg, count, etc… -  not specific dimensions by which to aggregate.  By properly using SQL Aggregation and Measure Projection in the definition of your universe objects, the result set will dynamically aggregate at whatever level is appropriate given the dimension objects you selected.  If you select ‘Year’ and ‘Total Sales’, the query will return one row for each year showing total sales.  Add ‘Product Line’ to the query, and now you’ll have one row per year per product line, etc…  All of this done automagically by the universe.

Our application uses a proprietary database, so it won’t work with a Universe.

False (sort of). In general, as long as the vendor provides an ODBC driver for the database you should be able to access it’s information through the universe using a Generic ODBC connection.  However (and it’s a big however) the functions that you can use in the universe are limited to those that are supported by the ODBC driver.  If you’d like to roll up all the sales by year and the driver doesn’t support a Date function to do that, you’re out of luck.  (Obviously you could still do these conversions at the report level, but that’s a different topic as we’re talking specifically about universe functionality here.)

At any rate, this lack of support has more to do with the specific ODBC driver than the universe, as you would run into the same issue no matter how you tried to access that data.  In these cases, we typically evaluate the reporting requirements alongside the capabilities of the ODBC driver itself before making the decision to move forward with the generic driver, or work towards getting the data into a more standard database platform.

Question:  What misconceptions have you had/heard about SAP BusinessObjects Universes?

Related posts:

1. 5 Reasons Why You Should Use SAP BusinessObjects Universes
2. What is a Business Objects Universe?
3. Exploring 4.0: Information Design Tool

In meeting with organizations who are new to SAP BusinessObjects or who are legacy Crystal Reports users, we are often asked the question “Why should I use a Business Objects Universe?”.  To organizations who have worked with universes for a period of time, the advantages and value proposition are clear.  But for organizations who are new to universes, it can often be a challenge to quantify the value of the semantic layer.

In this post I hope to outline a few of the reasons why we recommend implementing universes, even if you’re not using an SAP BusinessObjects tool that specifically requires them.

Integrated security

One of the most common ways that security is implemented into an SAP BusinessObjects Universe is to dynamically restrict data being returned by a query.  In this example, only sales belonging to the user that ran the report or viewed the dashboard would be shown.  You can also use this technique to segregate data by customer, regional manager, product division, warehouse, etc… to give everyone a personalized view of their information.  But that’s just the beginning.

You can also use the built-in universe security to restrict access to particular objects (such as salary or SSN), control the types of queries a user can run, change the database connection depending on the user, and even dynamically map to other tables.  Leveraging the universe model gives you complete security over your environment, and the best part is you only have to apply the security once and it takes affect whether the user is refreshing a canned report, viewing a dashboard or creating their own ad hoc report.

Single version of the truth

We’ve all been there.  You’re at a meeting discussing sales numbers and three people give three different answers on what last month’s sales were.  The Sales Manager defines it as bookings made.  The Warehouse Team counts only orders that were physically shipped out the door.  And Finance, well they pull a bunch of different information into their spreadsheet and come up with a third version.  They may all be correct, but they’re also all wrong.

Building a universe layer “forces” you to come together and define the terminology that you use, perhaps in the case above creating separate “sales” and “shipments” measures to satisfy everyone’s reporting requirements.  When reporting through the universe, everyone in the organization will benefit by having access to the same information, defined in the same way, using the same calculations.

Build once and reuse

Some of the clients we meet with, particularly those that have been using Crystal Reports for some time, are resistant to using universes because “it would be easier to just hardcode the SQL” or “our data structure is too complex”.  Sure, it may be easier the first time to hardcode a SQL query into a report, but what about the second, fifth or tenth time you have to do that?  And as for the data being too complex, with few exceptions if you can define it in SQL you can build it into a universe.  This ability to define the universe semantic layer one time and leverage it across the entire SAP BusinessObjects toolset is huge.

Maintenance/change management

Perhaps one of the most overlooked benefits of utilizing the universe layer is around maintenance and change management.  With the universe model all of your logic is in one place, making maintenance straightforward.  Plus, if the data model for any of your upstream systems changes, you can in most cases modify the universe to reflect those changes without having to touch any of your downstream reports, dashboards or analytics.  Just imagine if you had 2,000 reports written against hardcoded SQL sitting on top of a data model that has now changed radically in a new release.  I’ve seen it happen, and it wasn’t pretty.

Intuitive interface for developers and end-users

This is what it’s all about: providing end-users and developers alike with a drag and drop interface where they could build reports using business terminology rather than SQL code.  Which is more intuitive to an end-user: SUM(DB_AdvWorksDW.dbo.FactResellerSales.SalesAmount) or ‘Sum of Reseller Sales’?  Now imagine this simple example using CASE statements, datatype conversions, etc… and you’ll understand the true power of the SAP BusinessObjects universe.

In using the universe layer, report authors and developers can reference information in common business terminology, and be shielded by all the technical complexity and transformations that are happening behind the scenes.

Want to learn more?

There are many benefits to using the Universe model, these are just a few of the most popular.  Want to learn more?  Call us at (877) 844-7476 or email info@alteksolutions.com to see how you can leverage the power of the universe for your organization.

Question:  Does your organization utilize SAP BusinessObjects universes?  If so what advantages do you see, and did you find any downsides?  If you don’t use universes, why not?

Related posts:

1. Top 5 Misconceptions About Business Objects Universes
2. Maintain Peak Performance With a Comprehensive SAP BusinessObjects Health Check
3. Five Reasons Why Ad Hoc Reporting Won’t Work in Some Organizations

We’re about to embark upon a new project to conduct a large-scale health check on one of our client’s primary reporting environments, so I thought it may be beneficial to write about the process we use. Hopefully it will give you some insight into how to conduct a health check, and the benefits your organization will see should you decide to undertake one.

When sitting down with a client to discuss conducting a Health Check, we tend to get asked a lot of questions – which is exactly how I’m going to frame this post. Have some of your own? Add them in the Comments, and we’ll add them to the post.

What is an SAP BusinessObjects Health Check?

In it’s basic form, an SAP BusinessObjects Health Check is directed to discovery and documentation of an SAP BusinessObjects deployment. The core deliverable of a Health Check is an accounting of system design and performance, along with recommendations on how to best approach the environment for present and future requirements.

When should a Health Check be conducted?

Generally, it’s a good idea to periodically (every year or so) conduct Health Checks to keep up with changing demands, technologies and information. We especially recommend undergoing a Health Check activity:

• Before migrating to a major new release
• When the actual system usage or audience has changed significantly from its original scope
• If performance isn’t as expected or is declining
• When development is complete and new content is about to be migrated into production

Why should I do a Health Check? Where is the benefit?

The main benefit of a Health Check is to receive an unbiased evaluation of your environment, along with a roadmap of ways to improve its usability, security and performance. A chain is only as strong as its weakest link. By identifying the weak links in your system and proposing solutions to resolve them, a successful Health Check put your business intelligence solution and organization as a whole in a much better competitive position.

What does the process look like?

Over the past ten years, we have developed a core methodology around Health Checks, and I’m sure other organizations may have their own written procedures as well. While we often tailor our process to meet a specific goal or area of focus, the workflow generally looks like this:

• Kick-off meeting to determine scope, constraints, areas of focus, etc…
• Interviews with technical teams
• Interviews with developers
• Interviews with end-users
• Self-guided analysis/Follow-up interviews
• Documentation development
• Presentation of findings/recommendations

What specifically is evaluated?

We typically start the analysis process with the following areas and add/modify according to the client’s specific needs and areas of focus:

• Tool selection and usage
• Development practices
• Architecture & configuration
• Underlying databases
• SAP BusinessObjects Universes, reports, analytics and dashboards
• Custom intranets/extranets/portals
• Security protocols
• Skill and knowledge gaps

What are the deliverables? What do I “get”?

Deliverables may vary depending upon the methodology of the organization conducting the Health Check. The primary deliverable that we provide is a well-written, detailed document that covers:

• The current state of affairs
• Issues discovered during the Health Check and their potential resolutions
• Recommendations on ways to improve the environment by applying best practices
• Education plan to address staff skill- and knowledge-gaps
• A Business Intelligence Roadmap to help ensure the organization moves in the right direction

How long does it usually take?

A typical Health Check for a small to mid-sized organization usually takes between 5 and 10 days. If your environment is smaller in scope, it could be accomplished in as little as a few days. Likewise, if you’ve got a large environment with numerous servers, databases and universes – like the one we’re embarking on now – the process can take a bit longer.

Why use a consultant? Can’t my own developers conduct our Health Check?

Sure…but that’s a bit like having the fox guard the hen house, isn’t it? In all seriousness, using your own developers to perform a Health Check is a bad idea for a number of reasons.

First, they don’t know what they don’t know. A seasoned consultant, who develops a variety of BI solutions day in and day out, has acquired additional skills along the way that give them a unique perspective on best practices and approaches to your problems. Second, your developers may be too close to the problem. Working in an environment for a period of time may blind them to glaring issues an “outsider” will pick up on almost immediately. Finally, as an outside resource, a consultant generally doesn’t have to deal with office politics. They come in to do a job, and make recommendations based on fact – not whether or not they’re going to ruffle anyone’s feathers.

Are these really beneficial? Will I see results?

The “worst” that can happen is we end up telling you that you’re doing everything right – but that hasn’t happened in the ten years I’ve been doing these. We can ALWAYS find some tweaks that can have a large impact on the performance, usability and scalability of your Business Objects environment. Two cases that come to mind are a client implementing a suggested change that took query run-times from 20+ minutes to under 3 seconds, and a client that had numerous reports that were unknowingly pointing to test data instead of production data for several months.

What are the next steps after a Health Check is conducted?

As part of a typical Health Check you will receive a document outlining recommendations you can take to improve your environment. Once presented, the recommendations are yours to do with what you wish. You could throw them out the window (not recommended), undertake them in-house, utilize a consulting organization to bring your deployment up to par, or a combination of all three. In any case, the Health Check will provide you with a solid roadmap on what you need to do next to maintain and improve your SAP BusinessObjects environment.

Related posts:

1. 5 Reasons Why You Should Use SAP BusinessObjects Universes

There are going to be three key steps that will need to be done to get Aggregate Awareness up and running in your universe. The first will be to add the summary tables and any objects that are not already in your universe. Normally with Aggregate tables, you will not be linking them in to any of your other tables in the universe. They will just be hanging out by themselves on an island. FYI, when you have tables like this, your integrity check will throw errors so don’t get too frustrated, it is to be expected.

SAP BusinessObjects Universe

Aggregate Awareness Function

The second step is to set up the Aggregate Awareness function in your objects. Before we get into the syntax, here is a quick overview of how the function works. The AA function takes multiple fields from multiple tables that have been inserted into your universe and determines which one to use depending on objects selected for a query by the end user.

Although it sounds confusing it is actually pretty easy to implement. The first thing is to determine which objects should get the AA function. The answer to this is that any object that is in both your summary tables and your fact tables. In my example, I will be adding AA to the following objects:

• Company
• City
• State
• Sales Cost
• Margin
• Quantity Sold

For Company, City, State, Margin, I will be adding AA for two fields while for Sales Cost and Quantity Sold I will need to add AA for 3 fields. So to get started, the syntax is @aggregate_aware([Field1], [Field2], …) and as a tip, when you populate the fields you want to use, you need to put the smallest / quickest responding table to the left while the biggest / slowest responding table will go to the right. Here are two examples from my universe.

Company

@Aggregate_Aware(“Company Summary”.Company,”Fact Table”.Company)

Sales Cost

@Aggregate_Aware(sum(“Company Summary”.”Sales Cost”),sum(“Date Summary”.”Sales Cost”),sum(“Fact Table”.”Sales Cost”))

Aggregate Awareness Syntax

Incompatible Objects

After you set up the AA function, the next and final step is to set up your incompatible objects. An incompatible object is an object that will not work for a specific table. So really what you are doing is setting up objects that if selected will eliminate tables that you cannot use from your query. To access the incompatible objects, go to Tools > Aggregate Navigation.

Aggregate Navigation

Once there you will need to set up incompatible objects ( and filters) for each table that you have in your universe. In my example, I have set up incompatible objects for Company Summary as Year, Quarter, Month, Date, Order Date, Order Number and Customer Name. For my Date Summary table, I set up Order Date, Order Number, Customer Name,  Company, City, State,  and Margin. Once this is set up you should be able to export your universe and check out how it works in WebI.

AA in Action!

Now all that is left is to create a query and watch AA do its magic. In the pictures below, I have created 3 queries and show the SQL with each one. As I stated above, Aggregate Awareness will automatically determine which tables to pull data from depending on the objects you select in your query.  This approach is a quick and easy way to gain performance in your reporting as well implementing a feature that the end user will appreciate but not even know that it is there.

Fact Table Query

Company Summary Query

Date Summary Query

Related posts:

1. Aggregate Awareness! What is that? (Part 1 of 2)
2. Top 5 Misconceptions About Business Objects Universes
3. Why Ad Hoc Reporting Won’t Work (part 3): I don’t want people poking around in data they shouldn’t have access to

Back in March I posted “Five Reasons Why Ad Hoc Reporting Won’t Work In Some Organizations“.  In that post, I listed some of the major concerns that I hear from potential clients when the subject of ad hoc reporting is broached.  We’ve already addressed “Our people aren’t smart enough to create their own reports”,  “We need to massage the data first” and “I don’t want people poking around in data they shouldn’t have access to”.

One of the other reasons I hear is that managers don’t want to train end-users to create reports, since they have folks in IT that already tasked with that.  Some report authoring will always need to be handled by IT, due to it’s complexity, lack of data availability, etc…  But I argue that the lion’s share of the development can be handled within each department instead, freeing IT developers to take on other projects critical to the organization.

Two Kinds of Users

First, let’s set the record straight.  You will ALWAYS have a majority in your organization that will only consume content.  They will never have the desire or need to create their own reports, and that’s OK.  Keep on providing them with canned reports that they can refresh on their own and they’ll be content.

On the flip side, you will also ALWAYS have a few power users that can do things with that data that will make your head spin.  You know the ones.  They’re sitting in Excel right now.  Slicing and dicing the data to gleam insights in the information.  And they could get it done a lot quicker if they didn’t have to wait 5 weeks for IT to create the updated report they’re looking for.

It’s Not IT’s Fault

I’ve spent many years on the IT side of the fence, so I feel for my technical brethren. You’re knee-deep in the middle of another project, when a request comes in to create a new report or data download.  You’ve got tons of other things to work on, and now you need to create a new report…only to have the user tell you while you built what they asked for, it’s not really what they wanted.  Sound familiar?

Just imagine the time savings you’d realize if you created a reporting environment one time, then rolled that out to power users in each department to do the actual reporting.  Sure, you’ll need to make tweaks here and there.  And once in awhile even the power users will get stumped and need some help.  In the long-run, however, not only do you clear your plate to take on more strategic initiatives that are critical to the organization…but the users will gain access to information quicker, be able to perform iterative development to meet their requirements, and become better data stewards in the process.  It’s a win-win for everyone involved.

It’s All About the Reporting Environment

A well-designed reporting environment will require very little training for users with the right aptitude.  I’ve seen power users develop basic proficiency in SAP BusinessObjects tools within a matter of days.  And if the universe metadata layer (and underlying database) is designed properly, you can eliminate many of the data-related questions as well.  What you’re left with is a power user that has all the data they need at their fingertips, and the tools needed to turn that into useful information that can be shared with the rest of the team.

Conclusion

There’s no magic bullet, and deploying a well-designed ad hoc reporting solution will take an investment in time and resources.  What cannot be underestimated, however, are the productivity and knowledge gains that can be realized once ad hoc reporting is released to your user base.

Related posts:

1. Why Ad Hoc Reporting Won’t Work (part 3): I don’t want people poking around in data they shouldn’t have access to
2. Why Ad Hoc Reporting Won’t Work (part 1): Our People Aren’t Smart Enough
3. Why Ad Hoc Reporting Won’t Work (part 5): If I Give Them Ad Hoc Access to Data, They’ll Keep Asking For More

Back in March I posted “Five Reasons Why Ad Hoc Reporting Won’t Work In Some Organizations“.  In that post, I listed some of the major concerns that I hear from potential clients when the subject of ad hoc reporting is broached.  We’ve already addressed “Our people aren’t smart enough to create their own reports” and “We need to massage the data first.”  Now let’s take a look at a typical concern from a security standpoint.

Data security is typically a really a big deal for organizations, and it SHOULD be.  Thankfully, SAP BusinessObjects offers a number of ways to provide security around functionality, content and data.  With some careful planning and a well-designed SAP BusinessObjects implementation, you can rest assured knowing that users will have access to only the information that they are supposed to see.

Content-level Security

Managing User Security in the Central Management Console

The easiest way to limit unnecessary information is to simply deny access to that universe (semantic layer), report or dashboard through the Central Management Console.  For instance, unless an employee is in the Payroll Department, they shouldn’t have access to any payroll reports, dashboards, etc…

This method will work to restrict content at a high level.  There are, however, instances where an end-user should have access to a set of information…but have a restricted view based on their particular role or access level.

For a more granular level, we turn to column-level and row-level security.

Column-level Security

Prior to founding Altek Solutions, I worked for a health insurance company developing a data warehouse using Business Objects.  There were only handful of people in the organization that were permitted to see “sensitive” member information, such as a member’s Social Security Number.

The people who had the appropriate security level would see “123-45-6789″ as the SSN on a report, while everyone else would see “xxx-xx-xxxx”.  Since this logic was implemented at the universe level, it was automatically applied whether a user was looking at a canned report, a corporate dashboard, or their own ad hoc report.

This approach works great for restricting sensitive columns, such as SSN, salary, margin, etc… as a whole.  But sometimes you need to allow a user to see information, but only for a subset of the data.  For that, we turn to our third approach: row-level security.

Row-level Security

Through row-level security, you can limit access to a particular segment of the data.  For instance, in an extranet you can utilize row-level security to ensure that a customer only sees their own data.  And internally, make sure that a salesperson only sees their results, a sales manager only sees results for their particular region, etc…

You can also incorporate security tables (whether standalone or from a ERP or CRM system, etc…) to provide customized security to meet your specific needs.  And like Column-level security, since the logic is implemented at the universe level it will be applied no matter which tool is utilized to view the information.

Conclusion

Admittedly, I’ve only briefly touched on the power and versatility that SAP BusinessObjects provides to limit access to information.  (We will touch on these three approaches and a few others in more technical detail in some upcoming posts.)  Rather, this post is intended to provide a background of some of the approaches that you can take when applying security, and hopefully alleviate some concerns you may have about opening your data to your user base.

With some careful planning, you can develop a security methodology that will empower your users with the information they need to make better decisions – while safeguarding it from others who do not need access.

Related posts:

1. Why Ad Hoc Reporting Won’t Work (part 5): If I Give Them Ad Hoc Access to Data, They’ll Keep Asking For More
2. Why Ad Hoc Reporting Won’t Work (part 4): I Pay People in IT to Create Reports
3. Why Ad Hoc Reporting Won’t Work (part 1): Our People Aren’t Smart Enough

What is Aggregation?

At its basic, aggregation is just the process of summarizing information based on the level of detail you want to look at your data. For an example, it is really as simple as taking a years worth of data that is broken out by day and then aggregating or summarizing it to see the results by week, month, quarter or even the whole year.

Monthly Aggregation

Summary Tables

Before we can add Aggregate Awareness into our universe we first need our summary tables. These are generated at the database level and are usually created based off of a fact or transaction table. How you want your data summarized is totally up to you and the requirements of your end users. More than likely you are going to be using Sum and Count for the majority of your aggregation but you can also use the following:

• Average
• Maximum
• Mean
• Minimum
• Mode

I put together a quick example to show how to take a fact table and get aggregate tables out of it. In the picture below, we have a  table that consists of order information by date and contains a million records. Depending on the level of detail a report looks at, we can bypass looking at the huge fact table and get our results out of one of the two summary tables.

Summary Tables

The Company Summary table takes the fact table and aggregates it up to show Sales Cost, Margin and Quantity Sold by Company, City and State. The Date Summary table parses out the Order Date to allow Year, Quarter, Month and Day to be dimensions for Sales Cost and Quantity Sold. An example of the SQL to generate the Company Summary table would be as follows:

“SELECT Company, City, State, Sum(Sales Cost), Sum(Margin), Sum(Quantity Sold) FROM Fact Table GROUP BY Company, City, State”

Aggregation and Summary tables can be your best friend by limiting the amount of records an end user has to report against. Less records equals quicker response time for your report and happy end users.

Go here to see the second part of our Aggregate Awareness series to see how to implement your new summary tables into a universe.

Related posts:

1. Aggregate Awareness! What is that? (Part 2 of 2)
2. Top 5 Misconceptions About Business Objects Universes
3. Why Ad Hoc Reporting Won’t Work (part 3): I don’t want people poking around in data they shouldn’t have access to

I recently posted “Five Reasons Why Ad Hoc Reporting Won’t Work In Some Organizations“.  In that post, I listed some of the major concerns that I hear from potential clients when the subject of ad hoc reporting is broached.  As promised, I will be addressing each of those concerns and showing how they can be overcome.  Today, we begin with the first one: “Our people aren’t smart enough to create their own reports”

As I mentioned previously, I hear this one way too often and it usually is a case of not understanding the capabilities of a well-designed Business Intelligence solution.  Managers are concerned (and rightfully so) about the level of training their users will require, their ability to understand how the data fits together, etc…  But it doesn’t have to be a concern at all.

With the breadth of tools and capabilities that are available in today’s BI solutions — and with a solid understanding of the user’s requirements for ad hoc information access — it can be relatively easy to build a solution that delivers on those requirements without requiring a huge investment in training.

Let’s first take a step back to look at what ad hoc reporting really means.

What is Ad Hoc Reporting?

When a client tells me they are interested in implementing ad hoc reporting, I always ask them to define that for me. My experience tells me that people often have varying views of what ad hoc reporting really is, including:

• Ability for a user to refresh a report themselves and fill in prompts to filter the results
• Ability to perform simple queries or ask simple questions of the data to find the information they need
• Ability to create production-ready reports themselves.

When someone in the SAP BusinessObjects world says “ad hoc reporting”, they typically are referring to the WebIntelligence product.  But as you can see there are a variety of other tools that can be used to satisfy those needs — depending, of course, upon your definition of “ad hoc”.

Using SAP BusinessObjects Tools to Support Basic “Ad Hoc” Reporting

1. Crystal Reports
   While certainly not a tool that I would give to untrained end users, Crystal Reports themselves are an excellent way to implement  “filter and refresh adhoc”.  These reports could also include interactivity to drill into the hierarchy of the data, link to more detailed reports, etc… making it a great way to build a sandbox for simple interactive, ad hoc reporting
2. Xcelsius
   While typically thought of as a dashboard/visualization tool, Xcelsius can also be used to assemble easy-to-use ad hoc sandboxes.  Using filters, drop-down lists and the like, IT can deliver visually stunning, interactive “ad hoc” reporting to end-users.
3. Explorer
   Finally, SAP BusinessObjects Explorer provides search, exploration and visualization — much in the way I’ve described above in allowing ad hoc reporting within a predefined sandbox.

Depending upon your needs, this level of ad hoc reporting may be enough.  In fact, it will probably satisfy most ad hoc information needs.  If you need to move beyond that, however, read on for some tips on how to create a true ad hoc environment with SAP BusinessObjects that people can and will use.

A Few Tips for Creating a True Ad Hoc Environment

Even if you need to deploy true ad hoc reporting, it shouldn’t be cause for alarm.  While there will always be some degree of a learning curve in terms of creating queries, formatting the report, etc…, there are a few steps we can take to minimize the training required.

1. Focus on Subject-specific data
   Throughout my 10 years as a BusinessObjects consultant, I’ve seen a lot of styles of Universe development.  Strike that.  I’ve fixed a lot of styles of Universe development.

   While I suppose it’s noble to develop a universe that contains every bit of information a company needs, if that universe contains 50 classes, 1,200 objects and 9 contexts…I respectfully say you’re missing the point.  (This isn’t an extreme example…unfortunately we’ve seen fixed much worse.)

   Our methodology for developing ad hoc BusinessObjects universes is to focus on a specific subject-area, and provide all the information a would-be end-user needs to answer a specific set of questions.  No more.  No less.

   Instead of developing a “Finance” universe, think about developing one universe for Accounts Receivable, one for Accounts Payable, one for the General Ledger, etc…  Not only will the universes be easier to use, but they’ll be infinitely easier to maintain as well.

2. Start with the data in the correct format
   With SAP BusinessObjects, you have a number of opportunities to get the data in the correct format for a given analysis: at the database level, in the universe, and in WebIntelligence report itself.  And I recommend tackling it in that order.

   If you can “fix” the data at the database level, do it.  Not only will it be easier to develop the universe if the data is structured for reporting, but you’ll also likely gain performance advantages along the way.

3. Build as much business logic into the Universe as possible
   Continuing on with the theme from #2, try to push as much business logic to the universe level so end-users won’t have to worry about data aggregation, calculating averages, grouping data together, etc…Once we understand the specific requirements, we work hard to make the ad hoc environment as close to “drag and drop” as possible.  The less the end-user needs to do to get the results they’re after the better.

That’s it for part 1, “Our people aren’t smart enough…”.  Stay tuned for our next “objection” to implementing ad hoc: “”We usually need to massage our data…”.

Question:  How does your organization use ad hoc reporting?  If you’re utilizing true ad hoc reporting, what steps have you taken to make the environment as easy-to-use as possible?

Related posts:

1. Why Ad Hoc Reporting Won’t Work (part 4): I Pay People in IT to Create Reports
2. Why Ad Hoc Reporting Won’t Work (part 3): I don’t want people poking around in data they shouldn’t have access to
3. Why Ad Hoc Reporting Won’t Work (part 5): If I Give Them Ad Hoc Access to Data, They’ll Keep Asking For More