There are a number of tools that can aide in the integration of SAP BusinessObjects into a BI environment. But it's up to administrators to decide which tools are best for their configurations, and how to best use these tools. In this section, gain insight into choosing the right tools for integrating SAP BusinessObjects. Learn about SAP Business Explorer (SAP BEx), as well as the Web Intelligence (WI) reporting toolset, and find out why WI is a standout component of SAP BusinessObjects.
Table of contents:
Integrating SAP Business Objects into BI environments
Choosing tools for an SAP BusinessObjects-BI integration
The basics of SAP Xcelsius software
Using Crystal Reports and SAP BEx in an SAP BI environment
Choosing the Right Tool for the Right Job
Now we can look at the different tools within this set to see what works where, so that we can identify and recommend the appropriate tool for the job. With the SAP BusinessObjects suite of BI solutions, several options enable organizations to bring BI to all business users. With the current components available, we have a bit of a mix in toolsets—most with a significant background with BusinessObjects and one aligned with the SAP BI reporting component and this group of reporting components will be the best business practice approach until the development of SAP BusinessObjects Pioneer product is available. These reporting options are
- BusinessObjects Explorer
- BusinessObjects Web Intelligence
- BEx Analyzer (Web and Excel)/Voyager/Pioneer
- Crystal Reports
As mentioned in the last section, SAP takes a use case–driven approach to determine which products are best to use for each business requirement, and then recommends that other consultants and businesses take a similar approach. When looking at the existing BW footprint at SAP customers, the following are the general guidelines for what constitutes the right tool for the right job:
- For information exploration where BW is in place, SAP BusinessObjects Explorer NetWeaver Version (that is, SAP BusinessObjects Polestar + SAP BW Accelerator) is the tool of choice.
- For casual, ad hoc reporting and analysis and general interactive reporting where BW is in place, Web Intelligence with OLAP universes is the first choice.
- For OLAP analysis where BW is in place, the BEx Analyzer (Web and Excel) client remains the tool of choice until the availability of the SAP BusinessObjects Pioneer. Voyager was the BusinessObjects component that was similar to the BEx Analyzer but should really not be concerned as an alternative. In the future, the preferred solutions for OLAP analysis will be based on the Pioneer project as a replacement for BEx Analyzer and Voyager.
- For formatted or production reporting from either BW or directly from ERP (ECC), Crystal Reports is the tool of choice.
- For dashboarding and visualization where BW is in place, the choice would be a combination of Xcelsius with Query as a Web Service (QaaWS) or LiveOffice as a connection layer.
As part of the requirements gathering in project preparation, it is strongly recommended to apply use cases to each of the requirements. That is, by not only capturing what the business needs are and how we plan to address them (as part of the project), but also including how reports and dashboards are delivered and consumed, we discover how end users will use the information that is provided to them. With this process in place it will help us further understand the nature of the requirements and functionality each business user needs. This will also help us determine which tool to use, as well as help us with our design approach. By not only considering the needs and requirements of the business user, we can also identify the reporting toolset that will satisfy their needs. As you can see, the process is twofold. First, identify the actual functional requirements, and then identify the reporting component that will satisfy those requirements. The following sections include both a basic background of the product use and the guidelines for mapping required end-user capabilities to the BI platform, starting with an overall baseline approach, as depicted in the illustration.
Again, the positioning of these components will really help you to conceptualize the BusinessObjects product. The preceding diagram shows the functionality across the top and the business user groups down the left side. Some of these tools overlap user groups, such as BusinessObjects Explorer and Xcelsius, but overall you can see what situation fits what tool. This should help you to identify the configuration approach and the implementation process. In a normal business use case, we would look at the process rather than the actual system component, and then work toward the appropriate tool that fits the situation. For now, we are going to look at the specific components of the BOBJ reporting toolset and include the use case information within each of these discussions. I find this approach more vertical and not horizontal enough for the business but it works for us in this book environment.
As we all look to migrate from our current reporting format to the newer format we always try to compare the newer items with the previous items and in this case I will also offer some comments to this effect in the areas that are really trade-offs such as the Crystal Reports versus Report Designer area but overall we will try to just outline the overall functionality. Also, in this case attempting to match reporting component to reporting component would be inconsistent with the approach that the business should take in terms of identifying the correct reporting functionality. Each should be viewed on their own value and functionality to the business. Now you can see that getting into too much detail would take us into another completely different avenue and the chapter would end up being twice the size. Just the configuration alone of the WebI would take about 200 pages to describe in detail and we haven't really even talked about the User Interface, which in this case is the InfoView. So the discussion will be high level and brushing over the functionality. As we always say, the devil is in the details, so using this section as an initial very general discussion of each component and then using other more detailed documentation to understand all of the complexities is a prudent approach.
Web Intelligence (WebI)
The Web Intelligence reporting toolset is one of the more recognized components of the BOBJ group. This section highlights the features of the WebI reporting tool and also gets into some of the configuration details. Now, remember, having a new reporting component will not mean that we are going to reinvent the wheel but using another toolset—BOBJ—rather than the SAP BI, we will be able to offer all of the same functionality plus some additional bells and whistles. So, as we go through this process, we will see some very similar activities that we've seen with the WAD or the BEx Web Analyzer. Just that they will possibly use different terminology and access them in a different manner.
In this case, we'll look at some additional details of the integration between the NetWeaver BW system and the BOBJ frontend toolsets, just to give you a general sense of how it works. In general, the Web Intelligence component has two main connectivity options for BW:
- OLAP universes
- Relational universes via SAP BusinessObjects Data Federator
If you look at a best business practice for the WebI, you will see that the suggested approach is via the use of OLAP universes with BW, as this will be the most widely implemented solution within the existing SAP customer base. The following diagram of the architecture shows that the OLAP universe can be supported by a direct link to the actual InfoProvider, such as the InfoCube or the MultiProvider. The preferred approach is to use the BEx query (in this case, the query is created as a definition using the BEx Query Designer and will probably never really be run for any business users as a report); this approach is preferred for several reasons, one of which is the ability to use calculated key figures (CKFs) and restricted key figures (RKFs) that are created in the query definition. Since these are not found in the Infocube, the direct access method would not have access to these formulas.
Note the differences between the InfoProviders that can be directly linked to the OLAP universe and the ones that can be accessed via the BEx query. After the linkage between the two systems is complete, you need to understand what the mapping process is for the different objects within the BEx query. Table 9-1 shows a list of BW query elements and how they are used in an OLAP universe.
As you can see, the OLAP universe maps many objects within the BEx query to "classes," and this mapping is used in the creation of the actual WebI query. As an example of this, the following illustration shows a BW query in the BEx Query Designer.
|BW Query Element||OLAP Universe Element|
|Characteristic (incl. Time and Unit)||A class with dimension and detail objects (detail objects for key and description).|
|Hierarchy||A class containing a dimension and detail objects for each hierarchy level.|
|Calculated key figure (CKF)||Measure element in a class named key figures (information about the calculation is not available via the universe but the CKF is available to be used).|
|Restricted key figure (RKF)||Measure element in a class named key figures (information about the restriction is not available via the universe but the RKF is available to be used).|
|Key figure||Measure element in a class named key figures.|
|Navigational attribute||A class with dimension and detail objects (detail objects for key and description).|
|Display attribute||Each display attribute becomes a detail object underneath the related dimension object.|
|Query filter||Filters will be applied to the underlying query but are not visible in OLAP universe.|
|SAP variables||Query filter as predefined object, which can be optional or mandatory.|
|Custom structure||Dimension object.|
The Rows area of this query includes several characteristics, and the Columns area includes several key figures. On the left side, the actual cube structure is shown with the cube dimensions and different characteristics. The symbol for dimensions has three triangles and the symbol for characteristics has one triangle. If we focus on one portion of this query, we see the characteristics, dimensions, and variables for the customer dimension, shown in the following illustration.
In the next illustration, you can see what happens to these objects when translated or mapped into the OLAP universe. The dimension is Customer (technical name Z_BOBJ1) and the characteristics are City, Country, Customer, and Region. The illustration at right shows the result when an OLAP universe is built on top of such a BW query.
You can see that the cube dimension from BW results in a class in the OLAP universe (for example, dimension Customer). In addition, each characteristic in the query results in a class with dimension and detail objects. Level 00 objects represent the aggregated view on this characteristic, representing the "All" member from the underlying cube.
In terms of the display attributes of a BEx query definition, we see that they are detail objects within the OLAP universe. If we look at this in more detail, we see that display attributes are InfoObjects that are logically assigned or subordinated to a characteristic. For example, the characteristic Customer has two attributes, Phone Number and Fax Number. In SAP reporting tools, the display attributes can only be used in combination with the actual characteristic, which means the attribute Phone Number can only be shown in the SAP reporting tool in combination with the characteristic Customer. In addition, characteristics can be defined as navigational attributes in the BW cube, which then makes these attributes available for navigational purposes in the reporting tools; navigational attributes are treated identically to a characteristic. This can get a bit confusing to both the developers and also for the OLAP universe so the universes differentiate between the two and the functionality of the display versus navigational attributes goes with these objects over to the OLAP universe. The following illustration shows a BW query in the BEx Query Designer. The row structure includes a characteristic Customer with four display attributes: Geographical Height, Postal Code, Sector Code, and Area Code. In addition, the BW query contains three navigational attributes in the rows: Regional Code, Postal Code, and Area Code.
When we build an OLAP universe on top of this BW query, it results in the elements shown in the following illustration. The cube dimension from BW results in a class in the OLAP universe (for example, dimension Customer, not to be confused with the characteristic Customer). As mentioned, each characteristic in the query results in a class with dimension and detail objects. Level 00 objects represent the aggregated view on this characteristic representing the "All" member from the underlying cube (characteristic Customer resulting in a class Customer2 with dimensions L00 Customer and L01 Customer). Also notice that each navigational attribute in the query results in a class with dimension and details objects (navigational attribute Postal Code resulting in a class Postal Code with dimensions L00 Postal Code and L01 Postal Code).
The next illustration shows the display attributes from characteristic Customer and how these display attributes are treated in an OLAP universe. Each display attribute for the characteristic results in a detail object for the corresponding dimension objects in the universe.
- Numeric value of the key figure
- Unit or currency information
- Formatted value, representing the user-specific formatting
The illustration here shows the result of two key figures in the OLAP universe. Each key figure is represented with a measure object in a class Key Figures. In the case where the key figure is configured in BW with a unit, an additional dimension object will be added representing the unit information. The "Formatted" value represents the numeric value formatted as a string value, following the user-specific formatting settings.
This gives you some idea of the linkage of the BW query to the OLAP universe. Once this process of creating an OLAP universe is complete, we can step into the Web Intelligence Rich Client and create the report by dragging and dropping the information into the appropriate columns and rows. The following illustration shows the initial screen for the Web Intelligence Rich Client. Once you start working in this environment, you will find that a number of functions and tasks are similar to those in the BEx Query Designer in terms of formatting and display options. All of the components are found in similar navigational processes as the BEx Query Designer -- either in the right-click context menu or in the top toolbar, where you click and choose what you need to work on.
Once you have created the report, you will have developed an ad hoc analysis component that you will be able to navigate and slice and dice on to generate multiple different views of the data, with the option to save each of the views for later analysis. This is the primary ad hoc reporting and analysis product for casual business users in the BOBJ components. Web Intelligence is a complementary tool to leverage outputs, for the casual and business user, that might have been derived from a deeper analysis achieved in BEx Analyzer. If we look at the overall reporting strategy and identify the areas and requirements that the WebI can fulfill, we have a fairly well-defined list.
First, this component allows the business user to have a combination of ad hoc reporting and analysis primarily directed to the casual user. Second, as with all BOBJ products, Web Intelligence is a self-service process and therefore reduces reliance on the BW IT department. Third, this reporting tool also allows multiple sources of data, both SAP and non-SAP, to be integrated into the same reporting display. Fourth, all the functionality available in the BEx Web Analyzer is available in the WebI component, such as the ability to schedule and publish reports to a distribution list of users, and the ability to modify a report on-the-fly on the Web, save it, and then review or refer back to it in the future. Fifth, Web Intelligence also has all the user-friendly navigation capabilities that the BEx Web Analyzer has in terms of drag-and-drop navigation, context menu functionality, and the ability to switch information into a better format for the analyst. Sixth, it also allows the creation of reusable calculations (creating CKFs and RKFs on the fly). All of these components look at the actual information in the report, but in addition to these functions, Web Intelligence also has the ability to allow the business user to change the format of the report on the fly, adjust charts and table format, add conditions and exceptions, and adjust the positioning of all of these objects within the report. Again, if we compare (and we really shouldn't compare the functionality directly) the capabilities and uses for the WebI with either the BEx Web Analyzer or the BEx Analyzer, we see that we have much of the same functionality and more. It's just a matter of getting used to the actual process of doing these different tasks in the BOBJ environment.
To round out this discussion, let's look at some reports that are generated from the WebI format. In this illustration, the resulting report shows the information in a similar column format as you've seen before and, as mentioned, you would be able to make adjustments as necessary.
The next illustration extends the information into the development of a chart to display the data. As you can see, the ability to develop and use dimensional charts is available in the WebI component.
There are many other examples for the Web Intelligence reporting tool for BOBJ including variables, alerts, conditions, filters, and other parameters but these are just a few to offer some basic samples.
This was first published in July 2010