SAP BW is a three-tiered, state-of-the-art data warehousing toolset that brings added value over other analytical options such as traditional SAP ERP Central Component (ECC) ABAP-based  reporting, classic InfoSets, or even over native SAP HANA views. Traditionally, SAP BW is installed with its own application servers that can be run on a variety of databases, including SAP HANA. With SAP ECC running on SAP HANA and with SAP BW sharing the same application servers as ECC (embedded SAP BW), companies get 90 percent of the value of SAP BW with little or no additional cost. This is especially true when very little data that is supporting your analytic needs is residing outside of the SAP HANA database on which ECC is running. SAP HANA is much more than a very fast in-memory database. It includes many features that extend its value more than a traditional database, such as a text search engine, a web server, and predictive and geospatial calculation tools that were previously deployed in an application server model running on some databases. As a data warehouse, SAP BW has three main strengths:

1. It homogenizes disparate data from various source systems into valid global data, thus making it meaningful company-wide.
2. It restructures and summarizes data (e.g., aggregating data so that performance across large volumes of data can be acceptable)
3. It provides data analysis tools

When an SAP ECC system runs on SAP HANA, there is no need to materialize aggregates. In addition, SAP HANA provides adequate analytical tools. This means that SAP BW’s role needs to be justified for two reasons—first, as a place to store globally homogenized data and, second, because the analytical tools available with SAP BW are better than SAP HANA’s without SAP BW on top (discussed below). When a company has most of its data just in SAP ECC running on SAP HANA (as many companies commonly do), the homogenizer role for SAP BW is also greatly reduced. So, for these companies, SAP BW is deployed primarily for its analytic tools. As a result, these companies often have to justify having SAP BW, because deploying SAP BW involves additional expense and complications. Therefore, the added benefits of SAP BW over those in native SAP HANA have to be evaluated carefully in light of these perceived drawbacks. However, what if this cost were near zero—at least hardware-wise? In that case, then the benefits offered by SAP BW are more easily justified. Well, this near-zero added cost for having SAP BW is possible, and it’s called embedded BW. Next, I define exactly what embedded BW is, and then review why (even taking into account the advantages of using SAP BW to homogenize and aggregate data), using SAP BW can still be justifiable when implemented in its embedded version.

A Definition of Embedded BW

As of SAP NetWeaver version 7.0, SAP BW software was installed automatically when the ECC system is installed on an application server. Because the SAP BW component is installed on the same servers as the ECC component, and not on its own application servers, SAP terms this SAP BW as the embedded BW. Traditionally, when ECC and embedded BW are installed on non-SAP HANA databases, using this embedded BW software to manage a physical data warehouse (with the load from analysis, extraction, transformation, and loading [ETL]), and for aggregation, was not practical or in any way recommended by SAP. This was because it would compete for database resources with the ECC-related tasks. Instead, in these cases, companies used a separate three-tiered SAP BW system as the warehouse. However, these embedded BW systems did have a few use cases, even in the old days. It was just that most customers were not aware of them. For example, even pre-SAP HANA, embedded BW was used in a few dedicated scenarios, such as:

1. For integrated business planning in the Financials add-on
2. With SAP Business Planning and Consolidation (BPC)
3. For using SAP BW’s Query designer in a very targeted OLAP scenario (i.e., operational reporting), directly on ECC data

Although there were really good use cases for using embedded BW before SAP HANA, most companies did not know—and still do not know—it exists in every newer (since NetWeaver 7.0) ECC system they have. With ECC running on SAP HANA and embedded BW, the need to limit using the SAP BW Query Designer for targeted OLAP (operational reporting) is essentially no longer valid. This is because the database server is so fast. If performance issues arise on your ECC application servers, you can just add more of these servers to load balance.  However, in many cases, and this seems be even more true with each new revision that comes out, the load of a BusinessObjects Explorer (BEx) Query running with SAP BW on SAP HANA is actually processed by SAP HANA, and not the application server. Therefore, if you are a company that gets 90 percent of your data right from ECC running on SAP HANA, and you’re thinking of just using SAP HANA Live supplemented by custom-created SAP HANA-modeled views to feed BusinessObjects Reporting tools, think again. If you use the same hardware, implementing embedded BW to get SAP BW features with only some configuration and setup costs is a very viable idea. Figure 1 illustrates the concept of embedded BW on an SAP HANA database. Understanding Figure 1 in detail helps you to understand completely the concept of embedded BW. Figure 1 shows a dark gray area which depicts the ECC (or SAP ERP suite products) application servers. The light gray area above that depicts the embedded SAP BW software normally installed in a different client automatically on these same application servers. The orange area at the bottom shows that SAP HANA is the underlying database for the ECC application. More specifically, the letter E shows that most of the information on SAP HANA would be packaged as SAP HANA information views as you would do normally if you were modeling without SAP BW. This would include the pre-delivered SAP HANA information views packaged under SAP HANA live. The B in the dark gray area of the figure shows that these SAP HANA views are being virtualized as SAP BW InfoProviders. These views are modeled and controlled by SAP HANA. As a virtual object in SAP BW, no data is actually stored. It is just pointed to when the SAP BW BEx Query is executed. The letters C and D show the more traditional use for SAP BW as a real data warehouse in control of globally homogenous data. In this scenario (the normal BW) the extractor logic is used to load data to the database (SAP HANA), but these objects are managed and controlled with SAP BW modeling tools, not native SAP HANA modeling tools. Using this part of embedded BW means it is being used like a normal SAP BW system with the goal to homogenize or transform the data, then physically store it, in control of the SAP BW application. Since using SAP BW in this way means extra load and resource use, you should only do this for a very small part of the requirements—I would estimate that it not be used for more than 20 percent. If your company has a lot of external data, using embedded BW as a real SAP BW is not advised. Rather, you should look into installing SAP BW the normal way on a different set of application servers. Completing the picture shown in Figure 1, the upper right corner of the light-gray box (identified as SAP BW Query) is very important. It is the main reason, in my mind, to use embedded BW. You get to use the BEx Query designer, now accessing ECC data virtualized via SAP HANA views and SAP BW InfoProviders. Let me use this last point, the BEx Query designer, as a segue into the final section. Here I describe how the use of SAP BW—embedded or not—can be beneficial.

The Benefits of the Embedded SAP BW Scenario

Since SAP BW doesn’t incur any additional costs when you have ECC (or any ERP suite product from SAP), what are the advantages in learning and deploying it as embedded BW? Although SAP BW offers benefits as a global data warehouse to cleanse and store data from various source systems, the recommended use case for embedded BW does not support a large use of external data. Rather, embedded BW is targeting very little external data (from SAP ERP/ECC), and instead allows you to access the ECC tables on SAP HANA through SAP BW. For this reason, I am limiting my list of advantages to those SAP BW benefits that do not focus on significant external data being merged and stored by SAP BW. These benefits include:

1. Access to the SAP BW Query Designer
2. Access to SAP BW hierarchies
3. Better control over and deployment for variables
4. SAP BW authorization
5. Planning

In the following sections, I discuss these benefits in greater detail.

Access to the BEx Query Designer

With an embedded BW system running on the same application servers as SAP ECC running on SAP HANA, the views you model with native SAP HANA modeling tools, as well as the custom extended views derived from the SAP-delivered views of SAP HANA Live, can be easily exposed to embedded BW as transient or virtual SAP BW InfoProviders (Figure 2). Figure 2, I admit, is a bit complicated. This is because when you use SAP BW as a shell on top of SAP HANA, and especially embedded BW, you are presented with so many options to merge physical and virtual sources. Ultimately, one main goal is deploy the BEx Query as a feed on top of the SAP HANA models (for reasons I discuss later in this article). However, for now let’s take a deeper look at the illustration in the figure and sort it out. Figure 2 shows the use of embedded BW as it is primarily intended: as a pass-through virtual layer to access SAP HANA views which, in turn, access the physical tables. In addition, if there are minimal needs, you can also use this embedded BW system as a real data warehouse by physically storing and merging legacy data in tables maintained by SAP BW as physical objects. This includes a store for global master data (e.g., physical InfoObjects and global transaction data) that could be used as the repository for planning applications running on SAP BW. Although any InfoProvider in SAP BW can be used as the source for a BEx query, there is a slight difference between these two subtypes of InfoProviders as shown in Figure 2. With transient providers there is no requirement to map each ECC field to an SAP BW InfoObject (illustrated by the thinner red lines). This allows you to create just the minimal number of important physical or virtual SAP BW InfoObjects, such as cost center, customer, material, and a few more, but not all the fields in the ECC sources would need to be mapped to BW InfoObjects. Many fields could remain unmapped. Contrarily, if an SAP BW virtual provider is used to expose the SAP HANA view as an InfoProvider, all the fields of the SAP HANA modeled view need to be mapped to SAP BW InfoObjects (illustrated by the thicker red lines). For companies that get most of their data from the SAP ERP suite, this 100-percent mapping scenario is most likely unnecessary. Either way—transient or virtual—you decide. Once an SAP HANA view is mapped to an SAP BW InfoProvider, all of the SAP BW BEx Query features become available, even if you have not ever loaded the data via your SAP BW system. You are just leveraging the SAP HANA views as if they were InfoProviders that you built with SAP BW. You could even take things one step further and virtualize you master data as virtual InfoObjects. If you link these to the virtual/transient cubes, then absolutely no data is loaded physically by SAP BW, but, to repeat, you get all the BEx Query features.

Using SAP BW InfoProviders to Access the BEx Query Designer

Unnoticed by the business user, the BEx Query Designer creates the complicated SQL needed to access data from a database. The main reason I like it in an SAP HANA environment is if you just use SAP HANA views and directly feed reporting tools (bypassing SAP BW), all calculated and restricted measures must be created by SAP HANA modelers on the SAP HANA view. It would be impractical to involve the business function experts in this process. Therefore, flexibility is decreased and response time is increased when it comes to trying to solve business problems. BEx Query provides a business-defined layer in which calculated and restricted measures (called key figures) can be defined quickly by business experts, not just by IT. In addition, BEx Query provides other features, such as the ability to create conditional formatting rules in the query definition (in BEx Query these are called exceptions). Finally, if InfoObjects are mapped to fields in the SAP HANA view, you can leverage SAP BW-provided variables maintained in one common place across all views, tied instead to the SAP BW InfoObject that the SAP HANA fields are mapped to. This is as opposed to variable maintenance on each view separately, which would be required when using SAP HANA without SAP BW. Once a BEx query is created, it can be deployed as a consistent base for BusinessObjects reporting tools, directly feeding every tool. This means that, in the case of Web Intelligence, no universe is needed, as it is currently if SAP HANA is deployed without SAP BW. Finally, Figure 2 shows the option of using Smart Data Access to virtualize external data via SAP HANA tools or via SAP BW tools. In this scenario, you might not need to use SAP BW functionality to merge in external data. Rather, you could use SAP HANA Enterprise Information Management (EIM) to load the data that needs to be manipulated to be consumed by an SAP HANA view. If the external data does not need manipulation, it can just be pointed to it as a virtual SAP HANA table. BEx Query also provides even more functionality because you can use it to deploy SAP BW external hierarchies.

SAP BW Hierarchies

Although SAP HANA supports parent–child and level hierarchies, both of these hierarchy types are merely used to display the millions of transactional datasets in a nested manner. Neither of these hierarchy types has the same power as the SAP system’s external hierarchies. With an SAP BW external hierarchy, you can display, for example, a rollup of sales by customer into sub-sales’ regions, sales regions, states, and countries in multiple configurations, simply by dragging and dropping customers into a tree-like structure. Moving customers between regions is done instantaneously and it is not connected directly to the sales transaction data. So, unlike with other tools, restating the hierarchical rollup does not require restating individual sales records and reloading data. This is all made possible by using the external SAP BW hierarchy maintenance transaction code RSH1. In addition, it is possible to virtualize the SAP BW hierarchies directly from ECC hierarchical data, if extra external hierarchies for what-if scenarios or special reporting requirements are not required.

Some Additional Benefits of Embedded BW

There are other benefits to embedded BW, even when your intent is not to load much (if any) non-ECC data under SAP BW control. Many of these benefits are discussed in greater detail in my “Do You Still Need SAP BW If You Have SAP HANA?” BI Expert article. Briefly, these include the ability to use SAP BW variables with SAP BW authorizations. These apply to the embedded scenario for SAP BW as well as the standard way SAP BW is deployed. One special note is the SAP BW planning application, as discussed briefly below.

Planning

Existing planning applications running on SAP BW include BI Integrated Planning and SAP Business Planning and Consolidation (BPC), which SAP is merging into an application called Unified Planning. Also partly because of the need for better planning-related features, the newest ERP offering, SAP S/4HANA (the Simple Finance add-on for SAP HANA), requires the Strategic Enterprise Management (SEM)–SAP BW software component, which means using embedded BW. You can read more about Simple Finance here (log on required): https://websmp209.sap-ag.de/~sapidb/012002523100010452112015E/SFIN_ADMIN_GUIDE_202.pdf.

Final Recommendations

If you are at a small-to-mid-sized company, here, in brief, are my recommendations when it comes to determining what core SAP applications to deploy. First, deploy ECC on SAP HANA, and include SAP S/4HANA to get the Simple Finance functionality. Second, deploy SAP HANA live to get a multitude of delivered SAP HANA views. Finally, deploy SAP BW (which you already have installed) with transient providers on top of all the SAP HANA views. For larger companies or for ones that get a lot of data from external sources and need SAP BW’s ETL and global homogenizing features, consider using the newer SAP HANA database containers (see note above) before you dive into keeping the traditional SAP BW scenario (as a separate three-tiered solution) . In addition, I recommend the following SAP classes:

• HA100 and HA300 (to learn SAP HANA modeling)
• HA350 (only if you need data external to ECC and SAP S/4HANA)
• BW310 for BW basics (but mostly BW362) to learn about BW on SAP HANA
• BW305 to learn the BEx Query Designer