SAPANS

Analytics with SAP Solutions

.
.
PARTICIPANT HANDBOOK
INSTRUCTOR-LED TRAINING
.
Course Version: 10
Course Duration: 3 Day(s)
e-book Duration: 5 Hours 45 Minutes
Material Number: 50147751
SAP Copyrights and Trademarks

© 2018 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional
trademark information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only,
without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate
company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business
outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’
strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any
reason without notice. The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking statements are subject to
various risks and uncertainties that could cause actual results to differ materially from expectations.
Readers are cautioned not to place undue reliance on these forward-looking statements, which speak
only as of their dates, and they should not be relied upon in making purchasing decisions.

© Copyright. All rights reserved. iii

Typographic Conventions

American English is the standard used in this handbook.

The following typographic conventions are also used.

This information is displayed in the instructor’s presentation

Demonstration

Procedure

Warning or Caution

Hint

Related or Additional Information

Facilitated Discussion

User interface control Example text

Window title Example text

© Copyright. All rights reserved. iv

Contents

vi Course Overview

1 Unit 1: Native SAP HANA Modeling

2 Lesson: Understanding Native SAP HANA Modeling

22 Lesson: Understanding SAP HANA Live

26 Unit 2: Native SAP HANA CDS

27 Lesson: Positioning SAP HANA CDS

32 Unit 3: S/4HANA and Embedded Analytics

33 Lesson: Describing the Advantages of SAP S/4HANA and

Embedded Analytics
38 Lesson: Consuming an ABAP CDS View in SAP Fiori
39 Lesson: Consuming an ABAP CDS view with SAP Analytics Cloud
40 Lesson: Describing Customer-Defined ABAP CDS Views

46 Unit 4: SAP BW powered by SAP HANA and BW/4HANA

47 Lesson: Describing SAP BW Powered by SAP HANA and BW/

4HANA
51 Lesson: Defining Data Models in BW on HANA and BW/4HANA
72 Lesson: Loading Data into BW on HANA or BW/4HANA
81 Lesson: Describing the Evolution of SAP BW

88 Unit 5: Summary

89 Lesson: Comparing Different Options

96 Unit 6: More Information (Appendix)

97 Lesson: Finding More Information

© Copyright. All rights reserved. v

Course Overview

TARGET AUDIENCE
This course is intended for the following audiences:
● Application Consultant
● Business User
● System Architect
● Technology Consultant

© Copyright. All rights reserved. vi

 UNIT 1 Native SAP HANA
Modeling

Lesson 1
Understanding Native SAP HANA Modeling 2

Lesson 2
Understanding SAP HANA Live 22

UNIT OBJECTIVES

● Explain native SAP HANA Modeling

● Create Calculation Views with SAP HANA Studio
● Create Calculation Views with the Web IDE for SAP HANA
● Explore SAP HANA Live Calculation Views

© Copyright. All rights reserved. 1

 Unit 1
Lesson 1
Understanding Native SAP HANA Modeling

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explain native SAP HANA Modeling
● Create Calculation Views with SAP HANA Studio
● Create Calculation Views with the Web IDE for SAP HANA

Advantages of SAP HANA

There is too much IT complexity in most organizations. Complex landscapes are costly to
maintain with multiple skills needed. Complexity is stifling growth and suppresses agility and
innovation, which is critical to survival in today's digital world.

Figure 1: Advantages of SAP HANA

As the figure, Advantages of SAP HANA, illustrates, the answer is to have all applications
powered by one high performance, multipurpose platform. This means a common
architecture with only one store for all data, regardless of data type. Data is available to all
applications in real time. This means that there is no more data movement or management of
multiple data stores.

© Copyright. All rights reserved. 2

 Lesson: Understanding Native SAP HANA Modeling

Figure 2: Onboard Cache Advances

As the figure Onboard Cache Advances illustrates, advances in the design of on-board cache
mean that data can pass between memory and CPU cores rapidly. In the past, even with large
amounts of memory, this created a bottleneck because the CPUs were demanding more data,
and the journey from memory to CPU was not optimal. You now have sophisticated on-board
CPU cache that keeps the most useful data closest to the CPU, and avoids reading from
memory unless absolutely necessary.
With modern blade-server architecture, you can now add more RAM and more CPUs into your
landscape easily. This adds more processing power or memory, allowing you to scale up to
any size. It would have been possible for SAP to have kept the same business application
software that was written twenty years ago, along with the traditional databases that
supported them, and installed all this on the new powerful hardware. This would provide some
gains, but traditional databases and applications were designed around old, restricted
hardware architecture. This means they would not be able to fully exploit the power of the new
hardware, with all the new developments previously mentioned.
Put simply, the business software needed to catch up with advances in hardware technology.
Thus, a complete rewrite of the platform (SAP HANA), as well as the applications that run on
the platform, was required.
SAP built SAP HANA to fully exploit the latest hardware. SAP collaborated with leading
hardware partners who shared the designs of their new CPU architectures. This enabled SAP
to develop SAP HANA in such a way that it could extract every last drop of power from the
hardware.

© Copyright. All rights reserved. 3

Unit 1: Native SAP HANA Modeling

Figure 3: Database in Memory

As illustrated by the figure, Database in Memory, in the past, databases were stored
completely on disk. Only the data requested by the applications would be moved to memory,
where it then passed to the CPU for processing. Data in memory would be constantly
displaced with new data requests, so a lot of swapping was normal.
With SAP HANA, you can now store the complete database in memory. This means that
nearly no more disk movement is needed and swapping can be eliminated. However, this does
not mean that disk is no longer needed. SAP HANA includes disk store. You need disk for the
following reasons. Data in memory is referred to as "hot", which means it is highly used and
needs to be closest to the CPU for optimum read performance. Less used data can be
classified as "warm", which means it is stored on disk.
SAP HANA will always attempt to store all data in memory. However, most organizations
would not want all data in memory because they regard only a part of it to be hot. The warm
data can wait on disk until it is needed, at which time it is called into memory. Of course, this
means a slight delay in getting data to the CPU when compared to the hot data, but for data
that is warm, this is usually acceptable. This means that you can deliberately size memory
optimally to fit only the hot data and not worry about trying to fit the entire organization's data
in memory. Disk is used as a safe backup of memory, in case of power outage. SAP HANA
regularly saves the entire contents of memory to disk so that when power is restored,
memory can quickly be restored from disk.

© Copyright. All rights reserved. 4

 Lesson: Understanding Native SAP HANA Modeling

Figure 4: Column Cores

As shown in the figure, Column Cores, traditional applications such as SAP Business Suite
were built on a hierarchical data model. Detailed data was summarized into higher-level layers
of aggregation to help system performance. On top of aggregates, more aggregates were
built, as well as special versions of the database tables to support special applications.
As well as storing the extra copies of data, application code had to be built to maintain extra
tables and keep them up to date. These extra tables also needed to be backed up, so even the
IT operations were impacted.
In addition to aggregates, another inefficiency needed to be removed. Database indexes
improve access speed because they are based on common access paths to data. However,
they need to be constantly dropped and rebuilt each time the tables are updated, and more
code is needed to manage this process. Using the raw power of SAP HANA, we can aggregate
on the fly in sub-seconds from any line item table. There is no need for prebuilt aggregates.
SAP HANA can generate any view of the data at runtime, all from the same source tables.
SAP HANA organizes data using column stores, which means indexes are usually not needed.
They can still be created, but usually offer little improvement. Therefore, as well as losing the
aggregates and indexes from the database, we can also lose huge amounts of application
code that deal with aggregates and indexes. Inside SAP S/4HANA almost all aggregation and
index tables are eliminated. For example, there are seven (index-) tables inside the SAP S/
4HANA Finance module, fewer than in ECC.

© Copyright. All rights reserved. 5

Unit 1: Native SAP HANA Modeling

Figure 5: Push-Down

The figure, Push-Down, illustrates how the handling of data requests has changed in SAP
HANA. For example, if the application layer sends the instruction "please summarize the last
five years' sales line items of yellow widgets into region totals by year, and calculate the net
value after discount" to SAP HANA. Instead of sending millions of basic rows from the
database to the application layer, SAP HANA processes the data request and sends back only
the results to the application layer. A huge reduction in data volume is being passed.
As well as this, the data processing is done in memory by SAP HANA, so performance is
excellent too. Moving the data processing tasks from the application layer to the database
layer is called push-down. Push-down means that application developers need to rethink their
approach.
In the past, all coding focused on the application layer, but now with SAP HANA, large parts of
the coding can be pushed down. This means that developers need to think of how to ensure
that they pass challenging data processing tasks to SAP HANA, instead of expecting the
application layer to handle this.

© Copyright. All rights reserved. 6

 Lesson: Understanding Native SAP HANA Modeling

Figure 6: Transactional and Analysis Combined

SAP HANA takes on the challenges of combining transactional and analysis processing in one
platform, as the figure, Transactional and Analysis Combined, illustrates. The database,
hardware, and data model of SAP HANA are built for combined transactional and analysis
purposes. No movement of data is necessary and you always work from the same, single copy
of the data for any requirement. This is true for both transactional and analytical
requirements. This means that you have live data available to all applications. This reduces
the complexity by removing the need to move data using separate software.

SAP HANA Modeling Principles

Figure 7: SAP HANA Modeling Principles

© Copyright. All rights reserved. 7

Unit 1: Native SAP HANA Modeling

As the figure, SAP HANA Modeling Principles, illustrates, with SAP HANA, we can build a
sophisticated modeling layer on top of the database tables. This means we can first process
the raw data and turn it into something meaningful in the database before passing it on to the
application.
With SAP HANA, we build calculation views to combine data from multiple tables, and apply
filters, conditions, calculations, and aggregations. The calculation views are developed in SAP
HANA using easy-to-use modeling tools, and are stored in SAP HANA alongside the database
tables in the database. Therefore, instead of the application processing the raw data, the
application calls the required calculation views and the processing is pushed down to SAP
HANA. This is efficient in the following ways: The application code is simplified, because it
does not have to deal with many data processing tasks. These tasks are pushed down to SAP
HANA where in-memory processing takes place. The processing on the data is carried out
where the data resides, so we do not have to move raw data from the database to the
application. We only move the results of the data processing to the application. The
calculation views can be reused in multiple applications so we avoid redundancy.
The purpose of information views is to organize the data from the individual transactional
tables, and to perform a variety of data calculations, in order to get a relevant and meaningful
set of measures and dimensions or attributes to answer a specific reporting need. You can
make the data more meaningful than it is in the source tables by customizing the column
names, assigning label columns to key columns, and calculating additional attributes.

Figure 8: Measures and Attributes

When you report on data, you have to distinguish between the following important concepts:
Measure, Attribute.
As the figure, Measures and Attributes, describes, a measure is a numeric value, such as a
price, quantity, volume, on which you can process arithmetic or statistics operations, such as
sum, average, top N values, and calculations.

© Copyright. All rights reserved. 8

 Lesson: Understanding Native SAP HANA Modeling

An attribute is an element that is used to describe a measure. Attributes are used to filter or
aggregate the measures, in order to answer questions such as the following: What are the
total sales originating from Sales Org. located in the EMEA region? What is the sales revenue
generated by the product cars?
In a number of cases, analyzing the measures is easier if you group attributes together by
dimension. In the examples shown in the figure, the sales organization would be treated as a
dimension, with the following associated attributes: Country, Region. Similarly, a Product ID
dimension could be associated with several attributes, such as product name, product
category, or supplier.
A Star schema consists of one fact table that references one or several dimension tables. The
fact table contains facts, or measures, as well as the keys used to identify - for each
dimension - which dimension member corresponds to each fact. Each dimension contains
attributes, such as the name of the dimension member, description, and other attributes that
can be used to filter the dimension members, build a hierarchy, and perform specific
calculations.

Figure 9: Types of Calculation View

The figure, Types of Calculation View, lists the properties of the calculation views supported in
SAP HANA.
A graphical calculation view defined with the DEFAULT data category is never exposed to
client tools. It can contain both attributes and measures. The main use case for this type of
view is when you create views that will be reused in other views but do not need to be
accessed by the end user. Dimension calculation views do not allow measures; any numeric
columns or values will always be treated as attributes. When you analyze data including
measures, you use a calculation view of the type CUBE or CUBE with star join.
These types of views provide a number of features to filter data, control the aggregation of
data, perform complex data calculations on measures, combine data from several data sets,
retrieve sub-sets of data based on measure ranking (for example, the top countries for
revenue or margin). In this scenario, a cube with star join calculation view enables a
multidimensional reporting that leverages the source data (from the Vbap and Bvak tables)
and dimension calculation views created for the main dimensions, such as Product,
Employee, or Customer. Multidimensional tools support hierarchies for navigation, filtering
and aggregation, as well as prompts (variables and input parameters) for efficient pre-filtering
of data.

© Copyright. All rights reserved. 9

Unit 1: Native SAP HANA Modeling

Figure 10: Data Source Types

The figure, Data Source Types, lists the main data source types that are supported in SAP
HANA calculation views. It makes a distinction based on whether the data source is located in
the same database as the calculation view that consumes it, or in a different database within
the same multi-database container (MDC) system. Multi-database container system is the
separation of one physical SAP HANA database in several tenants.

Figure 11: Semantic Nodes

The figure, Semantic Nodes, lists the semantic nodes supported in calculation views in SAP
HANA.
Every calculation view has a semantic node. You do not add this; it is already present and will
always be the top node regardless of the data category of the calculation view. In this node,
you assign semantic to each column in order to define its behavior and meaning. This is
important information used by consuming clients so that they are able to handle the columns

© Copyright. All rights reserved. 10

 Lesson: Understanding Native SAP HANA Modeling

appropriately. The most important setting for each column is its column type. You can choose
between attribute or measure.
In the semantic node, you can also optionally assign a semantic type to each column. A
semantic type describes the specific meaning of each column and this can be helpful to any
client that consumes the calculation view so it can then represent the columns in the
appropriate format. For example, if you define a column as a date semantic type, the front-
end application can then format the value with separators rather that a simple string. The key
point is that it is the responsibility of the front-end application or consuming client to make
use of this additional information provided by the semantic type.
A projection node is typically used in the following scenarios: To filter measures based on
attributes values. To extract only some columns from a data source.
Using a projection node is also a prerequisite to compute a calculated measure before an
aggregation. Indeed, calculated columns in the aggregation nodes of calculation views are
always executed after the aggregation.
The join node is used to join two (and only two) sources. If you need to join more than two
sources, you can stack several joins in the scenario of your calculation view. For each join
node, you must define which columns of the two joined sources must participate in the join, as
well as the join type, as discussed in the lesson Connecting Tables. You can also specify the
cardinality (with the help of the Propose Cardinality feature), but only if you are sure that the
cardinality you provide corresponds to how the data is actually organized.
If your source data for a graphical calculation view is of a star schema type, you can create a
calculation view of type cube with star join. A star join node enables you to join the fact data
with the descriptive data. The input allowed to the star join include the lower node and all the
relevant calculation views of type dimension. This way, you are logically creating a star
schema where the join is created from the central entity to the other entities. A union node is
used to combine two or more data sets to a common set of columns. Depending on how
different the column names are from the data source, you can map the columns automatically
by name (columns with identical names will be mapped automatically) or define the mapping
manually. The purpose of an aggregation node is to apply aggregate functions to measures
based on one or several attributes. The purpose of the rank node is to enable the selection,
within a data set, of the top or bottom 1, 2, ... n values for a defined measure, and to output
these measures together with the corresponding attributes and, if needed, other measures.
For example, with a rank node, you can easily build a subset of data that gives you the five
products that generated the biggest revenues (considering the measure Gross Amount) for
each country.

© Copyright. All rights reserved. 11

Unit 1: Native SAP HANA Modeling

Figure 12: Join Types

The figure, Join Types, lists the join types supported by SAP HANA. The inner join is the most
basic of the join types. It returns rows when there is at least one match on both sides of the
join.
A left outer join returns all rows from the left table, even if there are no matches in the right
table.
A right outer join returns all the rows from the right table, even if there are no matches in the
left table.
A full outer join combines the behaviors of the left and right outer joins. The result set is
composed of the following rows:
● Rows from both tables that match on joined columns
● Rows from the left table with no match in the right table
● Rows from the right table with no match in the left table

A referential join is semantically an inner join that assumes that referential integrity is given,
meaning that the left table always has a matching entry in the right table.
It is an optimized or faster inner join where the right table is generally not checked if no field
from the right table is requested.
A text join enables SAP HANA to handle the translation of attribute labels in a way that
corresponds to the way translation texts are stored in the master data or SAP systems, such
as SAP ERP.
It is possible to add a temporal condition to a join in order to find matching records from two
tables based on a date. The records are matched only if a date column of one table is within a

© Copyright. All rights reserved. 12

 Lesson: Understanding Native SAP HANA Modeling

time interval defined by two columns of the other table. This is useful to manage time-
dependent attributes.
A spatial join enables the modeler to use the native spatial capabilities of SAP HANA in
graphical modeling tools.

Figure 13: Design-Time and Runtime Objects

As the figure, Design-Time and Runtime Objects, illustrates, when you create or modify an
information view with the SAP Web IDE for SAP HANA, the design-time object is located in a
project within your workspace. This workspace is linked to your SAP Web IDE user and is not
visible to other users in the same SAP HANA system. When you build a file with the SAP Web
IDE, SAP HANA creates the corresponding runtime objects in a so-called container, which is
an abstraction layer for a database schema. This container is specific to the HDB module of
your project.

SAP HANA 1.0 vs. SAP HANA 2.0

Figure 14: Comparing SAP HANA 1.0 to SAP HANA 2.0

As the figure Comparing SAP HANA 1.0 to SAP HANA 2.0 illustrates, SAP HANA 1.0 SPS12 is
ideal for customers seeking a stable platform without frequent updates to run their mission-
critical applications. There will be no support packs after SPS12 on SAP HANA 1.0. Only
software fixes are provided, through maintenance revisions, until May 2021. Customers
running SAP HANA 1.0 should consider upgrading to SPS12 if they are on lower support
packs, to get the maintenance until May 2021.

© Copyright. All rights reserved. 13

Unit 1: Native SAP HANA Modeling

SAP HANA 2.0 is ideal for customers seeking a platform that enables them to leverage the
very latest technology innovations. Customers can build next-generation applications and
also run mission-critical applications on SAP HANA 2.0. The SAP HANA 2.0 platform inherits
all the features and capabilities of SAP HANA 1.0 but with significant additional innovations.
All content built with SAP HANA 1.0 continues to run on SAP HANA 2.0 with no changes.
Natively built modeling objects have to be migrated via the XSA migration assistant. From a
modeler’s perspective the main differences affect new modeling features (e.g. graph node,
intersect node), a new user interface (WEB IDE for SAP HANA), a new modeling environment
(HDI Container) and a different security concept (no package privileges).

Figure 15: XS Design-Time and Runtime Architecture

Since SAP HANA 1.0 was released in early 2011, the design and run-time architecture has
remained stable. As the figure XS Design-Time and Runtime Architecture illustrates, database
artifacts and source code would sit in a giant single system-wide repository that was
organized by packages. From there, development artifacts would be activated, and the
generated runtime database objects and applications would be placed in database schemas
and in the XS engine runtime. Only one version of the activated objects could exist, which
meant you could not deploy an updated version of an application while still retaining the
original version. XS was tightly integrated with the HANA database, which meant you could
not scale either separately. Each application that was developed could only have one
deployment target. For example, you could not develop a single application and deploy it as
both an on-premise and a cloud application. You would have to create two separate
applications. This original architecture is known as "XS classic/repository based".
Since SAP HANA 1.0 SPS11, a new, flexible approach that is much more powerful has been
introduced for development and runtime. Customers are encouraged to move over to the new
architecture to take advantage of many new features. Eventually, XS classic will no longer be
relevant and will not be the focus of any more development by SAP.

© Copyright. All rights reserved. 14

 Lesson: Understanding Native SAP HANA Modeling

Figure 16: XSA Design-Time and Runtime Architecture

The new architecture includes a more advanced version of Extended Services (XS), called
Extended Services Advanced (XSA). As the figure XSA Design-Time and Runtime
Architecture illustrates, XSA is decoupled from the database to provide more flexibility and
ease of scalability. XSA can now be sized independently from the HANA database. Application
source code is no longer stored in the internal repository of HANA, but in an industry
standard, external repository called Git. This allows much improved version control and
collaboration. Git manages source objects across multiple instances of HANA. For managing
database objects, the new architecture includes a new deployment approach called HANA
Deployment Infrastructure (HDI). This includes the generation of deployment containers,
which are used to store all runtime objects for an entire application.

© Copyright. All rights reserved. 15

Unit 1: Native SAP HANA Modeling

SAP HANA Studio

Figure 17: SAP HANA Studio Screen Layout

The figure, SAP HANA Studio Screen Layouts, gives an example of the HANA Studio screen.
SAP HANA Studio provides many different screen layouts that are built by SAP and organize
screen content and tooling for each type of SAP HANA persona. These are called
perspectives. When you launch SAP HANA Studio, you will be asked to choose a perspective.
A modeler would chose the SAP HANA Modeler perspective.
It is easy to jump between perspectives once you are inside the interface. For example, you
may want to jump to the Administrator perspective in order to check that a service is running,
or check memory consumption.
Even though SAP HANA 2.0 uses WEB IDE for SAP HANA as the new UI, SAP HANA Studio is
still relevant for some scenarios such as SAP HANA 1.0 modeling scenarios (old objects), BW
on HANA; BW/4HANA mixed modeling scenarios, SAP HANA Live scenarios, and migration of
SAP HANA 1.0 objects to SAP HANA 2.0 environment (until SAP HANA 2.0 SPS 03).

© Copyright. All rights reserved. 16

 Lesson: Understanding Native SAP HANA Modeling

SAP Web IDE for SAP HANA

Figure 18: SAP Web IDE for SAP HANA

SAP Web IDE for SAP HANA and the database explorer enhance the development experience
by providing the following features:
● Integrated Workspace and Project Management
- The latest tool versions without additional installation
- Full workspace management on the server
- Integrated Git-based version control
- A dedicated template and wizards for multi-target application projects
● Development Tools
- Graphical modelers for complex artifacts, such as data models or calculation views
- An SQL console and an MDX console in the database explorer
● Build, Run, and Deploy
- Incremental build support
- Structured console output and logging
- Automatic creation of development sandboxes on SAP HANA (HDI containers)
- Automatic provisioning of HDI container services
- Generation of deployment archives

To launch the Web IDE for SAP HANA, you need to obtain the URL from the administrator.
This will include the host name where HANA is installed, which is unique for each installation.
After launching the URL, the screen shown in the figure, Launching Web IDE for SAP HANA,
will be displayed.

© Copyright. All rights reserved. 17

Unit 1: Native SAP HANA Modeling

Figure 19: Projects in the SAP Web IDE

As the figure, Projects in the SAP Web IDE, illustrates, the workspace in the SAP Web IDE is a
structure where you can store one or several projects. Each user of the SAP Web IDE for SAP
HANA has their own workspace. The workspace of a user can contain as many projects as
needed, but each project must have a different name. When you create a project, you choose
a project template, depending on the type of application you want to create. Currently, the
SAP Web IDE comes by default with one template, which is called the Multi-Target Application
(MTA).
An MTA comprises multiple parts, or modules, created with different technologies and
deployed to different targets, but with a single common lifecycle. An HDB module contains all
the design-time files that define the database objects that must be deployed together with the
application.
The table, Settings for MTA, lists the settings you need to specify when creating an MTA.

Table 1: Settings for MTA

Setting Description Example

Project name The name given to the new

project in your workspace
Application ID The identifier of the MTA, 1.0.3
used during deployment. This
must be unique in the target
environment, and uses the
reverse-URL dot-notation.
Description A free text describing the
purpose of the MTA
Space The space where you want to DEV
build your project content
during the development
phase

© Copyright. All rights reserved. 18

 Lesson: Understanding Native SAP HANA Modeling

The table, Settings for HDB Module, lists the settings you need to specify for the modules that
comprise the MTA.

Table 2: Settings for HDB Module

Setting Description Example

Name The name of the module. It core-database-module

should be unique within the
entire descriptor file
(mta.yaml)
Type hdb is the reserved module hdb
type for a HDB module
Path The relative location of the db
module root within the file
structure of the project
Schema Name A specific name for the HDB SAMPLE_SCHEMA
module container, used dur-
ing build and deployment
SAP HANA Database Version The SAP HANA database ver- _schema-version: “2.0”
sion against which artefacts
of the HDB module must be
validated

The main database artefacts defined in a HDB module are as follows:

Main Database Artefacts Defined in a HDB Module

● Tables
● Table data
● Calculation views
● CDS views
● Table functions
● Procedures
● Analytic privileges
● Synonyms

Due to the new modeling environment (HDI) tables should be generated only with HANA CDS
syntax (DDL) so they can be used in further modeling scenarios.
Table data is an approach to load data from flat files (e.g csv) into physical tables which are
stored inside an HDI module.
HANA CDS views are SAP HANA native objects which can also be used to build a modeling
environment. They are intended more for SAP HANA developers.
Table functions are comparable to calculation views only designed in SQL Script without using
a graphical editor and can be consumed directly by the calculation view.

© Copyright. All rights reserved. 19

Unit 1: Native SAP HANA Modeling

Procedures are comparable to calculation views and table functions, designed in SQL Script
or R-Language, but they are a lot more flexible than our usual modeling objects. For instance
it is possible to execute write operations which is not possible with the calculation view.
Analytic privileges are security-based objects to restrict data on row level and have to be
implemented in calculation views especially in two-tier scenarios or/and mixed BW modeling
scenarios.
Synonyms are objects to reference objects such as tables in foreign HDI Containers.

Figure 20: Table Functions

As the figure, Table Functions, illustrates, in SAP HANA modeling, table functions are typically
used to generate a tabular data set that is used as a data source in a calculation view. Table
functions can be used in SQL Script in a FROM clause of a select statement (in other words
wherever a standard table is used). A table function encapsulates the logic in a reusable form
so that it can be used many times in different artefacts. Table functions can accept one or
more input parameters. Table functions are read-only; that is, they cannot be used to change
data. Table functions produce exactly only one tabular output. Table functions can also call
other functions.

© Copyright. All rights reserved. 20

 Lesson: Understanding Native SAP HANA Modeling

Figure 21: Procedures

Procedures define reusable data processing logic that can be used to enhance a calculation
view. As the figure, Procedures, illustrates, procedures are very similar to functions in that
they are written in SQL Script, can have one or more inputs and they always have outputs.
However, procedures can produce multiple output data sets of different structures, whereas
a table function can only return one tabular output data set. Procedures cannot be used as
data sources to calculation views. They are used throughout the calculation view, especially
where some processing logic is required, for example, to automatically derive values for an
input parameter, or to return values used in analytic privileges. A procedure can be called
directly from SQL Script, which means it can be called from a function or even another
procedure. Procedures used within modeling are mostly used as read only. In that case they
are called stateless (or side-effect free), because they don't alter any data in the database.
However, procedures can also be used to update, insert, and delete data. These procedures
are called stateful, and they are not allowed when called from calculation views. Stateful
procedures are more likely to be used by developers building applications.

LESSON SUMMARY
You should now be able to:
● Explain native SAP HANA Modeling
● Create Calculation Views with SAP HANA Studio
● Create Calculation Views with the Web IDE for SAP HANA

© Copyright. All rights reserved. 21

 Unit 1
Lesson 2
Understanding SAP HANA Live

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explore SAP HANA Live Calculation Views

SAP HANA Live

Figure 22: SAP HANA Live

As the figure, SAP HANA Live, illustrates, SAP HANA Live is a comprehensive set of SAP-
supplied calculation views that expose live transactional and master data tables from SAP
Business Suite applications. These include SAP ERP, SAP CRM powered by SAP HANA, SAP
SCM, and so on.
SAP HANA Live is not relevant for S/4HANA.
Due to the high degree of normalization of the database schemas found in SAP Business Suite
applications, tables can appear complex, fragmented, and are often difficult to consume
without a thorough understanding of each schema. SAP HANA Live provides ready-to-use
business views of the Business Suite source tables. This means that report developers and
application builders can easily consume live business information without being concerned
about the underlying table complexities. The calculation views are created and maintained by
SAP using standard SAP HANA modeling tools, so that they can be modified easily by

© Copyright. All rights reserved. 22

 Lesson: Understanding SAP HANA Live

customers using the same tools. The key use case for SAP HANA Live is real-time operational
analytics on SAP Business Suite. SAP HANA Live is a read-only virtual data model, so it is of
no use for applications that need to write data back to the database. SAP HANA Live can be
consumed immediately by SAP BusinessObjects reporting tools and, in fact, any clients that
are able to consume standard SAP calculation views by SQL and MDX. SAP HANA Live
models contain all the necessary joins, filters, aggregations, and transformations to transform
the data in the raw Suite tables into meaningful information. They are compiled into column
views that are technically no different from the column views created from customer
calculation views.

LESSON SUMMARY
You should now be able to:
● Explore SAP HANA Live Calculation Views

© Copyright. All rights reserved. 23

 Unit 1

Learning Assessment

1. Why might I choose SAP HANA 2.0 instead of SAP HANA 1.0?
Choose the correct answers.

X A I want to use the latest technology

X B I want to follow development approaches such as Cloud Foundry

X C I want to work with SAP HANA Studio

X D I want to store data in column and row store-based tables

2. Which of the following statements applies to SAP HANA Live?

Choose the correct answer.

X A SAP HANA Live is a virtual data model provided for SAP ERP.

X B SAP HANA Live is a virtual data model provided for S/4HANA.

X C You can explore SAP HANA Live using the SAP WEB IDE for SAP HANA.

© Copyright. All rights reserved. 24

 Unit 1

Learning Assessment - Answers

1. Why might I choose SAP HANA 2.0 instead of SAP HANA 1.0?
Choose the correct answers.

X A I want to use the latest technology

X B I want to follow development approaches such as Cloud Foundry

X C I want to work with SAP HANA Studio

X D I want to store data in column and row store-based tables

Correct! With SAP HANA 2.0, you can follow development approaches such as SAP Cloud
Foundry, and use the latest technology. However, SAP HANA Studio and column and row
store-based tables are both available in SAP HANA 1.0 as well as SAP HANA 2.0. For more
information, see the lesson Understanding Native SAP HANA Modeling in the SAPANS
course.

2. Which of the following statements applies to SAP HANA Live?

Choose the correct answer.

X A SAP HANA Live is a virtual data model provided for SAP ERP.

X B SAP HANA Live is a virtual data model provided for S/4HANA.

X C You can explore SAP HANA Live using the SAP WEB IDE for SAP HANA.

Correct! SAP HANA Live is a virtual data model provided for SAP ERP. For more
information, see the lesson Understanding SAP HANA Live in the course SAPANS.

© Copyright. All rights reserved. 25

 UNIT 2 Native SAP HANA CDS

Lesson 1
Positioning SAP HANA CDS 27

UNIT OBJECTIVES

● Explain the positioning of SAP HANA CDS

© Copyright. All rights reserved. 26

 Unit 2
Lesson 1
Positioning SAP HANA CDS

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explain the positioning of SAP HANA CDS

SAP HANA CDS Positioning

The figure, Main Properties of SAP HANA Core Data Services (CDS), lists the features of SAP
HANA CDS.

Figure 23: Main Properties of SAP HANA Core Data Services (CDS)

HANA CDS is a component of SAP HANA. It sits on top of the SAP HANA database as part of
native SAP HANA database artifacts. HANA CDS is built using a programming language very
similar to SQL, stored in CDS documents (SQL Script + Annotations). The CDS documents
are maintained in the SAP HANA Studio or Web IDE for SAP HANA editors. They are
physically stored in SAP HANA. Furthermore it is even possible to create HANA CDS artefacts
via a graphical editor, which is on the other hand not that powerful as the one when creating
calculation views. With CDS you not only expose tables for analytic purposes, but you can also
use CDS in many other use cases such as the “Data Warehouse Foundation” (aka SQL Data
Warehouse). One of the most important objects for the SQL Data Warehouse approach is the
native DSO which is also being built (from SAP HANA 2.0) with SAP HANA CDS DDL.

© Copyright. All rights reserved. 27

Unit 2: Native SAP HANA CDS

Figure 24: SAP Enterprise Architecture Designer (EAD)

SQL Datawarehouse in SAP HANA is the idea to create a SQL driven native SAP HANA
Datawarehouse in a greenfield scenario. This includes dataflows (flowgraphs) and
persistencies (entities and native DSO).
As the figure, SAP Enterprise Architecture Designer (EAD), illustrates, the tool that supports
the design of the datawarehouse concept (not the actual building process) is the EAD. We are
able to design dataflows in EAD and to push them to the SAP Web IDE for SAP HANA in
flowgraph format. We are able to design entities (tables defined in CDS), views (HANA or even
calculation views) and native DSO and to push them to the SAP Web IDE for SAP HANA. With
the “reverse engineer” function, we are even able to pull classic database schemas (e.g.
tables built in SQL), convert them into CDS DDL and push them into SAP Web IDE for SAP
HANA. Detailed modeling work such as hierarchies, input parameters, and filters need to be
implemented in the further step in the graphical editor in the SAP Web IDE for SAP HANA.
As mentioned, the native DSO provides persistencies in SAP HANA which can even include
delta logic.

© Copyright. All rights reserved. 28

 Lesson: Positioning SAP HANA CDS

Figure 25: CDS DDL

CDS DDL (or graphical) is the new approach to define and create entities (physical SAP HANA
tables) inside the SAP HANA HDI Containers. The idea is to create a generated design- time
file which references to the according physical table which is not used when building entities
with SQL. This avoids a loss of the definition statements and provides an easier way to
transport and to share the entities (e.g. via Git technology). From a modeler’s perspective, the
SAP HANA CDS DDL is particularly relevant especially in cases where the modeler has to
create new physical SAP HANA tables inside the new HDI environment.

SAP HANA CDS Views Compared with Calculation Views

The graphical calculation view is the main BI reporting object within the native SAP HANA
modeling environment because of ongoing features, in-depth modeling functions and a very
powerful graphical editor. Thus the graphical calculation view is the recommended object for
deep Analytics scenarios which are being built natively inside the SAP HANA system. Even for
mixed modeling scenarios in SAP BW powered by HANA/SAP BW/4HANA the Composite
provider combines first of all SAP BW Infoprovider and graphical calculation views. On the
other hand SAP HANA CDS views are necessary for specific scenarios such as SQL Data
Warehousing or consuming views via Odata with SAP Fiori Apps.

LESSON SUMMARY
You should now be able to:
● Explain the positioning of SAP HANA CDS

© Copyright. All rights reserved. 29

 Unit 2

Learning Assessment

1. What is the main property of SAP HANA CDS?

Choose the correct answer.

X A SAP HANA CDS are natively built in SAP HANA.

X B SAP HANA CDS can be built only with a script in CDS DDL, not with a graphical
editor.

X C SAP HANA CDS are supported only in SAP HANA 2.0

© Copyright. All rights reserved. 30

 Unit 2

Learning Assessment - Answers

1. What is the main property of SAP HANA CDS?

Choose the correct answer.

X A SAP HANA CDS are natively built in SAP HANA.

X B SAP HANA CDS can be built only with a script in CDS DDL, not with a graphical
editor.

X C SAP HANA CDS are supported only in SAP HANA 2.0

Correct! SAP HANA CDS are built natively in SAP HANA. They can be built from SAP
HANA 1.0 SPS11, and they can be built using a graphical editor.

© Copyright. All rights reserved. 31

 UNIT 3 S/4HANA and
Embedded Analytics

Lesson 1
Describing the Advantages of SAP S/4HANA and Embedded Analytics 33

Lesson 2
Consuming an ABAP CDS View in SAP Fiori 38

Lesson 3
Consuming an ABAP CDS view with SAP Analytics Cloud 39

Lesson 4
Describing Customer-Defined ABAP CDS Views 40

UNIT OBJECTIVES

● Explain SAP S/4HANA and Embedded Analytics

● Consume an ABAP CDS View in SAP Fiori
● Consume an ABAP CDS view with SAP Analytics Cloud
● Explain ABAP CDS Views

© Copyright. All rights reserved. 32

 Unit 3
Lesson 1
Describing the Advantages of SAP S/4HANA
and Embedded Analytics

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explain SAP S/4HANA and Embedded Analytics

SAP S/4HANA and Embedded Analytics

2015 - A new wave of advances in hardware architecture brings massive computing power at
decreasing costs. Huge memory and multi-core processors arrive to offer massive computing
power. The underlying design of existing SAP applications does not fully exploit the power of
the new hardware. A complete rewrite of the Business Suite is required.

Figure 26: Evolution of SAP Business Suite

As the figure, Evolution of SAP Business Suite illustrates, the new business suite is called SAP
S/4HANA. A crucial point is that SAP S/4HANA is built natively and optimally to run only on
the SAP HANA platform. By contrast, SAP Business Suite was built many years ago to run on
any platform and so the design of the code and data model was not optimized for any one
particular platform. A key objective back then was flexibility of the solution. SAP allowed
customers to choose the various components of the solution: the database, the operating
system and hardware that they preferred. However, SAP S/4HANA is built only to run on SAP
HANA and SAP HANA only runs on the fastest hardware available. This is how SAP can deliver

© Copyright. All rights reserved. 33

Unit 3: S/4HANA and Embedded Analytics

a platform with phenomenal performance to cope with today's massive data volumes and also
the high expectations of business users of instant response.

Figure 27: Advantages of S/4HANA Data Model

As the figure, Advantages of the S/4HANA Data Model, illustrates, S/4HANA is based on a
new developed data model (e.g. no BSIS, BSID,VBUK) without any aggregation and index
tables. The idea is to reduce the data footprint and with this to increase performance, for
example, by avoiding the regular update of the redundancies. Furthermore in S/4HANA the
trend is towards a “single point of truth", which leads to higher data quality.

Figure 28: Operations in S/4 HANA

Many operations in S/4HANA are accelerated via the push-down approach (from code to
data). For example, as the figure Operations in S/4HANA illustrates, with SAP S/4HANA,
material requirements planning (MRP) is a real-time process. This is achieved because of the
raw power available with SAP HANA, and the dramatically simplified data model and
application code that runs faster. MRP is no longer a painful batch process, which means you

© Copyright. All rights reserved. 34

 Lesson: Describing the Advantages of SAP S/4HANA and Embedded Analytics

can run it whenever an individual change occurs in the inventory position right down the BOM
component level. This means MRP is always live.
Also, with SAP S/4HANA, you can now plan right down to a lot size of one. If a customer order
is taken, you can immediately determine the effect on all the dependent subcomponents'
requirements, but only for that single order. This means the inventory department can
immediately begin working on the procurement of the missing items and do not have to wait
until the next MRP run to tell them subcomponents are missing and need to be ordered.

Figure 29: SAP Fiori

With SAP S/4HANA comes a brand-new user experience. This is called SAP Fiori, as
illustrated in the figure, SAP Fiori. SAP Fiori is not a software product, but the name of a new
design approach that was created especially for SAP S/4HANA. Key aspects of the design of
SAP Fiori applications are as follows:
● They must run comfortably on any device, and present a modern consumer-grade quality.
● They focus on specific job functions (as opposed to an overcomplicated screen filled with
functions for different users).
● They offer only the essential information that users need to get their jobs done with no
clutter.
● They allow tasks to be completed with very few clicks or screen changes.
● They are intuitive to use, with little or no training required.
● They can include embedded analytics to support in-process decision making.
● They have a consistent look and feel across applications.

In many cases, a single SAP Fiori application can replace many individual SAP GUI
transactions.

© Copyright. All rights reserved. 35

Unit 3: S/4HANA and Embedded Analytics

Figure 30: S/4HANA Simple Data Model

As the figure, S/4HANA Simple Data Model, illustrates, SAP S/4HANA, OLTP, and OLAP are
combined on a single, in-memory platform. This means that there is no more moving data,
generating multiple copies, and causing delays in the viewing of business performance
information. We also have a much simpler IT landscape with only the SAP HANA platform
needed. A key enabler of this simplicity is that the SAP S/4HANA data model is simple. We do
not need to prepare and aggregate transactional data into separate analysis tables. All
analysis is done directly on the core transactional tables. There is no more moving data, either
from one system to another, or even within one system, from detailed table to summary table.
There is no redundancy at all. Additionally, SAP S/4HANA includes built-in analysis tools that
are Fiori based and user-friendly and promote self-service operational BI. S/4HANA provides
a virtual data model (VDM) based on S/4HANA tables e.g. MATDOC, ACDOCA ready to
consume.
The concept of embedded analytics is to embed analytical functions (technically via ABAP
CDS views and SAP Fiori Apps) in a transactional system. The term embedded analytics
includes as well the VDM ABAP CDS views as the SAP Fiori apps which are able to provide
realtime reporting as part of the simplified core of S/4HANA.
The main properties of ABAP CDS views are listed in the figure, Main Properties of ABAP CDS
Views

Figure 31: Properties of ABAP CDS views

© Copyright. All rights reserved. 36

 Lesson: Describing the Advantages of SAP S/4HANA and Embedded Analytics

LESSON SUMMARY
You should now be able to:
● Explain SAP S/4HANA and Embedded Analytics

© Copyright. All rights reserved. 37

 Unit 3
Lesson 2
Consuming an ABAP CDS View in SAP Fiori

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Consume an ABAP CDS View in SAP Fiori

LESSON SUMMARY
You should now be able to:
● Consume an ABAP CDS View in SAP Fiori

© Copyright. All rights reserved. 38

 Unit 3
Lesson 3
Consuming an ABAP CDS view with SAP
Analytics Cloud

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Consume an ABAP CDS view with SAP Analytics Cloud

LESSON SUMMARY
You should now be able to:
● Consume an ABAP CDS view with SAP Analytics Cloud

© Copyright. All rights reserved. 39

 Unit 3
Lesson 4
Describing Customer-Defined ABAP CDS
Views

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explain ABAP CDS Views

Examples of ABAP CDS Views

Figure 32: Example of CDS Views

As the figure, Examples of CDS Views, illustrates, the virtual model is designed in a modular
way, and distinguishes between several view types.
Consumption views are designed for consumption by client applications. These views define
how they can be accessed (via Analytic Manager or oData service). Consumption views often
contain input parameters and define a default layout.
Interface views are all views that are not consumption views, and include the following view
types:
Basic views are interface views with direct access to physical tables. Basic views can
implement joins or foreign key relationships to other ABAP CDS views, usually from the same
business segment.

© Copyright. All rights reserved. 40

 Lesson: Describing Customer-Defined ABAP CDS Views

Composite views are interface views without direct access to physical tables. Composite
views usually contain calculations that combine values from different business areas.
In the exercise in this lesson, you will create an ABAP CDS view and review a virtual data
model (VDM) that combines ABAP CDS views of different types.

Figure 33: The DDL Source and the Graphical Editor

CDS views are saved in an ABAP object called a DDL source. The view definition uses the CDS
Data Definition Language (DDL). As the figure, The DDL Source and the Graphical Editor,
shows, there is a graphical editor to display the relationship between different objects.
The foreign key relationship can be modeled as associations. Associations allow you to join
two ABAP CDS views. If required, fields from the associated view can be consumed in the
main view. You can restrict returned records to a subset by containing a filter or cardinality
information in square brackets [].

© Copyright. All rights reserved. 41

Unit 3: S/4HANA and Embedded Analytics

ABAP CDS Views: Associations

Figure 34: ABAP CDS Views: Associations

The figure, ABAP CDS Views: Associations, gives an example of an association.

The idea behind the associations in the ABAP Core Data Services (CDS) is to provide an
adequate representation of a relationship between two entities in the data model in the ABAP
Data Dictionary. If you think of the classical entity-relationship model as a directed attributed
graph, the associations are the edges of this graph.
The idea is to express these relationships as part of the data model - capture them in the
metadata stored behind the scenes and make them available for reuse. Reusing associations
includes an integration into the SQL-like query language as well as the availability of the
association metadata to frameworks built on top of the ABAP Data Dictionary.

ABAP CDS Views: Annotations

Figure 35: ABAP CDS Views: Annotations

© Copyright. All rights reserved. 42

 Lesson: Describing Customer-Defined ABAP CDS Views

As the figure, ABAP CDS Views: Annotations illustrates, the DDL language allows you to add
semantic information as annotations. These annotations are interpreted by the consuming
application. As the figure shows, annotations start with the @ symbol.

Figure 36: Types of Annotation

The figure, Types of Annotation, gives examples of the two kinds of annotation.
● Core annotations before the define statement refer to the entire view, such as a
descriptive text, or a data category (master data or facts), or an annotation if an
authorization check is required.
● Domain-specific annotations within the select statement refer to a single field. They
appear before the field. They can give hints for the interpretation of the content (is it an
URL, a currency, a unit), or for the reporting behavior, such as default aggregation.

LESSON SUMMARY
You should now be able to:
● Explain ABAP CDS Views

© Copyright. All rights reserved. 43

 Unit 3

Learning Assessment

1. Which of the following are advantages of the S/4HANA data model?

Choose the correct answers.

X A A reduced digital footprint

X B A reduced number of aggregation tables

X C A reduced number of index tables

X D A reduced number of views to combine data.

2. SAP Analytics Cloud allows live data connection to an ABAP CDS View.
Determine whether this statement is true or false.

X True

X False

3. Which of the following are key properties of ABAP CDS Views?

Choose the correct answers.

X A They are built in S/4HANA.

X B They are built in ABAP Eclipse only with scripts, without a graphical editor.

X C They can be built using transaction code SE80 in SAP GUI.

© Copyright. All rights reserved. 44

 Unit 3

Learning Assessment - Answers

1. Which of the following are advantages of the S/4HANA data model?

Choose the correct answers.

X A A reduced digital footprint

X B A reduced number of aggregation tables

X C A reduced number of index tables

X D A reduced number of views to combine data.

Correct! The S/4HANA data model provides a reduced data footprint, contains fewer
aggregation tables, and contains fewer index tables. For more information, see the lesson
Describing the Advantages of SAP S/4HANA and Embedded Analytics in the course
SAPANS.

2. SAP Analytics Cloud allows live data connection to an ABAP CDS View.
Determine whether this statement is true or false.

X True

X False

Correct! SAP Analytics Cloud allows live data connection to an ABAP CDS View. For more
information, see the lesson Consuming an ABAP CDS view with SAP Analytics Cloud in the
course SAPANS.

3. Which of the following are key properties of ABAP CDS Views?

Choose the correct answers.

X A They are built in S/4HANA.

X B They are built in ABAP Eclipse only with scripts, without a graphical editor.

X C They can be built using transaction code SE80 in SAP GUI.

Correct! ABAP CDS Views are built in S/4HANA, in the ABAP layer. They are built in ABAP
Eclipse only, without a graphical editor. You can review existing coding in SE80, but you
cannot build them there.

© Copyright. All rights reserved. 45

 UNIT 4 SAP BW powered by
SAP HANA and BW/
4HANA

Lesson 1
Describing SAP BW Powered by SAP HANA and BW/4HANA 47

Lesson 2
Defining Data Models in BW on HANA and BW/4HANA 51

Lesson 3
Loading Data into BW on HANA or BW/4HANA 72

Lesson 4
Describing the Evolution of SAP BW 81

UNIT OBJECTIVES

● Explain SAP BW on HANA and BW/4HANA

● Define data models in BW on HANA and BW/4HANA
● Load data into BW on HANA or BW/4HANA
● Describe the evolution of SAP BW

© Copyright. All rights reserved. 46

 Unit 4
Lesson 1
Describing SAP BW Powered by SAP HANA
and BW/4HANA

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Explain SAP BW on HANA and BW/4HANA

Advantages of a Separate Data Warehouse

Data evaluation is possible with HANA information views in an operative system environment
where business transactions are processed. However, there are use cases where defining
analytical processes in a separate, informative environment is more powerful and convenient.
Data storage, data management, authorization concepts, system configuration, and system
resources can be better tailored to the requirements of analytical processes in a separate
system.

Figure 37: Advantages of a Separate Data Warehouse

As the figure, Advantages of a Separate Data Warehouse, shows, a technical solution that
supports online analytical processes (OLAP) based on a consistent, stable set of data, is
called a data warehouse. The purpose of a data warehouse is to keep, structure, and visualize
all necessary company information. The increasing demand for high-quality business
information means that, in addition to an integrated data collection process, detailed data
analysis and multimedia presentation options are also required.

© Copyright. All rights reserved. 47

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

In heterogeneous system landscapes, a particular challenge lies in the extraction and

preparation of consolidated data from different source systems.

Figure 38: Data Processing in a Data Warehouse

As the figure, Data Processing in a Data Warehouse, illustrates, a data warehouse relies on the
data that comes from the sources. However, this information cannot easily be used for
targeted analysis. Therefore, the master data and transaction data from the source system
are cleansed, and technically and semantically prepared (or homogenized). This enterprise
data can then be combined with external data in the data warehouse.
A business intelligence (BI) application is a technical solution that helps to better understand
this information. The BI provides powerful and flexible tools for reporting and predictive
analysis. This knowledge can help the organization to optimize its business strategy and to
support the business processes derived from it. A clear, informative environment (including a
data warehouse and BI) is the key to a company’s strategic and operational advantage over
other companies.

© Copyright. All rights reserved. 48

 Lesson: Describing SAP BW Powered by SAP HANA and BW/4HANA

Figure 39: Features of SAP BW

SAP Business Information Warehouse (SAP BW) is the data warehouse solution of SAP. As
listed in the figure, Features of SAP BW, the main reasons for introducing a data warehouse
are data analysis, redundant data storage, preparation of data, and integrating data from
many sources in a periodically scheduled way with excellent monitoring possibilities.
SAP BW offers tools for different data analysis tasks
● Flexible self-service analysis tools with selection and drilldown properties, and features to
add local calculations
● Standardized Enterprise with a guaranteed quality of information, such as Crystal Reports,
with restricted self-service functionality
● Web-based self-service reporting tool for quick filters and graphical display of selected
values
● Analytical services, such as for data mining, planning, and more, which allow you to
execute predefined data-mining models such as ABC analysis

Storing data redundantly outside the source system in separate data storage offers a number
of advantages to your organization:
● Strain on the source systems is relieved, because data access for analytic purposes does
not consume their resources, and vice versa.
● A data history can be kept independent of, but reflecting changes in, the source system.
This is typically done by uploading changed values every night.
● The storage is optimized for read access.
Especially in SAP BW powered by SAP HANA, all tables relevant for reporting are stored in
column store format.

© Copyright. All rights reserved. 49

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

Preparing data in the data warehouse specifically for reporting improves data analysis in
several ways:
● If different source systems deliver values in different data types, currencies, or with
different texts or attributes, homogenization can take place during the staging process.
● Cleansing techniques avoid duplicates, keep only the latest status information, and
guarantee referential integrity.
● Definitions for hierarchies, and calculation of total values, guarantee correct mathematical
results.

Data provisioning across different source systems has the following advantages:
● Distributed scheduling allows you to extract data during windows of low activity in both the
source system and the reporting system.
Moreover, an even distribution of resources across the night becomes possible.
● SAP BW provides detailed monitoring and simulation functions that help to identify and
prevent errors, and it allows data requests to be reloaded with incorrect values without
getting incorrect total values.
● If different sources provide different key figures or attributes, integration of data from
different sources can be managed.

LESSON SUMMARY
You should now be able to:
● Explain SAP BW on HANA and BW/4HANA

© Copyright. All rights reserved. 50

 Unit 4
Lesson 2
Defining Data Models in BW on HANA and BW/
4HANA

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Define data models in BW on HANA and BW/4HANA

Modeling in SAP BW: An Example

Figure 40: How SAP BW Stores and Enhances Data

Different business users have different reporting requirements, based on the same data. As
the figure, How SAP BW Stores and Enhances Data, shows, the advantage of an SAP BW data
model is that data can be transformed in several steps, and intermediate results can be
saved. A central storage of homogenized data can be used for many different BW queries.
Each BW query aggregates and enhances this data in a specific way.

Homogenization of Data
To generate a usable permanent set of data for these queries, first you can extract raw data
selectively from a data source. As the figure shows, a persistent staging area (PSA) stores the
received records in the original format. Data from different source systems are stored in
different, data-source specific PSA tables.

© Copyright. All rights reserved. 51

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

The original values from different sources can be stored in an advanced data store object
(ADSO).
Homogenization can involve several of the following tasks:
● Changing the format from an internal to a BW format
● Mapping values from source-specific customer numbers to BW-wide valid, global
customer numbers
● Adding a currency or unit that was not available in the source system
● Adding the source system

Moreover, the data quality can be further improved during homogenization in the following
ways:
● Omitting further values that are out of scope
● Adding the current date
● Checking referential integrity (that is, rejecting values that are not listed in the
corresponding master data table)

Derive New Insight

In a further step, you can define a BW query to aggregate values on a specific group level, and
to define further filters and calculations.
For example: If the business’s users are interested in the average number of invoices sent to
the same customer during a specific month, a filter for this month can be applied, and values
can be aggregated from day to month. In a first step, the count of different invoices can be
calculated. In a second step, the system can determine the average of this value over all
customers. To derive a tax value, the revenue can be multiplied by a tax rate that depends on
the customer’s country.

Modeling Options
Especially with SAP HANA, a lean modeling approach that consumes less storage space is
desirable, but this must be balanced with the need for reusable, stable, and consistent data.
Therefore, SAP BW provides various object types for many different kinds of models, and
which option is better depends mainly on the reporting requirements. A key decision is how
the objects in the reports are defined.
Data is presented as a combination of different columns. For some columns, for example, for
a formula of a query, the data format shall be defined locally with the calculation. Any formula
that fits this format is then accepted. To achieve a higher rate of consistency, SAP BW
facilitiates the use of globally defined standard objects, such as sales revenue, currency,
product, country, and customer. These objects are called InfoObjects. The choice of an
InfoObject determines technical and semantic properties that are used in the same way in the
entire BW system, especially the data format, the language-specific description, and the list of
permitted values.

© Copyright. All rights reserved. 52

 Lesson: Defining Data Models in BW on HANA and BW/4HANA

Figure 41: Components of an InfoObject

InfoObjects are the smallest components of SAP BW, and can be used in different levels of a
data model, especially in BW queries. As the figure, Components of an InfoObject, shows,
InfoObjects are divided into characteristics, units, XXL attributes, and key figures.
Key figures store values that can be aggregated, as follows:
● Amounts with a reference to a currency
● Quantities with a reference to a unit of measure
● Pure mathematical numbers

Units are currencies and units of measure.

XXL attributes are files, such as images, Microsoft Excel, or text files.
Characteristics are used to distinguish between different records of a table or a result set.
Specific characteristics with reference to a calendar or fiscal calendar, such as calendar day,
month, year, and fiscal period are called time characteristics.
In a report, characteristics and units provide more information about their associated key
figures. For example, the sales revenue value can be determined by a combination of
currency, customer, sales day and product. Centrally stored master data of a characteristic
can be used to define higher levels of aggregation, such as the country or region of a
customer, or product hierarchies. Master data tables can contain XXL attributes, key figures
and units, such as the bar code, the net weight and the weight unit of a product.
Before master data tables of a basic characteristic can be filled, the corresponding
characteristics, key figures, or units must be assigned to the basic characteristic. The
assigned InfoObject is called an attribute of the basic characteristic. These master data
values are usually loaded from source systems. Besides master data for attributes, master
data for texts or for hierarchies, and even files, can be loaded.

© Copyright. All rights reserved. 53

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

Figure 42: Data for BW Queries

As the figure, Data for BW Queries, illustrates, a BW query is the BW object that contains
filter, calculations, and display properties for characteristics, and key figures for reports.
Besides queries that aggregate key figures, it is possible to define master data queries
without measures. These queries display a list of entities and their attributes. But where do
these values come from?
As the figure illustrates, an InfoProvider is an SAP BW object that is used to provide data for
the BW query. An InfoProvider can access data loaded to SAP BW, or views on remote data
such as native SAP HANA Views.
The figure shows the following different types of InfoProvider:
● Characteristic InfoObjects as InfoProviders are used for master data reports.
Example: A list of sales organizations with country and responsible employee.
● Advanced DataStore Objects (ADSO) are usually used to store transaction data.
Example: Sales revenue based on sales order data at the item level.
● Composite Providers provide a view of the data of one or more InfoProviders.
Different queries can be based on the same InfoProvider, but each BW query is based on a
single InfoProvider. If data from different ADSOs needs to be combined in a query, the
query can be defined on a Composite Provider that contains all the necessary ADSOs.

Technically, a query can be directly defined on an ADSO, but it is not recommended to access
an ADSO directly. To improve flexibility, it is recommended to install at least one Composite
Provider on top of each ADSO. This Composite Provider shall be used to assign characteristic
InfoObjects to the fields of the ADSO, and to define default properties for its queries.
It is easy to extend the scope of a Composite Provider by adding another part provider. For
example, you can combine sales amounts from China and India together with the assignment
of the responsible employee.

© Copyright. All rights reserved. 54

 Lesson: Defining Data Models in BW on HANA and BW/4HANA

Figure 43: SAP BW InfoProvider Use Cases

The figure, SAP BW InfoProvider Use Cases, shows the SAP BW powered by SAP HANA
InfoProviders and their intended use cases.
The data modeler needs to decide, for each set of data, which InfoProvider type is most
suitable.
The first question is whether data should be persisted. If yes, then use an InfoObject (type
characteristic) for master data, and an ADSO for transactional data. (Existing classic data
store objects and InfoCubes can still be used with SAP BW powered by SAP HANA.)
If no persistence is required, there are two options for master data: If you want to integrate
the characteristic into another InfoProvider or as an attribute of another InfoObject, choose
on InfoObject (characteristic) with virtual data.
If the master data should be combined with other open ODS views, choose an Open ODS view
of type texts or attributes.
For transactional data without data persistence, there are also several options. If existing BW
InfoProviders or HANA information views exist, and the requirement can be modeled as a
union or join over existing objects, choose a Composite Provider.
If direct access of one source table or view is required, possibly with associations to others,
choose the Open ODS view of type facts. (An association behaves like a join when the fields of
the associated views are needed.)
(Moreover, existing classic multiproviders and hybridproviders can still be used with SAP BW
powered by SAP HANA, but it is recommended to migrate them.)

InfoObject and Field-Based Modeling

There are two BW modeling approaches: the traditional one and a simplified one. The main
idea of the simplified approach to modeling is that you do not have to create BW objects for all
the fields of your data sources.

© Copyright. All rights reserved. 55

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

Figure 44: InfoObject and Field-Based Modeling

The left-hand side of the figure, InfoObject and Field-Based Modeling, shows the traditional
approach, which is integration before function (InfoObjects first).
The classical BW philosophy, which is InfoObject-based, requires integration before applying
business functions. It is a powerful tool to integrate data, and it guarantees a high data quality,
but this integration requires a lot of effort. You model the InfoObjects that are used to
harmonize and integrate data from different sources and to add meaning (semantics) to the
data. Semantic is defined by the InfoObject’s list of possible values, its attributes, or by
referenced units or currencies. If you have no InfoObjects, you cannot model data.
Then, after you have assigned InfoObjects, you model functions, such as looking up master
data, or calculating new values. This can be done in transformations, or in BW queries.
On the right-hand side of the figure, we see the new philosophy, which is function before
integration, or the field-level approach.
By using fields instead of InfoObjects, you define a minimal amount of meaning (semantics)
to the data. You execute a query on raw data. The data quality depends on your source, but
you get immediate answers to urgent questions.
The central object for field-based modeling is the Open Operational Data Store (ODS) view
and its persistent version, the advanced datastore object (ADSO). With all three HANA-
optimized types of BW InfoProviders, the composite provider, the ADSO, and the Open ODS
view, you have the option of choosing either field-based (function before integration), or
InfoObject-based (integration before function). Only the legacy InfoProviders, such as
InfoCubes, classic DSO, or InfoObjects as InfoProviders, need integration before function.
SQL views follow the function before integration approach.

Data Access Technologies: Data Flow, Virtual Access

The extraction, transformation and loading (ETL) process, sometimes called the data flow, is
a list of the steps that data must follow to be extracted, transformed, and loaded into SAP BW
target. There are different versions.

© Copyright. All rights reserved. 56

 Lesson: Defining Data Models in BW on HANA and BW/4HANA

Figure 45: Dataflow and Virtual Access

As the figure, Dataflow and Virtual Access, illustrates, in the full dataflow with PSA, an
infopackage loads data as unchanged raw data into a persistent storage area (PSA) within the
BW system. In further steps, data can be transformed. A process called data transfer process
(DTP) reads data from the PSA table, executes the transformation and stores the result into a
data target. In a version called ODP, the infopackage and PSA can be omitted. Virtual access
is another option, especially (but not only) with the SAP BW InfoProvider type Open ODS view.
The data modeler needs to decide the data flow method to be used for each loading
mechanism.
We recommend the following approach for choosing the best data access technique:
If the same values areneeded in several targets or if large amounts of data need to be
extracted, storing raw data in a PSA table is recommended. Then transformations and further
updates within BW do not block resources in the source system.
If the extraction isf ast enough, especially with SAP BW powered by SAP HANA, it is possible
to directly load values to ADSOs without using the PSA. This avoids redundant storage of
data.
If no history or snapshot is required, but realtime values are needed in a report exactly as they
look in the source system, define a virtual provider (for virtual access) in SAP BW. If the
source supports it, an open ODS view is sufficient. Otherwise, a virtual provider needs to be
defined. This scenario is not recommended for frequent unfiltered access to raw data
because of the impact on the source system. (Each query access needs a process in the
source system.)

Modeling Options in BW
SAP BW does not allow reporting based on stored values. Stored, harmonized data can be
combined with the latest original data from the sources for operational reporting in real time,
and for accessing and integrating different sources from different applications. You can
choose between executing this task in the source system, with SAP BW-based models, or with
SAP HANA-based models, as listed in the figure, Modeling Options: Focus.

© Copyright. All rights reserved. 57

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

Figure 46: Modeling Options: Focus

Let us focus on the integration from different sources. Usually, the following tasks need to be
performed:
● Harmonize the master data across source systems.
For example, the same product could have different IDs, which need to be mapped, or the
assignment of categories is different.
● Integrate master data and transactional data, such as adding category information to the
sales data.

In principle, integration of data from different tables or sources can be modeled in the
following ways:
If a source system already contains all the data that are required to generate the desired
result, it is possible to define database views or function modules in the source system, and
then you can define generic data sources for the extraction to SAP BW. To add missing values
from another table, you can use transaction SE11 to generate database views. For complex
transformations, use function modules instead of simple database views, and profit from the
full range of ABAP features. Then the original values are collected during extraction. If
executing a join or function module slows down the extraction process too much, execute a
program in the source system to fill a new table in the source system. Then only read from
this smaller set of values during extraction. If this is the main area of modeling, you use the
source system as your modeling focus.
The major advantage of this approach is that BW models can be kept simple, and the
necessary result can be checked in the source system. It is then the responsibility of the
source system to provide consistent data. The major disadvantage of this approach is that all
data must be available in the system, and that long-lasting harmonization processes slow
down the source-system performance.
However, if data needs to be harmonized across systems, it must be collected in one system.
If values from different sources can be assembled in the same SAP HANA platform on the
database level via SLT, or smart data access, models can be created in SAP HANA. Create
calculation views, or CDS views, to calculate the desired result on the fly whenever needed.
Values are immediately available. This view can be directly consumed in reports, or used as
the basis for extraction to SAP BW. In this case, HANA is used as a modeling focus.

© Copyright. All rights reserved. 58

 Lesson: Defining Data Models in BW on HANA and BW/4HANA

The major advantage of this approach is that real-time reporting is available, and data
integration is fast. No further results need be stored if calculation takes place on the fly. The
major disadvantage of this approach is that you need SQL for complex cases, and
harmonization with historical data has to be implemented manually, with much effort.
Another option is to use SAP BW as the modeling focus. You can take this approach in the
following circumstances:
● Not all values are loaded to SAP HANA.
● You want to use ABAP for integration.
● You want to take snapshots of the source data at exact points in time.
● You want to keep a history.

Use InfoObjects to store time-dependent master data. use ADSOs as persistent storage for
snapshots, and to generate delta data after changes. This is the focus of this course.
The major advantage of this approach is that as long as ABAP is not used, transforming
values can be processed within the SAP HANA database. ABAP can be used for special cases.
There are excellent monitoring and scheduling options. The major disadvantage of this
approach is that you need to wait for the loading mechanisms to take place before you can
evaluate new or changed values.

Note:
SAP BW provides excellent options for scheduling periodic data load. Some
loading mechanisms will be covered later in this course.

SAP BW Client Tools

Architecture of SAP BW Powered by SAP HANA and Business Intelligence
The figure, SAP BW Client Tools Overview, shows how the client tools fit into the SAP BW
landscape. You can combine these different approaches.

© Copyright. All rights reserved. 59

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

Figure 47: SAP BW Client Tools Overview

As the figure shows, SAP HANA views are modeled with the SAP HANA Modeler or SAP Web
IDE for SAP HANA. They can be made available to SAP BW by integrating them into a
Composite Provider. ADSO, Composite Provider, BW Query and Open ODS views are
modeled with the BW Modeling Tool. Depending on your release and on the type of BW object,
other objects are maintained within SAP HANA Studio or using the classical SAP GUI.
The SAP BusinessObjects Business Intelligence solution consists of different client tools for
specific use cases and the SAP BusinessObjects BI platform server that provides functionality
including a central repository, user management, security, and reports scheduling.
SAP BusinessObjects BI platform is a flexible, scalable, and reliable solution for delivering
powerful, interactive reports to users via any Web application: intranet, extranet, internet, or
corporate portal. Whether it is used for distributing weekly sales reports, providing customers
with personalized service offerings, or integrating critical information into corporate portals,
SAP BusinessObjects BI platform delivers tangible benefits that extend across and beyond
the organization. As an integrated suite for reporting, analysis, and information delivery, SAP
BusinessObjects BI platform provides a solution for increasing user productivity and reducing
administrative efforts.
Data can be accessed or loaded into the SAP Analytics Cloud. With a dynamic modern user
interface you can filter, combine, cluster and visualize the data.

The Data Warehousing Workbench

The main transaction code of SAP BW powered by SAP HANA is the Data Warehousing
Workbench.

© Copyright. All rights reserved. 60

 Lesson: Defining Data Models in BW on HANA and BW/4HANA

Figure 48: SAP BW Client Tools: Data Warehousing Workbench

A navigation pane appears on the left-hand side of the screen. There you find the following
individual function areas:
In the modeling function area, SAP BW objects and data flows are created. These objects are
displayed in a tree structure, where they are ordered according to hierarchical criteria. The
folders of this hierarchy are called InfoAreas. You use context menus to access the relevant
maintenance dialogs and functions of each of the objects in the object tree. You will access
this area while creating objects such as transformations and DTPs.

Note:
If you use BW/4HANA, all object types are modeled in the comfortable Eclipse-
based BW modeling tool. The modeling function area of the Data Warehousing
Workbench is discontinued. All other function areas are still available.

The administration function area collects a tool set for load scheduling, monitoring, and data
administration.
The transport connection function area provides a BW-specific transport tool set.
The document function area enables you to add documents to SAP BW objects. You can
search and create links between documents in various formats, versions, and languages.
The BI content function area provides preconfigured information models based on metadata.
You can use these objects in your system directly, or revise them. BI content enables
companies to build data models in SAP BW in a fast prototype way.
In the translation function area, the descriptions of SAP BW objects, such as queries and
InfoCubes, can be translated for support in multiple languages.
You use the Metadata Repository as a central point of access to information about the
metadata objects of SAP BW. This metadata includes important object properties and their
relationships with other objects.

The BW Modeling Tool

The BW Modeling Tool is an Eclipse-based GUI. Most of the modeling tasks must be
performed in this tool.

© Copyright. All rights reserved. 61

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

Figure 49: SAP BW Client Tools: BW Modeling Tool

As the figure, BW Modeling Tool, shows, the first step is connecting a BW system as a BW
project. A project is a stored connection with a specific user and logon language. After
opening the BW project, the InfoArea tree displays.
You use this environment to create new Composite Providers, ADSOs, Open ODS Views, and
BW Queries. You can define objects that you frequently access as favorites, which makes it
easier to find them.

BW Modeling Tool: Query Design

The BW Modeling Tool is used for query design. This includes the following tasks:
● Restricting characteristics
● Building the default layout

The figure, Query Designer, shows where you carry out these tasks in the tool.

© Copyright. All rights reserved. 62

 Lesson: Defining Data Models in BW on HANA and BW/4HANA

Figure 50: SAP BW Client Tools: Query Designer

On the Filter tab, you can restrict characteristics to characteristic values or to hierarchy
nodes, either as specific or as variable values.
When building the default layout, you use the following sections of the Sheet Definition tab:
● Columns
You place query objects such as key figures or characteristics in this section so that they
appear in report columns when you execute the query.
● Rows
You place query objects such as key figures or characteristics in this section so that they
appear in report rows when you execute the query.
● Free
You place characteristics here if you want them to be available for a user. Free
characteristics do not appear in the initial view or a query results set. The user navigates in
Analysis to make use of free characteristics.
● Properties
If you select an InfoObject, you can view and edits its properties on the right of the Sheet
Definition tab.

Rapid Prototyping
Business Scenario and Purpose of Open ODS Views
The figure, Purpose of Open ODS Views, explains a possible scenario for using Open ODS
Views as a starting point for development in the sense of rapid prototyping, and how a
dataflow can be developed.

© Copyright. All rights reserved. 63

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

Figure 51: Purpose of Open ODS Views

Imagine that you store orders and items in different tables of a SAP HANA database, and you
want to make them available for reporting in realtime without any delay. The requirement
analysis and an analysis of available sources reveals that the required information is already
available in the source system, and no harmonization needs to be done: There is no need to
check master data if you are only interested in seeing the sum of all orders of a specific day,
or to show all items of one order number. Then instead of loading all values to BW, you prefer
a direct access to the original database records in SAP HANA, and to select and aggregate the
required values within memory.
The first approach to realize this requirement might be a SAP HANA calculation view that is
directly accessed by BI Client tools. However, what if later the requirements change, and
products need to be made available with their category and text? What if these products need
to be checked against the list of existing products with their harmonized BW key? Then,
transforming and integrating these values according to well-established BW standards
becomes an issue. What if the values need to be stored in a permanent storage? Then, you
need a solution that allows immediate access without complicated modeling in the first place,
but is open for further enhancements within the same object. In order to allow the full range of
BW reporting, it should be an InfoProvider.
Indeed, there is one InfoProvider that makes source tables directly available in SAP BW : The
Open ODS View.
According to the field-based approach, an Open ODS View does not need InfoObject
definition, transformation, or data staging. Modeling with Open ODS Views is considerably
more flexible than modeling with InfoObjects. In particular, when defining the structure of the
Open ODS View, you can specify whether a specific field should be interpreted as a key figure
or a characteristic.
The left side of the figure shows the architecture of a simple Open ODS View. It keeps only
metadata; it does not have separate storage for transaction data or master data. However,
the data model can be enhanced for further integration into SAP BW. You can switch to a
version that uses a transformation during virtual access, or to a version with transformation

© Copyright. All rights reserved. 64

 Lesson: Defining Data Models in BW on HANA and BW/4HANA

and staging. The structure remains the same. This means persistency and analytic modeling
are decoupled for the Open ODS View.
The following restrictions apply to use of Open ODS Views:
● Open ODS Views are only available if the SAP BW system runs on the SAP HANA database.
● Open ODS Views cannot be defined for hierarchies yet.

Rapid Prototyping
Rapid Prototyping means starting with a simple field-based approach that is subsequently
enhanced with a dataflow and InfoObjects to generate more integrated solutions.

Figure 52: Rapid Prototyping: User Benefits

The figure, Rapid Prototyping: User Benefits, illustrates the steps in the process, as follows:

1. Create an Open ODS View.

2. Generate a data flow.

3. Assign InfoObjects.

To save time, create a virtual model with direct access to the original table fields. Use an Open
ODS View.
When creating an Open ODS View, the underlying object is tagged as facts, master data, or
text. The Open ODS View acts as the BW InfoProvider. It serves as a source for BW queries
and, as such, it can be directly consumed by reporting clients.
You can change the object descriptions and some default properties.
For flexibility, and to be compliant with the LSA++ architecture, we recommend that you
integrate each Open ODS View into Composite Providers.
If virtual access is too slow or puts too much stress onto the sources, generate a data flow. A
data flow generates an ADSO with the same structure, a default transformation, and a DTP,
You can change the transformation to improve the data quality. Still, the ADSO is field-based.
The open ODS View now only displays the loaded values; this is not a real-time scenario.
If you need master data or texts in your model, or if you want to check the referential integrity,
you create, load, and associate InfoObjects for some of the fields. If you want to save memory,
you can associate master data Open ODS Views instead of InfoObjects. It is technically

© Copyright. All rights reserved. 65

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

possible to define this association directly in an Open ODS View. However, you are more
flexible if you define the association in a Composite Provider that consumes the ADSO. The
Composite Provider can be used to add information from other models via union or join.
We recommend that you keep the number of InfoObjects low. Do not create InfoObjects for
fields such as invoice number, for which neither master data nor authorizations are needed.
Many more options exist to gradually enhance the integrity and consistency of your data:
● Start with data consumption of external data without staging: The Open ODS View allows
data sources to be virtually consumed without the need for a separate BW persistence for
the data. You can consume virtual data models located in a database schema (of the SAP
HANA database in BW), which is not managed by BW. Alternatively, the models can be
located in other databases, which can be connected to the SAP HANA database in SAP BW
using SAP HANA Smart Data Access.
● By generating a data flow, you switch from virtual to persistent structures. Load the data
physically into SAP BW. The degree of integration for data models can be iteratively
developed, without invalidating any modeling objects (for example, queries) that are based
on these modeling objects. For example, you can model a simple Open ODS View with
standard properties for the fields. You can then use this view as the base for queries. They
remain functional.
● Combine external data with SAP BW models very flexibly: By using links (“associations”) to
InfoObjects in an Open ODS Views, you can leverage an InfoObject´s attributes, texts, and
hierarchies, as well as analytic authorizations in SAP BW, for example.
● Modeling based on InfoObjects as well as fields can be combined now. In a Composite
Provider, you can associate some objects with Open ODS Views, others with InfoObjects.
● Combine the Open ODS View with SAP BW models using joins in a Composite Provider.
You can report on an InfoObject-based advanced DSO, an InfoObject, and a field-based
Open ODS View.
● Use the physical integrations options for external data (staging): For ETL purposes, you
can generate data sources and a data flow for Open ODS Views and and manually create
additional transformations and DTPs to different targets.
● You can keep your data model completely virtual, but add additional transformation logic
in a standard BW Transformation Rule. This means, for existing Open ODS Views you can
also automatically generate a data flow with a transformation. When the data flow is
created, the source of the Open ODS View is automatically replaced with the created
object, a so-called InfoSource(a structure as target of the Transformation).

Available Source Types for Open ODS Views

The key sources for Open ODS Views are as follows:
● SAP HANA database table (or database view). For each SAP HANA schema, there is a DB
connect source system.
● Virtual tables or views from external databases connected to SAP HANA via Smart Data
Access

The figure, Available Source Types, explains the difference between the database table or
view source type and the virtual table via SAP HANA Smart Data Access.

© Copyright. All rights reserved. 66

 Lesson: Defining Data Models in BW on HANA and BW/4HANA

Figure 53: Available Source Types

The SAP HANA database consists of different database schemas, each of which might
represent a different application. There is the schema that is managed by SAP BW, for
example, but additionally there might be external schemas containing objects of other
applications or of an ECC system. Data can be replicated to externally managed SAP HANA
schemas via SLT or Data Services. When you model an Open ODS View, you can consume
database tables or database views of all schemas that are available on the SAP HANA
database.
All these tables store their values within the SAP HANA database.
To integrate other database tables without duplicating data, tables can be connected via
Smart data access from external databases. They are available to Open ODS Views via the
“Virtual Table via SAP HANA Smart Data Access” option. Then, a virtual table is generated for
the remote table.
With SAP HANA SPS11, the following databases are supported for this feature:
● SAP HANA
● SAP IQ
● SAP Adaptive Service Enterprise
● Oracle Database 12C
● SAP Event Stream Processor
● SAP MaxDB*
● Hortonworks Distribution for Apache Hadoop version 2.3
● Teradata Database
● Microsoft SQL Server 2012
● IBM DB2

© Copyright. All rights reserved. 67

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

● IBM Netezza Appliance

● Apache Spark
● SAP MII (Manufacturing Integration and Intelligence, see also SAP Note 1984859)

Combining Open ODS Views as Unions

Data from different sources can be combined without data load processes using a BW
Composite Provider. Like in the Open ODS view, the aggregation behavior and other default
properties for reporting can be defined for fields. If you have associated an InfoObject, the
properties from the InfoObject are inherited.

Figure 54: Combining Open ODS Views in SAP BW

As the figure, Combining Open ODS Views in SAP BW, shows, if you use SAP BW powered by
SAP HANA, data can be read from the Composite Provider, then transformed and stored in an
Advanced DSO.

Business Intelligence Client Applications

For business users, the most visible advantage of SAP Business Intelligence (BI) is that it
provides intuitive front-end tools that enhance the self-service possibilities of business users,
and makes them independent of IT.
These tools are tightly integrated with SAP Business Warehouse (BW).

© Copyright. All rights reserved. 68

 Lesson: Defining Data Models in BW on HANA and BW/4HANA

Figure 55: Business Intelligence Client Applications

As the figure, Business Intelligence Client Applications, illustrates, SAP BI provides different
tools for different needs:
● Crystal Reports: Access and transform corporate data into highly formatted reports for
greater insight
● Lumira, Designer edition (and BO Dashboards): Visualize data for better decision making
● WebIntelligence: interactively answer ad hoc questions in a report
● Analysis, Edition for Microsoft Office and Analysis, Edition for OLAP: Perform
multidimensional analysis, determine trends from complex historical data and make better
forecasts
● Lumira, Discovery edition and SAP Analytics Cloud (and BO Explorer): Search and explore
data in a self-service manner, create and publish storyboards to answer specific questions
such as: Which was the top-selling product in region West in June? How many T-shirts did
we sell then?

© Copyright. All rights reserved. 69

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

Figure 56: SAP BusinessObjects Lumira Generic Analysis Application

The figure, SAP BusinessObjects Lumira Generic Analysis Application, introduces the
features of this application. With it, you can execute SAP BW queries, SAP BW InfoProviders,
and SAP HANA Views as data sources, as well as “slice and dice” them.
As the figure shows, the application is laid out as follows:
● It contains one crosstab and one chart by default.
● The drag-and-drop function can be used within the navigation panel, between the
navigation panel and the crosstab, and within the crosstab itself.
● A context menu is available on the crosstab, on the navigation panel, and on the chart,
which allow you to easily navigate and analyze your data.
● The SAP BusinessObjects Lumira Generic Analysis application does not need a data
source assigned. This means the application remains generic and independent of any data
sources. A data source can be chosen at run time via the Data Source Browser icon.

© Copyright. All rights reserved. 70

 Lesson: Defining Data Models in BW on HANA and BW/4HANA

Figure 57: SAP Analysis for Microsoft Office

The figure, SAP Analysis, Microsoft Office Edition, shows the features of this application. This
Excel-macro based tool allows you to perform the following tasks:
● Insert data from multiple sources and view the data from multiple perspectives.
● Use SAP BW queries, SAP BW InfoProviders, analysis views, and SAP HANA views as data
sources.
● Add multiple crosstabs to a workbook to insert and analyze data from different sources
and systems.
● Change the view of displayed data in the report.
● Refine your analysis of OLAP data with conditional formatting, filters, prompts,
calculations, and display hierarchies.
● Drag measures and characteristic objects into and out of the report to add and remove
them.
● Add charts for visual analysis of data.

The design panel is an element on the right side of the user interface that has four tabs,
Analysis, Information, Components, and Design Rules. You can use the design panel to create
new views of your data and to find information on the data sources currently being used in the
workbook.

LESSON SUMMARY
You should now be able to:
● Define data models in BW on HANA and BW/4HANA

© Copyright. All rights reserved. 71

 Unit 4
Lesson 3
Loading Data into BW on HANA or BW/4HANA

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Load data into BW on HANA or BW/4HANA

Data Extraction and Combination: An Example

Figure 58: Extracting and Combining Data: An Example

As the figure, Extracting and Combining Data: An Example, illustrates, data can be read from
many sources. These sources include tables, CDS Views, calculation views, R/3 function
modules, and more.
Data can be integrated using different methods, such as simple 1:1 field mapping, formulae,
procedures, time, currency, and unit of measure conversion.
Data from different sources can be combined during the data transfer process and stored in
the same data store object. Another option is to store data from different sources in separate
data store objects and combine them virtually.
Data is selected for reporting in a BW Query.

Operational Data Provisioning (ODP)

If changes must be monitored, or reporting on a history of changes is required, virtual access
is not informative. A specific technology to access data in the correct sequence is provided by
the Operational Data Provisioning (ODP) framework.

© Copyright. All rights reserved. 72

 Lesson: Loading Data into BW on HANA or BW/4HANA

Figure 59: Operational Data Provisioning Providers and Consumers

As the figure, Operational Data Provisioning Providers and Consumers, illustrates, there are a
number of possible ODP providers.
ODP-BW: SAP NetWeaver Business Warehouse exposes most of its data as ODPs for
replication purposes. Then, data from one BW system can be extracted to a subsequent BS
system, or to another application using DataServices, Embedded Analytics, or Odata.
ODP-SAP ERP Extractors: This context exposes BW DataSources in an ERP source system as
ODPs. A BW DataSource defines an extraction structure that is filled by an extractor
implementing the logic to retrieve the relevant data from the ABAP system. There are
application-specific extractors, each of which is hard-coded. In addition, there are generic
extractors for tables, views, and application areas such as LIS, CO-PA, FI-SL, and HR. Most
released DataSources are part of SAP Business Suite. Consumers access these ODPs using
the RFC implementation of the ODP consumer interface.
ODP - SLT Queue: Using the ODP infrastructure and the trigger-based replication of SAP
Landscape Transformation Replication Server (SAP LT Replication Server), data can be
transferred in real time from an ABAP system to one or more data warehouse systems.
ODP - SAP HANA Information Views: This context makes analytic views, calculation views and
associated attribute views defined in a HANA system release 1.0 SP4+ available as (transient)
ODPs in a connected NetWeaver 7.30 SP5+ system. It allows loading the view data into
another data warehouse system or to perform BW queries directly on HANA views. Such
queries can be defined on top of transient BW InfoProviders, which are provided for the
transient ODPs and can be identified by their name prefix "2H". This implementation opens up
the possibility to shift business logic from the ABAP-based BW warehousing and query layers
to the HANA database.
ODP - ABAP CDS Views: Core Data Services (CDS) enhance SQL to allow defining and
consuming semantically rich data models natively in HANA applications, thereby improving
productivity, consumability, performance and interoperability. This technology is core for S/
4HANA Analytics and has been added to the ODP framework with SAP BW 7.5.

© Copyright. All rights reserved. 73

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

ODP - SAP Business ByDesign: With the ODP context for SAP Business ByDesign, data
represented with ByDesign’s multi-dimensional analytical views (MDAVs) can be extracted
via ODP from the system.
ODP is a framework for extraction and replication scenarios. The data is stored in delta
queues and can be consumed by subscribers; that is, SAP applications that subscribe to this
delta queue can read the data out of this queue. The data is kept there until the last subscriber
has called the data or until a defined time has passed.

Figure 60: Operational Data Provisioning Benefits List

The figure, Operational Data Provisioning Benefits List, lists the benefits of ODP.
ODP offers a unified technology for data provisioning and consumption in BW. It
encompasses the Operational Delta Queue (ODQ). ODP is the technology that underpins the
key data provisioning techniques. ODP acts as the hub for all data flowing into BW from
external sources (see the figure Operational Data Provisioning Sources).
It supports an “extract once, deploy many” approach for sources and a unified configuration
and monitoring service for all source and target types. A time-stamp based recovery
mechanism and data retention periods which can be configured delivers greater and more
flexible data management. Parallel loading of data targets in high volume scenarios offers
reduced loading time. Use the ODP Framework to transfer data from various SAP repositories
to BW.

Figure 61: Operational Data Provisioning Sources

© Copyright. All rights reserved. 74

 Lesson: Loading Data into BW on HANA or BW/4HANA

As the figure, Operational Data Provisioning Sources, illustrates, the SAP BW system can
access data from any SAP system, an SAP S/4HANA system, an SLT source, and an SAP
HANA system.
When accessing data from an SAP HANA system, the data comes through the ODQ in the BW
system. The upper BW system can access data from another BW system via the ODP-BW
source system and data source, whereby the InfoProvider in the source BW system becomes
in ODP to the target BW system.
The ODQ is a data store in the source system. Data records are either written automatically to
the delta queue using an update process in the source system, such as 2LIS_11_VAITM, or
retrieved using the extractor interface, such as the generic data source
0COSTCENTER_ATTR.
The role of a provider is to provide one or more delta queues of a specific type.
The data is stored in a compressed state in the delta queue. A delta request then transfers
records from the queue to the subscriber. The data changes to a queue can also be requested
by more tan one subscriber. A subscriber can also request data for recovery purposes; in
other words, in case the subscriber needs to retrieve the data records again from a queue as a
once-off request (full). In this case, the request is not a subscription.

Figure 62: Monitoring the Operational Delta Queue

The data is retained in the delta queue for a specified time period for the Delta Queue Monitor,
as shown in the figure, Monitoring the Operational Delta Queue. The Delta Queue Monitor
(transaction ODQMON) allows you to monitor delta queues in various views, as detailed in the
figure.

Advanced DSO with Delta Generation

Figure 63: Advanced DSO with Delta Generation

© Copyright. All rights reserved. 75

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

The figure, Advanced DSO with Delta Generation, illustrates a typical BW data flow. In the data
flow, transaction data is extracted and transformed, and the result is stored in an advanced
DSO (ADSO). The records are initially stored in a database table called an inbound table. If
new values for the same key are loaded, only the final version is needed for reporting.
Therefore, with a special ADSO property, data is condensed in a second database table called
active data.
In many scenarios, data needs to be extracted to further targets that can only add new data.
In this case, knowledge of the difference between the two versions is required. If the source
does not provide such additional delta records, a special setting of the ADSO allows the
system to store the changes in a specific database table, the change log. From the change-log
data, the difference can be derived.

Figure 64: Delta Generation

The figure, Delta Generation, displays how data is stored in the three tables of an ADSO. For
each change, first a record with a before-image (a storno image of the former value) is stored
in the change log. Then, a second record with an afterimage is inserted in the change log.
The advantage of this mechanism is that the records from the change log can be added to
retrieve the current value. Another advantage is that no information is lost. The activation
mechanism can be undone, or rolled back, by reading the previous value from the change log.

© Copyright. All rights reserved. 76

 Lesson: Loading Data into BW on HANA or BW/4HANA

Process Chains

Figure 65: Process Chains

A process chain is a defined sequence of steps in BW. In a Planning View, the process chain
can be created and scheduled, as shown in the figure, Process Chains. New processes can be
integrated from a navigation area by dragging and dropping them.
After executing a process chain, a log view displays the process chain’s execution status.

© Copyright. All rights reserved. 77

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

Figure 66: Process Chains: Status-Dependent Process Sequence

Each process chain begins with a start process, as shown in the figure, Process Chains:
Status-Dependent Process Sequence. The start process defines when the process chain is
executed.
The following options for starting a process chain are possible:
● Immediately
● At a predefined point in time, either once or periodically
● After an event is executed

Some processes can be finished with status success or failure. In most cases, the subsequent
process should only be executed after the previous process has successfully executed.
However, in some cases, the subsequent process should be started anyway. The third option
is executing the subsequent process only in case of an error.
With this framework, the main advantage of BW can be leveraged: automation of complex
data loading mechanisms.

© Copyright. All rights reserved. 78

 Lesson: Loading Data into BW on HANA or BW/4HANA

Data Transformation

Figure 67: SAP BW Data Transformation: ABAP and HANA

As the figure, SAP BW Data Transformations: ABAP and HANA, suggests, there are two
different methods for defining and handling transformations.
ABAP-based SAP BW transformations load the data package by package from the source
database objects into the memory of the SAP BW application server (ABAP) for further
processing. The SAP BW transformation logic is executed inside the application server
(ABAP) and the transformed data packages are shipped back to the database server. The
database server writes the resulting data packages into the target database object.
During processing of an ABAP-based SAP BW transformation, the source data package is
processed row by row (or row-based). The ABAP-based processing allows you to define field-
based rules, which are processed as sequential processing steps. Therefore, the data is
transmitted twice between the database and the application server.
The distinction between application logic and data management gets more fuzzy if you are
using a SAP HANA database. All transformations can be processed in the SAP HANA
database as far as possible; that is, the data transformation logic is executed inside the SAP
HANA database only. Instead of reading the data from the database, processing the
transformation logic in the application server, and writing the transformed data back to the
database, the logic of the transformation is reflected in a so-called SAP HANA CalcScenario,
which is generated at activation time of the transformation on top of the source InfoProvider
in the SAP BW ABAP layer (see transaction RSDHATR). The CalcScenario is embedded into a
SAP HANA ColumnView.
To select data from the source object, the DTP creates a SQL SELECT statement based on
this Column View, and the processing logic of the CalcScenario applies all transformation
rules (defined in the SAP BW transformation) to the selected source data. By shifting the
transformation logic into the CalcScenario, the data can be transferred directly from the
source object to the target object within a single processing step.
The benefit of this approach is twofold — the data does not have to be transferred back and
forth between application server and database server, and secondly the transformation logic
can (potentially) leverage the full CPU power and parallelism of the SAP HANA database. The

© Copyright. All rights reserved. 79

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

degree of the performance improvement depends on several factors, such as the amount of
data read and written, the transformation logic, and the possible parallelism in there. Results
confirm great performance improvements - but in some cases (that is, at very low data
volumes) the performance improvement may also be negligible.

LESSON SUMMARY
You should now be able to:
● Load data into BW on HANA or BW/4HANA

© Copyright. All rights reserved. 80

 Unit 4
Lesson 4
Describing the Evolution of SAP BW

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Describe the evolution of SAP BW

The Evolution of SAP BW

Figure 68: The Evolution of SAP BW

As the figure, the Evolution of SAP BW, illustrates, if you need to leverage BW with SAP HANA
as the database, you upgrade from SAP BW on any database to SAP BW7.5, and migrate the
database to HANA 1.x.
With BW7.5, you can still use legacy objects, but if you want to take full advantage of all new
BW developments, you need to upgrade to BW/4HANA. As a first step, install BW/4HANA.
During this phase, delete or convert all existing objects. If a check is successful, you can
upgrade to BW/4HANA.
All future BW development will require BW/4HANA.

© Copyright. All rights reserved. 81

Unit 4: SAP BW powered by SAP HANA and BW/4HANA

SAP Business Content

Figure 69: SAP Business Content

As listed in the figure, SAP Business Content, SAP Business Content provides many BW
objects and complete data flows for standard extractors from SAP ERP. With SAP Business
Content, you can save a great deal of time. The objects have to be activated first. If you
activate a BW object, the system searches for other required BW objects, and activates all
required objects, too. With corresponding settings, a complete data flow can be activated for
a selected InfoProvider.
After introducing BW powered by SAP HANA and even more after introducing BW/4HANA,
many new Business Content objects have been generated. They follow a SAP HANA
optimized philosophy with fewer physical and more virtual data flows.

LESSON SUMMARY
You should now be able to:
● Describe the evolution of SAP BW

© Copyright. All rights reserved. 82

 Unit 4

Learning Assessment

1. Which of the following are advantages of SAP BW?

Choose the correct answers.

X A Online transactional processing

X B Fuzzy search models

X C Historization of changing master data

X D Combination and homogenization of data from different sources

X E Development of apps that use in-memory computation

2. Which of the following BW object types can you use to follow a field-based modeling
approach?
Choose the correct answers.

X A InfoCubes

X B Open ODS Views

X C aDSO

X D CompositeProvider

3. You want to persist central-fact data for reporting. Which of the following InfoProviders
can you use?
Choose the correct answers.

X A InfoCubes

X B Open ODS Views

X C aDSOs

X D CompositeProviders

© Copyright. All rights reserved. 83

Unit 4: Learning Assessment

4. In which of the following ODP use cases do you find the operational delta queue (ODQ) in
the SAP BW system?
Choose the correct answers.

X A SAP system

X B CDS view of an S/4HANA system

X C SAP HANA Calculation Views

X D SLT with dedicated replication server

5. What is the effect if BW transformations are executed using push-down code?

Choose the correct answers.

X A Data is transmitted twice between the database and application server.

X B Transformation logic must be written in ABAP.

X C Data does not have to be transferred back and forth.

X D The data transfer process cannot be scheduled.

X E Transformation logic leverages the full CPU power and parallelism of SAP HANA.

6. With BW/4HANA, you can combine legacy objects without SAP HANA optimization or
SAP HANA-optimized objects.
Determine whether this statement is true or false.

X True

X False

© Copyright. All rights reserved. 84

 Unit 4

Learning Assessment - Answers

1. Which of the following are advantages of SAP BW?

Choose the correct answers.

X A Online transactional processing

X B Fuzzy search models

X C Historization of changing master data

X D Combination and homogenization of data from different sources

X E Development of apps that use in-memory computation

Correct! SAP BW is optimized for analytical processing, not online transactional

processing. It has no data types for fuzzy search, although SAP HANA does. It also has no
data engine to pass app data to in-memory computation, although SAP HANA does.
However, SAP BW does provide features for the historization of changing master data,
and for transforming data from different sources. It also provides a stable, persistent,
consolidated data base for reporting. For more information, see the lesson Describing SAP
BW Powered by SAP HANA and BW/4HANA in the course SAPANS.

2. Which of the following BW object types can you use to follow a field-based modeling
approach?
Choose the correct answers.

X A InfoCubes

X B Open ODS Views

X C aDSO

X D CompositeProvider

Correct! Open ODS Views, aDSOs, and CompositeProviders all support field-based
modeling. InfoCubes do not; they can only contain InfoObjects. For more information, see
the lesson Defining Data Models in BW on HANA and BW/4HANA in the course SAPANS.

© Copyright. All rights reserved. 85

Unit 4: Learning Assessment - Answers

3. You want to persist central-fact data for reporting. Which of the following InfoProviders
can you use?
Choose the correct answers.

X A InfoCubes

X B Open ODS Views

X C aDSOs

X D CompositeProviders

Correct! InfoCubes and aDSOs both contain data. Open ODS Views are views without
persistent data, and CompositeProviders support joins and unions. For more information,
see the lesson Defining Data Models in BW on HANA and BW/4HANA in the course
SAPANS.

4. In which of the following ODP use cases do you find the operational delta queue (ODQ) in
the SAP BW system?
Choose the correct answers.

X A SAP system

X B CDS view of an S/4HANA system

X C SAP HANA Calculation Views

X D SLT with dedicated replication server

Correct! The ODQ of an SAP source system is stored in the SAP source system server, not
in the BW system. Similarly, the ODQ of a SLT replication server is stored in the replication
server, not in the BW system. The ODQ of a CDS view and of an SAP HANA Calculation
View is stored in the target, or BW, system. For more information, see the lesson Loading
Data into BW on HANA or BW/4HANA in the course SAPANS.

© Copyright. All rights reserved. 86

 Unit 4: Learning Assessment - Answers

5. What is the effect if BW transformations are executed using push-down code?

Choose the correct answers.

X A Data is transmitted twice between the database and application server.

X B Transformation logic must be written in ABAP.

X C Data does not have to be transferred back and forth.

X D The data transfer process cannot be scheduled.

X E Transformation logic leverages the full CPU power and parallelism of SAP HANA.

Correct! When push-down code is used, data transformation in SAP HANA is executed
with full CPU power and parallelism. The data transfer process can still be scheduled, and
you avoid the need to swap data back and forth. Data is directly processed on the
database without the need to move data to the application server. Transformation logic
must be written in SQL script. For more information, see the lesson Loading Data into BW
on HANA or BW/4HANA in the course SAPANS.

6. With BW/4HANA, you can combine legacy objects without SAP HANA optimization or
SAP HANA-optimized objects.
Determine whether this statement is true or false.

X True

X False

Correct! You can only use SAP HANA-optimized objects, not legacy objects. For more
information, see the lessson The Evolution of SAP HANA in the course SAPANS.

© Copyright. All rights reserved. 87

 UNIT 5 Summary

Lesson 1
Comparing Different Options 89

UNIT OBJECTIVES

● Compare different modeling options

© Copyright. All rights reserved. 88

 Unit 5
Lesson 1
Comparing Different Options

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Compare different modeling options

Comparison of Different Concepts

Figure 70: Native SAP HANA Modeling

The general approach of modeling in SAP HANA is to create virtualized objects such as
calculation views (table functions, procedures, and so on) and provide real-time analytics, as
shown in the figure, Native SAP HANA Modeling.
Now, it is even possible to generate persistencies natively via the Data Warehouse Foundation
(DWF), which can be used to expand the SAP HANA platform as a data warehouse system.
However, this requires additional installations, configurations, and an overview of the whole
system.
Working with SAP HANA requires according authorizations and a well-developed security
concept on the database level. One of the main benefits of SAP HANA, besides the highly
developed graphics editor for the calculation view, is the push-down approach to modeling.
The modeler doesn’t need to pay attention to it, because all the modeling work takes place at
the database level. Originally, SAP modeling supported mainly operational reporting
scenarios.

© Copyright. All rights reserved. 89

Unit 5: Summary

Figure 71: ABAP CDS views Modeling

As the figure, ABAP CDS Views Modeling, illustrates, the modeling approach of S/4HANA is
comparable to the SAP HANA approach, which is to create virtualized objects. Here, they are
in the form of ABAP CDS views for Real-time Analytics. An additional authorization concept at
the database level is not required because the modeling work takes place at the ABAP layer.
The main benefits of the ABAP CDS views are the use of the push-down approach when
activating the ABAP CDS views, and the decoupling of the modeling objects from the
underlying database.
In contrast to the calculation views, the only prerequisite for ABAP CDS views is an ABAP
layer beginning with ABAP 7.4. The underlying database may be technically different.
A graphical editor is only available in read mode, so that the actual definition of an ABAP CDS
view is only feasible with script code.
Originally, S/4HANA modeling supported mainly operational reporting scenarios.

Figure 72: SAP BW Modeling

© Copyright. All rights reserved. 90

 Lesson: Comparing Different Options

As the figure, SAP BW Modeling, illustrates, the general approach of modeling in SAP BW is to
create persistencies such as ADSO (InfoCube, etc), but even a virtualization approach is
supported by objects such as an Open ODS View.
Additional authorizations at the database level are only necessary in a mixed modeling
scenario. Highly developed user interfaces are available through the BW Eclipse and the Data
Warehousing Workbench. A web-based user interface is being planned.
SAP BW modeling supports mainly strategic analytics scenarios that focus on historical data.
SAP BW is still the main modeling environment for strategic analytics scenarios that require
persistencies. This could replaced technically by the native DWF, but additional effort is
required to set up the data warehouse system. That is why the DWF might be more
interesting for customers in a greenfield scenario.

Figure 73: Comparison of Modeling Concepts

As the figure, Comparison of Modeling Concepts, illustrates, BW has many features that are
not found in core SAP HANA or SAP HANA Live. These features are as follows:
● Disciplined architecture model (LSA++) with data governance
● ABAP transformations (to develop complex business logic)
● Built-in planning applications
● Metadata management
● Data staging, in the form of ETL with full referential integrity and powerful delta
management
● Automated data loading controls (process chains) and error handling
● Historization of changing data
● Fully integrated lifecycle management (NLS)

© Copyright. All rights reserved. 91

Unit 5: Summary

● Authorizations: Sophisticated OLAP security modeling

However, embedded analytics in combination with SAP HANA Live is stronger, specifically in
the following areas:
● Analytics with realtime data availability: Make decisions based on up-to-date, trusted
information.
● Flexibility: Create new joins and combinations as soon as new connections come into
focus.
● Calculations with in-memory-optimized calculation engine.
● Open for Access with native apps, ABAP programs, and many front-end tools.

Combinations are possible: Data can be extracted from SAP HANA Live views or CDS views.

Figure 74: Comparison of Modeling Concepts Table

The figure, Comparison of Modeling Concepts Table, lists some of the areas to consider in
planning a modeling environment. Besides differences such as the according authorization
layer, the availability or non-availability of a graphical editor, and an existing or non-existent
database dependency, the existing IT know-how is one of the main reasons for a far-reaching
strategic decision for or against one of these modeling environments.

© Copyright. All rights reserved. 92

 Lesson: Comparing Different Options

Business Cases

Figure 75: Business Case (Example)

The figure, Business Case (Example) lists two scenarios that combine SAP BW with SAP
HANA, and SAP BW with S/4HANA. Further mixed scenarios for SAP BW + SAP HANA and
SAP BW + S/4HANA are explained in more detail in the documentation, which you can find
listed in the appendix.

LESSON SUMMARY
You should now be able to:
● Compare different modeling options

© Copyright. All rights reserved. 93

 Unit 5

Learning Assessment

1. Assign the following modeling concepts to their corresponding data transformation

possibilities.
Match the item in the first column to the corresponding item in the second column.

Native SAP HANA Calculation SQL-based data definition lan-

Views guage
ABAP CDS Arrange or hide dimensions
from a datasheet
SAP BW
Graphical data flow, graphical
SAP Analytics Cloud
transformation editor
Calculated columns, table
functions, and procedures

© Copyright. All rights reserved. 94

 Unit 5

Learning Assessment - Answers

1. Assign the following modeling concepts to their corresponding data transformation

possibilities.
Match the item in the first column to the corresponding item in the second column.

Native SAP HANA Calculation Calculated columns, table

Views functions, and procedures
ABAP CDS SQL-based data definition lan-
guage
SAP BW
Graphical data flow, graphical
SAP Analytics Cloud
transformation editor
Arrange or hide dimensions
from a datasheet

© Copyright. All rights reserved. 95

 UNIT 6 More Information
(Appendix)

Lesson 1
Finding More Information 97

UNIT OBJECTIVES

● Find more information

© Copyright. All rights reserved. 96

 Unit 6
Lesson 1
Finding More Information

LESSON OBJECTIVES
After completing this lesson, you will be able to:
● Find more information

Additional Training

Figure 76: Additional Training

The figure, Additional Training, lists courses available on Native HANA modeling, S/4
embedded analytics, and SAP BW.

Key Terms
The figure, Key Terms, lists some of the terminology you should be familiar with as a result of
this course.

© Copyright. All rights reserved. 97

Unit 6: More Information (Appendix)

Figure 77: Key Terms

Web-Based Sources
The figure, More Information about SAP HANA, lists sources of information about working
with SAP HANA.

Figure 78: More Information about SAP HANA

The figure, More Information about SAP BW, lists resources for finding out more about
working with SAP BW.

© Copyright. All rights reserved. 98

 Lesson: Finding More Information

Figure 79: More Information about SAP BW

LESSON SUMMARY
You should now be able to:
● Find more information

© Copyright. All rights reserved. 99