Librería ERP — Sample | libreriaerp.com/us | info@libreriaerp.

com

SAPANS
Analytics with SAP Solutions

.
.
PARTICIPANT HANDBOOK
INSTRUCTOR-LED TRAINING
.
Course Version: 12
Course Duration: 3 Day(s)
Material Number: 50159835

Librería ERP — Sample | libreriaerp.com/us | [email protected]

Librería ERP — Sample | libreriaerp.com/us | [email protected]

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

SAP Copyrights, Trademarks and

Disclaimers

© 2022 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 https://www.sap.com/corporate/en/legal/copyright.html 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 may have been machine translated and may contain grammatical errors or
inaccuracies.
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

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

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

iv © Copyright. All rights reserved.

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

Contents

vii Course Overview

1 Unit 1: Native SAP HANA Modeling

3 Lesson: Understanding Native SAP HANA Modeling

25 Lesson: Understanding SAP HANA Live
27 Lesson: Understanding SAP HANA for SQL data warehousing

33 Unit 2: SAP S/4HANA and Embedded Analytics

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

Embedded Analytics
41 Lesson: Exploring ABAP CDS Views
43 Lesson: Describing Customer-Defined ABAP CDS Views

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

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

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

89 Unit 4: SAP Data Warehouse Cloud

91 Lesson: SAP Data Warehouse Cloud Concept

95 Lesson: SAP Data Warehouse Cloud Integration
101 Lesson: SAP Data Warehouse Cloud Administration
107 Lesson: SAP Data Warehouse Cloud Modeling

119 Unit 5: Summary

121 Lesson: Comparing Different Options

131 Unit 6: More Information (Appendix)

133 Lesson: Appendix: BI Client Tools

137 Lesson: Finding More Information

© Copyright. All rights reserved. v

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

vi © Copyright. All rights reserved.

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

Course Overview

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

© Copyright. All rights reserved. vii

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

viii © Copyright. All rights reserved.

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

UNIT 1 Native SAP HANA Modeling

Lesson 1
Understanding Native SAP HANA Modeling 3

Lesson 2
Understanding SAP HANA Live 25

Lesson 3
Understanding SAP HANA for SQL data warehousing 27

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
● Explain SAP HANA for SQL data warehousing

© Copyright. All rights reserved. 1

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

Unit 1: Native SAP HANA Modeling

2 © Copyright. All rights reserved.

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

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 and multiple skills are 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 Advantages of SAP HANA figure 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. 3

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

Unit 1: Native SAP HANA Modeling

Figure 2: Onboard Cache Advances

As the Onboard Cache Advances figure 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.

4 © Copyright. All rights reserved.

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

Lesson: Understanding 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. 5

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

Unit 1: Native SAP HANA Modeling

Figure 4: Column Cores

As shown in the Column Cores figure, 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.

6 © Copyright. All rights reserved.

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

Lesson: Understanding Native SAP HANA Modeling

Figure 5: Push-Down

The Push-Down figure illustrates how the handling of data requests has changed in SAP
HANA. For example, if the application layer sends the instruction “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. 7

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

Unit 1: 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 Transactional and Analysis Combined figure 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

8 © Copyright. All rights reserved.

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

Lesson: Understanding Native SAP HANA Modeling

As theSAP HANA Modeling Principles figure 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 Measures and Attributes figure 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. 9

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

Unit 1: 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 Types of Calculation View figure lists the properties of the calculation views supported in
SAP HANA.
A graphical calculation view defined with the SQL ACCESS ONLY 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

10 © Copyright. All rights reserved.

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

Lesson: Understanding Native SAP HANA Modeling

and aggregation, as well as prompts (variables and input parameters) for efficient pre-filtering
of data.

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.

© Copyright. All rights reserved. 11

Librería ERP — Sample | libreriaerp.com/us | [email protected]

 Librería ERP — Sample | libreriaerp.com/us | [email protected]

Unit 1: Native SAP HANA Modeling

Figure 11: Semantic Nodes

The Semantic Nodes figure 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
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 Connecting Tables lesson. You can also specify the

12 © Copyright. All rights reserved.

Librería ERP — Sample | libreriaerp.com/us | [email protected]