Although most companies currently run SAP Business Warehouse (SAP BW) on traditional disk-based databases, many companies that I deal with are in the process of migrating or greenfielding (i.e., starting a project from scratch) their SAP BW systems to run on the in-memory computing power of SAP HANA. By adopting SAP HANA as the underlying database for SAP BW, companies realize immediate performance gains. SAP BW running on SAP HANA leverages the power of the database to create new InfoProviders that simplify the SAP BW modeling process. These new InfoProviders are designed to replace older ones. This transition should occur as soon as possible after a migration to the SAP HANA database to gain the most performance benefits, as well as for simplification.

Figure 1 shows the newest list of InfoProviders for companies running SAP BW on SAP HANA. It also shows the old InfoProviders used by BW when not running on the SAP HANA database.

Figure 1

The older InfoProviders and the new ones that replace them in SAP BW on SAP HANA

First, let me define the two major categories shown in Figure 1. Physical objects are InfoProviders that store their data in tables created by the SAP BW application on a database (in this case, SAP HANA). The second major category, virtual objects, are InfoProviders that act as temporary collections of data (based on InfoObjects or database fields) that are made available to query by SAP BW, but only during the execution of the query. They are like a pass-through layer between the query and physical tables of data in SAP HANA or, in some cases, other databases, but are not tables that were created by the SAP BW application.

Overview of Physical InfoProviders of the Future

To give the reader context, I explain, in detail, each of these new InfoProviders in the following sections. First I discuss physical objects, followed by virtual objects.

InfoObjects

InfoObjects existed in the past, and they remain the core element in SAP BW modeling. There is not that much difference between the older InfoObjects and the ones with SAP BW running on SAP HANA. InfoObjects are still the fields in most SAP BW virtual and physical InfoProviders. Although they are fields with field length and type settings, they have many other settings as well; in many cases they have associated master data attributes and hierarchy tables. These other settings are why SAP terms them not as fields, but as InfoObjects.

Advanced DataStore Objects (DSOs)

Unlike with InfoObjects, the move to the advanced DSO is a huge change. First, to help you understand the new advanced DSO, here is some technical history about the old InfoProviders.

In the recent past, there were three types of DSO objects: direct update, write optimized, and standard. These DSO objects, depending on their type, consisted of one to three tables.  Direct update DSOs and write optimized DSOs consisted of just 1 table, while Standard DSOs needed 3 tables to work their magic on processing all formats of delta information. They were designed to handle and store detailed data records, such as order numbers and financial postings. InfoCubes, on the other hand, were made up of a complicated star schema of tables (up to 18 tables joined behind the scenes) designed to store summarized data such as sales by month, material, and customer.

Persistent Staging Areas (PSAs) are tables for storing replicated data in its unchanged source system format in SAP BW to separate the move of the data from the manipulation (transformation) of the data into a global format in SAP BW.

HybridProviders are SAP BW objects that combine a real-time or near real-time component of source system data with large amounts of historical data statically stored in SAP BW. The idea of this relatively new type of InfoProvider (e.g., HybridProvider) is that it provides a more efficient way to accomplish real-time operational reporting over that of a virtual InfoProvider.

As shown in Figure 1, all these InfoProviders are being phased out and replaced by the advanced DSO. This new object is built from three tables, but it’s called advanced because of settings that change how and if a core table stores data. With the correct settings enabled, the advanced DSO can behave in your SAP BW system like a PSA by storing raw uncleansed source data. In other cases, the advanced DSO could mimic the functionality of the older standard DSOs. Again, instead of having three different object sub-types, a change in the settings of the advanced DSO lets this new kind of DSO behave in the ways the older ones would. In addition, some combinations of settings in the advanced DSO let you set up use cases that could not be done with the older DSOs.

When it comes to transitioning InfoCubes to the advanced DSO, it is not the settings that allow the transition; rather, it is the speed of SAP HANA. In older, disk-based warehouses, aggregated objects (such as InfoCubes) were needed for performance reasons, as the access time to read millions of records in standard DSOs made performance too slow. With SAP HANA’s speed, it is no longer necessary to aggregate anything. One of the main technical things that the advanced DSO brings to the table versus the standard DSO is that it can handle 120 keys. This feature allows it to replace InfoCubes, as the standard DSO was limited to only 16 keys.

In addition, when advanced DSOs first came out, they could not be used for planning, and, as a result, InfoCubes were still needed. This has changed—in the most recent versions of SAP BW (SAP BW 7.5) this planning functionality has been added.

As Figure 1 also shows, HybridProviders should be transitioned to advanced DSOs. The advanced DSO settings, together with other technologies implemented by SAP, allow the advanced DSO to also take on the role of a HybridProvider, efficiently providing a real-time reporting option via SAP BW. These include a newly designed request system allowing high-frequency data loads connected with the operational data provisioning framework. To learn more about this, follow this link: SAP BW 7.40 – Simplified Real-Time Replication Using Operational Data Provisioning (ODP).

Overview of Virtual InfoProviders of the Future

In this section, I discuss the new virtual InfoProviders. First, I cover the details of CompositeProviders, followed by a discussion of Open Operational Data Store (ODS) views.

CompositeProviders

These newer SAP BW objects, CompositeProviders, are also transformative. Again, some history is needed to grasp the advantages of these new objects vis-à-vis the ones they replace. Figure 1 shows the transition of MultiProvider and InfoSets to CompositeProviders. In the past, MultiProviders performed two functions. First, they allowed for high performance by being umbrella objects over a union of other InfoProviders. Second, they provided a layer over the physical InfoProviders to allow flexibility to change the physical source of data while not affecting the queries written against the MultiProvider. InfoSets are InfoProviders that allow for the joining of other InfoProviders into a virtual object. Although joining InfoProviders, like joining tables, is a very flexible solution to get access to the data you need for analysis, joins are time consuming and make it hard to reach ideal performance goals.

With the addition of CompositeProviders to the toolset (Figure 1), both joins and unions, as well as other features, are able to flexibly combine other SAP BW InfoProviders. In addition, SAP HANA information views are able to be added to a query-able virtual object. Finally, although joins are still slower than unions, the join operation for a CompositeProvider is performed in memory in SAP HANA instead of being transferred to the application server for join operations.

Open ODS Views

The final InfoProvider is the Open ODS view. This virtual InfoProvider is designed to replace the functionality of both virtual and transient InfoProviders, and does so elegantly. Historically, both virtual and transient InfoProviders allowed for a BEx Query to be written on data residing outside the physical SAP BW InfoProviders. For example, a virtual or transient InfoProvider could allow access to a table or view in a completely separate database. One requirement for virtual InfoProviders was that the fields of the real underlying data tables or views were required to be mapped to SAP BW InfoObjects in order to activate the virtual InfoProvider. Although similar, transient InfoProviders could access data that resided outside of the boundaries of the physical SAP BW InfoProviders, they did not require mapping to SAP BW InfoObjects in this case. Again, the new Open ODS view was created to simplify the modeling process, and it flexibly allows—but does not require—mapping to SAP BW InfoObjects.

These Open ODS views can point to SAP HANA information views, which, in turn, point to tables or virtual tables on SAP HANA. When SAP BW is running on the same SAP HANA database as SAP ERP Central Component (ECC) or another Business Suite application, wrapping this Open ODS view around the underlying tables of the ECC application allows for super-fast operational reporting with very little effort.

Now you have a glimpse into the future of SAP BW running on SAP HANA as you move to the latest versions. To find out more, you can attend one of the SAP BW on SAP HANA training classes (BW362). You should also read my second part of this series of BI Expert articles, “An Overview of Simplified Modeling with SAP BW on SAP HANA (Part 2): Using Advanced DataStore Objects,” which provides more detail about the new simplified SAP BW modeling functionality.

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.