SAP BusinessObjects Planning and Consolidation gives the option to optimize a data model from the front end.
In SAP BusinessObjects Planning and Consolidation’s action pane, there are two options to optimize: Lite Optimize and Full Optimize (Figure 1). Optimize in this sense means changing the dimension assignments to improve performance.
Figure 1 Options to optimize the data model
The Lite Optimize option does not make any changes to the data model. It just closes the open request, compresses and indexes the cube, and updates database statistics.
However, the Full Optimize option can rearrange the characteristics among 13 user-defined SAP NetWeaver BW dimensions.
The Full Optimize process checks if the size of the dimension table is less than 20 percent of the fact table and creates as many line item dimensions as possible (20 percent is the standard optimization logic built in).
To do this reconfiguration, the Full Optimize process: • Takes the application set offline • Creates a shadow cube with optimal data model • Links the new optimal cube to the MultiProvider for the application • Moves data to the shadow cube • Deletes the original cube • Closes the open request • Compresses and indexes the cube • Updates database statistics • Brings the app set online again
Though this results in creating a new InfoCube, the MultiProvider remains the same and all the SAP BusinessObjects Planning and Consolidation reports are built on the MultiProvider and not the underlying InfoCube. Hence, this optimization does not affect the SAP BusinessObjects Planning and Consolidation reports on this data.
Most companies that use SAP NetWeaver Business Warehouse (BW) have multiple data warehouse tools for staging data. They can find it hard to deploy common front-end solutions to end users. However, if you have BusinessObjects, you can consolidate your front-end software.
Two of the most common options for this purpose are BusinessObjects Web Intelligence and BusinessObjects Voyager. Table 1 shows how their applications compare.
Application
Purpose
Description
BusinessObjects Web Intelligence
Ad hoc reporting
Best for operational reporting where granularity is high (more details).
Save reports as BusinessObjects Web Intelligence documents in private and public folders.
Data is read from a universe. Tools such as drag and drop are available, but you need to save the report, add these tools, and then execute the report.
BusinessObjects Voyager
Analytical reporting
Best for financial reports and real-time reporting where data granularity is low (few details). It’s more suited for summarized data.
You can easily display data in graph and charts.
The source is an OLAP InfoCube, which is usually based on a multi-dimensional model that helps you analyze data quickly.
Uses drag-and-drop method to create reports and allows you to see the results as you add these options.
Table 1 BusinessObjects Web Intelligence and SAP BusinessObjects Voyager compared
Who Should Use Each Application
I find that Web Intelligence is more suited to computer-savvy users. You first have to create a universe based on either an SAP query or InfoCube. (The general recommendation is to use a BEx query for the universe.) Web Intelligence works fine when you have to read granular data or operational reporting, but adjusting the look of the report requires significant product training.
Alternatively, Voyager is more suited to business users. Most users find it easy to learn and use, even more so than existing SAP NetWeaver BW reporting solutions. Voyager works well for users who would like to create formatted reports, but lack reporting design experience. Table 2 summarizes who should use each application.
Application
Type of reporting
Typical user
Web Intelligence
Operational
Trained BusinessObjects users and power users
Voyager
Analytical
Executives, managers, less computer savvy users (those who don’t have much time to learn the reporting skills)
Table 2 Typical users for each type of reporting
For more on the differences between these two applications, check out Praveen’s full article on BusinessObjects Expert.
Ned Falk,Senior Education Consultant, SAP America, shows how your SAP NetWeaver BW projects can benefit using ABAP in his article “20 Uses for ABAP on SAP NetWeaver BW Projects,” which was posted to the SAP Professional Journal Web site in February 2010. Here are four of those uses.
1) Perform Open Hub transformations:
SAP NetWeaver BW supplies the Open Hub service to meet requirements for getting information to third-party applications from SAP NetWeaver BW. The data types, field names, and field lengths are often not the same in SAP NetWeaver BW as they are in the external application, or additional value manipulation is necessary. For this, an ABAPer needs to code the custom logic for the manipulation in a Business Add-In (BAdI). BAdIs, based on ABAP OO, help you accomplish custom enhancements in a controlled way.
2) Build authorization values:
ABAP implemented through variables filled by a user exit can be used to dynamically build authorization values when the user logs in. This is sometimes an easy way to maintain many allowed values for a cost center range for a specific user.
3) Process chains:
The process chain is a scheduling tool for various tasks in the data warehouse. In some cases, you can use ABAP code to schedule a job on the source system or run a small ABAP program on SAP ERP to raise an event on SAP NetWeaver BW. This event could then be used to start a process chain. A business case for this could involve a transaction or ABAP code run on SAP ERP to indicate that the Financial Accounting (FI) system is done with the month-close process. This ABAP program calls SAP NetWeaver BW and raises an event. When this event is raised, the process chain called “FI Monthly Process” starts.
4) Virtual InfoCube with services:
Virtual InfoCubes allow for the direct read of source data in real time. You do not have to load the data into an InfoCube — it is loaded into memory directly from the source when the report is run using standard SAP NetWeaver BW query and reporting tools. The three types of virtual InfoCubes are SAP remote InfoCubes, general remote InfoCubes, and virtual InfoCubes with services. SAP remote InfoCubes use SAP ERP or SAP CRM DataSources (and their associated extractors) to read the data in real time, while general remote InfoCubes access data that is normally purchased (e.g., Nielson). Virtual InfoCubes with services are used if the source is a custom table or group of tables. In this case, custom ABAP function modules (services) can be written to properly present the data from these tables to the SAP NetWeaver BW query tools, making your table look like an SAP NetWeaver BW InfoCube. This provides real-time data, not replicated data, from your application to the user.
Microsoft has made it much easier to design a PivotTable and Pivot Chart using SAP NetWeaver BW and Xcelsius. The screen shot below highlights a number of improvements in Excel 2007 PivotTables. The numbers in the list correspond to the numbers in the image.
The Simba ODBO provider is part of your SAP NetWeaver BW license. There is no additional cost for using MS Excel 2007 with SAP NetWeaver BW. You only have to make sure you have the latest Simba ODBO drivers installed on the client machine (available via a BI add-on for the SAP GUI) and that you have the most recent SAP GUI front-end patches and SAP NetWeaver BW service packs. You need SAP GUI 7.10 or higher.
*** or ***..."msoCommentShow('_anchor_2','_com_2')" onmouseout="msoCommentHide('_com_2')" href="#_msocom_2" language="..." name="_msoanchor_2">[JMH2]
Microsoft has made it much easier to design a PivotTable and Pivot Chart using SAP NetWeaver BW and Xcelsius. Figure 1 highlights a number of improvements in Excel 2007 PivotTables. The numbers in the list correspond to the numbers in Figure 1.
The SAP NetWeaver BW Nearline Storage (NLS) component was introduced in the initial SAP NetWeaver BW 7.0 release. A number of enterprises are already taking advantage of this feature, and their experiences have led to the identification of the following best practices for an Information Lifecycle Management (ILM) implementation.
1. Don’t wait to encounter database size issues before thinking about introducing an ILM strategy. Start early with a preventative approach rather than undertaking a more complex and expensive cure later on.
An ILM implementation has two main phases:
The initial ILM data migration process
The ILM steady state
The steady state is attained at the point when only the required data is kept online, which means that all static data has been moved to the NLS solution. During the initial ILM data migration process, an enterprise may have to migrate a large amount of data to catch up, which can have a major effect on the costs and time requirements of this operation. This also puts additional pressure on already constricted batch windows, thereby increasing the amount of time required to reach the steady state.
Frequently, ILM implementation projects do not allocate sufficient time for initial data migration, mainly because the amount of time required for data deletion and database reorganization is underestimated — this can actually represent up to 70% of the migration process. The longer the enterprise waits before implementing ILM, the more time is required to reach the steady state when pressure on the batch windows is eased considerably. So, the quicker and more aggressive the ILM implementation is, the sooner real benefits materialize.
