Business Warehouse (BW) is SAP’s data warehousing application; it uses an SAP NetWeaver application server, but can run on many different databases. Improvements come with each version of SAP BW, but a really big jump in functionality comes when SAP BW is installed on the SAP HANA database. Now, there are two flavors of SAP BW powered by SAP HANA: SAP BW powered by SAP HANA and SAP BW 7.5, edition for SAP HANA.

Regardless of the brand, data warehouses traditionally have had three purposes:

1. Consolidating data from disparate systems into homogeneous objects designed with online analytical processing (OLAP) in mind.
2. Ensuring that the OLAP workload would not interfere with SAP ERP’s job of executing business transactions (to do this, BW and ERP typically ran on separated databases with their own application servers).
3. Ensuring that response times would be reasonable (to achieve this, traditional data warehouses store data in aggregated forms).

With the advent of SAP HANA as the underlying database, two of these three purposes became obsolete. This is because the in-memory, columnar-stored, and highly partitioned data in SAP HANA allows for super-fast processing. As a result, the need to put OLAP (data-warehouse type) processing on a different database than online transaction-based processing (OLTP) is null and void (number two, above). This is possible because SAP HANA allows both to happen with power leftover for even legacy applications or web sites. In addition, if properly sized, purpose number three (above)—physically aggregating data—is no longer needed as billons of detailed transaction-level records can be processed in seconds.

So, with two out of these three attributes out the window when SAP HANA is the database, you are left with an SAP BW system whose main duty is to consolidate disparate data running from your company’s applications and make it available for analysis and planning.

Note
If your company is considering getting rid of SAP BW, I have written a few articles on why that may not, in most cases, be a good idea. SAP BW has features that are required if your company needs to homogenize data from non-SAP systems, and it is needed even when the SAP ERP Central Component (ECC) system is running directly on SAP HANA alongside SAP BW (the preferred option). For more details about this subject, read my two BI Expert articles, “Do You Still Need SAP BW If You Have SAP HANA?” and “A Guide for Using Embedded SAP BW on SAP HANA If You Get Most of Your Data from ECC.

A Brief Overview of SAP BW and Its Options

SAP BW is now available in two different versions: SAP BW running on traditional disk-based databases such as Oracle and DB2, and SAP BW running on SAP’s in-memory database, SAP HANA. In addition, the latter option comes in two flavors: SAP BW 7.5, edition for SAP HANA, and SAP BW powered by SAP HANA. Although the names sound similar, the SAP BW 7.5, edition for SAP HANA is slightly different and easier to use than the SAP BW powered by SAP HANA version. Here I explain why the simpler SAP BW 7.5, edition for SAP HANA, is what some companies will elect to implement or initially deploy as they shed the older options for using SAP BW and move exclusively to the new ones.

Note
The focus of this article is on the newest version of SAP BW, SAP BW 7.5, edition for SAP HANA, but in order to understand it fully, you must know more about some of the attributes of the versions of SAP BW that came before it.

Note
SAP BW 7.5, edition for SAP HANA is still in the ramp-up phase and is not publicly available. This article provides a glimpse into the future. If you would like to be a ramp-up customer, contact SAP. The normal SAP BW 7.5 and SAP BW powered by SAP HANA were generally available as of October 2015. Follow this link for more information about this ramp-up for SAP BW 7.5, edition for SAP HANA.

Option 1: Traditional SAP BW (Not on SAP HANA)

Now that you have the background, and assuming you did not deploy SAP BW powered by SAP HANA, you would be using SAP BW traditionally—that is, moving data from your ERP system and other applications to SAP BW and having it perform the three functions listed above.

With traditional SAP BW, you need to physically aggregate data as well as consolidate or homogenize it. You also need to stage the raw data in SAP BW so that the homogenizing process could be as efficient as possible. To do this, the SAP BW system relies on many different object types, as listed in Table 1.

Option 2: SAP BW Powered by SAP HANA

With SAP BW powered by SAP HANA, modeling options include both the SAP BW objects listed in Table 1 and newer SAP HANA-only objects, as follows:

• CompositeProviders: SAP HANA-only objects that allow both unions and joins; these replace the functionality of both InfoSets and MultiProviders.
• Advanced DSOs: These are designed to function in any of the DSO modes in the list in Table 1 (i.e., standard, write-optimized, and direct update). Because they are not limited to 16 key fields, they replace the functionality of InfoCubes.
• Open ODS views: Provide functionality to replace SAP BW Virtual Providers.
• BW WorkSpaces: This toolset gives end users the ability to join or union SAP BW and SAP HANA-based objects and deploy the resulting view as a CompositeProvider—all under the watchful eye of SAP BW administrators, who can ensure that the WorkSpaces don’t grow to consume too much SAP HANA memory.

In addition to the InfoProviders, other SAP BW powered by SAP HANA features include the ability to more easily eliminate many PSAs when it is deployed using the same database as your ERP system. This is because when SAP BW and ERP share the same database, you can more effectively use operational data provisioning (ODP). ODP allows transformations and data transfer processes (DTPs) to point directly to the source system tables so data does not have to be replicated into the PSA. This saves a lot of time on the extraction part of ETL as well as space.

Finally, with SAP BW powered by SAP HANA, you can use all the native SAP HANA modeling tools to build SAP HANA information views that can, in turn, be deployed with SAP BW-modeled objects in composite providers. This means that data-provisioning tools available in native SAP HANA can be used to populate the underlying tables in the SAP HANA information views. SAP HANA provisioning methods include real-time replication and SAP HANA Enterprise Information Management (EIM) tools, such as Smart Data Quality and Smart Data Integration, as well as virtualization with Smart Data Access.

These objects are not the only thing that is different with SAP BW powered by SAP HANA. You also have different data provisioning options for getting data into SAP HANA, which, in turn, means data is accessible to the SAP BW modeling side and SAP BW queries. These additional data-provisioning tools include:

1. SAP Landscape Transformation Replication (SLT) Server – Uses database triggers to facilitate real-time replication.
2. SAP Replication Server (a different product than #1, above) – A log-based way to replicate data in real time.
3. SAP HANA EIM – The SAP Replication Server combined behind the scenes with web-based tools to manipulate data and cleanse it.

Another difference with SAP BW powered by SAP HANA is the SAP HANA analysis process. With SAP BW not on SAP HANA, you get a toolset to perform simple data-mining tasks called the Analysis Process Designer, linked with the Data-Mining Workbench. All the manipulations done by these tools happen in the application server layer. With SAP BW powered by SAP HANA, you also get access to the SAP HANA Analysis Process Designer. This toolset gives SAP BW access to process complex stored procedures and data-mining applications running in-memory on the database server. This means more powerful algorithms that run much faster.

In the future of SAP, I see the Eclipse-based user interface (UI) framework playing a bigger role, with the Windows-based SAP log-on UI playing a much smaller role. To this end, with SAP BW powered by SAP HANA, you can model both SAP BW and SAP HANA-specific objects in SAP HANA studio, which is Eclipse-based. This UI is shown in Figure 1.

Figure 1

Modeling of an SAP BW CompositeProvider using Eclipse-based SAP HANA studio

Finally, as SAP BW seems to be moving away from the SAP log-on for Windows and towards Eclipse, there is an Eclipse version of the SAP Business Explorer (BEx) Query designer. This allows you to build SAP BW models and their queries all in one UI.

Note
For more details about the difference between SAP BW powered by SAP HANA and SAP BW powered by other databases, attend SAP training class BW362.

Let’s move on to the discussion about SAP BW 7.5, edition for SAP HANA.

SAP BW 7.5, Edition for SAP HANA

The goal for SAP BW 7.5, edition for SAP HANA is simple: to simplify SAP BW as part of SAP’s new “run simple” mantra. SAP BW powered by SAP HANA does not make SAP BW simpler. This is because the existing SAP BW objects and tools are added to the older SAP BW objects and tools, which offers a bunch of features, but with a lot more complexity.

With SAP BW powered by SAP HANA, you do gain a lot options for modeling using SAP HANA native modeling, as well as a big increase in the number of data-provisioning options. However, as part of SAP’s goal to simplify, they’ve introduced SAP BW 7.5, edition for SAP HANA, which is much less complex and easier to use than SAP BW powered by SAP HANA.

With SAP BW 7.5, edition for SAP HANA, the system constrains you from building objects that are not optimized for SAP HANA. This means that only the objects or tools listed in Table 2 can be created and used. The table of tools and objects shows the older tools and how to convert them to the newer ones.

As part of SAP’s simplification strategy, only the following tools are supported by this release (Tables 3 and 4). Lastly, on SAP BW 3.x data flows have long been obsolete, and in this version 3.x flows are not supported.

Reading all these lists of successor objects and tools (in the preceding tables) and knowing you need to move to them can be scary. For companies with existing SAP BW systems, it is unrealistic to think you can instantaneously change all the objects in your system at once. In response, when SAP BW 7.5, edition for SAP HANA, is installed, the system defaults to compatibility mode. In this mode all existing older SAP BW objects still work as before, but older object types (listed in Table 4) cannot be created in this environment, except by individually listing them by their technical name in an exception table.

After many months of effort, most companies will have converted the old objects to the new objects, and the system is then manually switched to what is informally referred to as B4H mode. This mode is when the full locked-down mode is reached and when these rules I’ve discussed are applied strictly—in other words, no old objects can be used or accessed whatsoever.  To switch, an ABAP program (program RS_B4HANA_CHECK_ENABLE), run with the proper authorization, must be executed. During this execution the system checks that you have eliminated all the old objects and, once confirmed, converts the system to B4H mode. If it finds any unsupported objects, the process to switch to B4H mode is aborted. If you have done your prep work properly and the conversion is successful, you are left using a simpler system, yet one with the best of the best objects and tools.

Ned Falk

Ned Falk is a senior education consultant at SAP. In prior positions, he implemented many ERP solutions, including SAP R/3. While at SAP, he initially focused on logistics. Now he focuses on SAP HANA, SAP BW (formerly SAP NetWeaver BW), SAP CRM, and the integration of SAP BW and SAP BusinessObjects tools. You can meet him in person when he teaches SAP HANA, SAP BW, or SAP CRM classes from the Atlanta SAP office, or in a virtual training class over the web. If you need an SAP education plan for SAP HANA, SAP BW, BusinessObjects, or SAP CRM, you may contact Ned via email.

You may contact the author at ned.falk@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.