Expand +



The Future of SAP BW: SAP BW 7.5, Edition for SAP HANA

by Ned Falk, Senior Education Consultant, SAP

March 15, 2016

Learn about the newest SAP Business Warehouse (BW), SAP BW 7.5, edition for SAP HANA, and the differences between it and a normal SAP BW-powered by SAP HANA system or SAP BW running on any other database.

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.

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.)

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.

Object type


Persistent Staging Area (PSA)

Raw, un-manipulated data replicated (staged) in SAP BW to facilitate loading into other objects

DataStore Objects (DSOs)

Storage of homogeneous detailed, transaction-level data (write-optimized and direct)


Storage of homogeneous data in an aggregated way with less detail than DSOs


Unions of other InfoProviders (DSOs, InfoCubes, and so on)


Joins of other InfoProviders

Semantically partitioned objects

A wizard-like tool to build DSOs or InfoCubes with many sub-objects. It is like a MultiProvider, but easier.

Virtual providers/transient providers

Virtual objects represent (point to) a source system data without loading it into physical tables in SAP BW.

Table 1 SAP BW object types

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.

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.

Previous object type

Successor object type (optimized for SAP HANA)

Conversion method

DSO (classic)

DSO (advanced)

Transfer tool RSB4HTRF


DSO (advanced)

Transfer tool RSB4HTRF

VirtualProvider based on the data transfer process

Open ODS view


VirtualProvider based on an SAP HANA model

Open ODS view or CompositeProvider


VirtualProviders with function modules

SAP HANA view (in Open ODS view or CompositeProvider)


HybridProvider (InfoCube + DSO [classic])

DSO (advanced)




Manually (transfer with RSB4HTRF is under planning, but currently unavailable)



Transfer tool RSB4HTRF

CompositeProvider (object type COPR)


Transfer tool RSB4HTRF; transfer is possible with the following restrictions (see SAP Note 2080851 [log-on required]):

  • Transferring with the same name is not possible.
  • Transferring CompositeProviders with inner joins to outer joins is not possible.
  • Stricter consistency checks can prevent a transfer from being performed:
    • For example, the associated unit/currency of a key figure must be mapped from the same PartProvider.
    • The target field is shorter than the source field.

InfoObject with master data access via SAP HANA View

Open ODS View


Semantically partitioned object for DSO (classic) and InfoCubes

A functionality for the semantic partitioning for DSO (advanced) is under planning, but is currently not available.


Table 2 A list of InfoProvider tools

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.

Functional area

Previous object types

Sucessor tool/function

Transfer method

BEx web

BEx web template, BEx web item, web design time parameter metadata, and web design time item metadata

SAP BusinessObjects Design Studio


Enterprise reporting

Enterprise report

Crystal Reports via Business Object Enterprise (BOE)


BEx Analyzer

Workbook and theme

SAP BusinessObjects Analysis, edition for Microsoft Office


BEx information broadcasting

Broadcast setting

BOE broadcasting


Integration with SAP BusinessObjects

Xcelsius Dashboard

SAP BusinessObjects Design Studio


Integration with SAP BusinessObjects

Crystal Reports

Crystal Reports via BOE


Table 3 SAP BEx tools

Previous object type

Successor object type (optimized for SAP HANA)

Conversion method

Data-mining model and model source

SAP HANA Analysis Process Designer or native in SAP HANA


Analysis process

SAP HANA Analysis Process Designer and transformation


Table 4 SAP HANA Analysis Process Designer and data-mining tools

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.

An email has been sent to:


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.


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!