BW410
Data Warehousing with SAP
BW/4HANA
.
.
PARTICIPANT HANDBOOK
INSTRUCTOR-LED TRAINING
.
Course Version: 17
Course Duration: 5 Day(s)
e-book Duration: 7 Hours 5 Minutes
Material Number: 50153609
SAP Copyrights, Trademarks and Disclaimers
© 2020 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.
This course 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.
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.
iii
© Copyright. All rights reserved.
iv
Contents
vii
Course Overview
1
Unit 1:
Understanding Key Concepts of SAP BW/4HANA
2
12
Lesson: Introducing SAP BW/4HANA
Lesson: Describing how SAP HANA Powers SAP BW/4HANA
19
Lesson: Working with SAP BW/4HANA Tools
30
Unit 2:
31
43
51
Lesson: Creating an InfoObject: Characteristic
Lesson: Creating a Generic DataSource
Lesson: Creating Transformation and Data Transfer Process (DTP)
for Attribute Master Data Loading
Lesson: Outlining the Graphical Data Flow Modeling
Lesson: Modeling and Administration of SAP BW/4HANA
Hierarchies
Lesson: Deleting and Activating Master Data
56
61
65
72
Unit 3:
73
78
81
87
94
Unit 4:
123
128
138
154
163
Integrating Native SAP HANA Models with SAP BW/4HANA
Lesson: Exploring the SAP HANA Modeler Perspective
Lesson: Outlining Data Provisioning in SAP HANA
Lesson: Introducing SAP HANA Native Modeling
Lesson: Combining SAP BW/4HANA InfoProviders with SAP HANA
Calculation Views
Unit 5:
164
176
187
Working with Transactional Data in SAP BW/4HANA
Lesson: Introducing InfoProviders
Lesson: Creating a Key Figure InfoObject
Lesson: Modeling Data Mart DataStore Objects (Advanced)
Lesson: Creating a Data Flow for Transaction Data
Lesson: Creating a Standard DataStore Object and Loading Data
from a Flatfile DataSource
Lesson: Modeling CompositeProviders
112
122
Working with Master Data in SAP BW/4HANA
Working with Open ODS Views
Lesson: Creating Open ODS Views
Lesson: Creating DataSources from Open ODS View
Unit 6:
188
210
© Copyright. All rights reserved.
Working with Transformations and Data Transfer Processes
(DTP)
Lesson: Implementing Transformations
Lesson: Creating Data Transfer Processes (DTP)
v
216
Unit 7:
Operating SAP BW/4HANA
217
Lesson: Managing DataStore Objects (Advanced)
226
Lesson: Creating Process Chains
240
Lesson: Managing SAP HANA Delta Merge in SAP BW/4HANA
247
Unit 8:
248
249
Glossary
Lesson: Glossary
Glossary
© Copyright. All rights reserved.
vi
Course Overview
TARGET AUDIENCE
This course is intended for the following audiences:
Business Analyst
Business Process Owner/Team Lead/Power User
User
© Copyright. All rights reserved.
vii
© Copyright. All rights reserved.
viii
UNIT 1
Understanding Key
Concepts of SAP BW/
4HANA
Lesson 1
Introducing SAP BW/4HANA
2
Lesson 2
Describing how SAP HANA Powers SAP BW/4HANA
12
Lesson 3
Working with SAP BW/4HANA Tools
19
UNIT OBJECTIVES
Describe data warehousing
Describe SAP BW/4HANA
Describe how SAP HANA powers SAP BW/4HANA
Work with SAP BW/4HANA tools
© Copyright. All rights reserved.
1
Unit 1
Lesson 1
Introducing SAP BW/4HANA
LESSON OVERVIEW
This lesson first introduces data warehousing concepts, and then introduces SAP's data
warehousing solution: SAP BW/4HANA.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Describe data warehousing
Describe SAP BW/4HANA
What is a Data Warehouse?
A data warehouse is a core part of a business intelligence (BI) solution and its three key roles
are as follows:
Acquire, integrate, and manage data from anywhere across an organization
Provide sophisticated data modeling capabilities on the acquired data
Present a single view of modelled data to all analytical applications and reporting solutions
Figure 1: The Data Generation and Collection Cycle
© Copyright. All rights reserved.
2
Lesson: Introducing SAP BW/4HANA
A data warehouse collects data from across the entire enterprise from all source systems and
either loads the data to the data warehouse periodically, or accesses data in real time. During
the data acquisition, data is cleaned up. This usually means data is thoroughly checked for
invalid or missing values. Correct values are generated, or data can even be rejected. Data is
usually integrated from multiple source systems across an enterprise, for example, inventory
and sales data managed in two separate systems can be integrated to build a complete
picture of sales demand and stocking levels.
When data warehouses first appeared in the early 1990s, their role was to relieve the source
systems (typically mission-critical systems that run the key business processes) of their
reporting duties. As the demands of the analytical users was increasing, the source systems
could not cope. The solution was to make a copy of the data in a separate dedicated analytical
system: the data warehouse, where reporting could be managed. Data was periodically
extracted and stored in the data warehouse; typically this was an overnight activity. But in
recent years, modern data warehouses provide not only those capabilities but also a
permanent, remote connection to live data sources, so that data loading and storage to the
data warehouse is not always necessary. Customers have to decide whether to extract and
load, or to implement a remote connection. The decision is usually based around
performance requirements. For example, reporting performance can be poor if large amounts
of live data need to be accessed in the remote sources and then complex processing is
needed in the data warehouse to clean up and harmonize the data sources before the data is
ready to be consumed by the reporting tool. In this case, it might be better to periodically
extract the data from the source systems and then process the data in the data warehouse
and store the results, so that the data is ready for immediate consumption by the reporting
tools. The downside to this is that you now have duplicated data (this is called data
redundancy). Also, this approach means that data is no longer live and is valid only at the time
of extraction. For some types of data, this is acceptable. But for data that must be up to date,
extraction and loading is less desirable and a live connection is usually implemented.
Modern data warehouses can connect to data that is located on-premise and also in the
cloud.
Once data is acquired and integrated, it is then usually transformed by adding additional
business information to add more value to the data. For example, aggregate measures,
calculate new values, convert currencies, apply hierarchies to the data. Finally, the
transformed data is then exposed to analysis tools that are operated by the business user.
© Copyright. All rights reserved.
3
Unit 1: Understanding Key Concepts of SAP BW/4HANA
Figure 2: Basic Architecture of a Data Warehouse
A key objective of a data warehouse is to provide the complete historyof the organization’s
entire data set that is accurate, and at all levels of granularityright down to the original
transaction (grain). It should be possible to ask any analytical question on the data and trust
the answers. Performance should be acceptable. A well-built data warehouse avoids data
redundancy by avoiding storing summarizations of data that is already stored in detail. As
data volumes have increased, the traditional role of the data warehouse as a mass storage
archive has changed in recent years, and now physical data storage is managed across the
data warehouse storage layer, but also in other cheaper storage solutions, such as data lakes.
But the key role of a data warehouse has not changed and still continues to be responsible for
the management of all data, regardless of location, and to provide a single source for all
reporting and analytical requirements.
A data warehouse is often referred to as a data mart. But a data mart is simply a data
warehouse used to manage only a limited part of an organization's data, such as sales or
procurement, and is usually managed locally, and the data is often used for a specific use
case and not shared. One of the risks of developing data marts is the creation of silos of data
that create redundancies and inconsistencies. When a data warehouse manages the entire
organization's data, it is referred to as an enterprise data warehouse (EDW).
Introducing SAP BW/4HANA
SAP provides the following three data warehousing solutions:
SAP BW/4HANA — A packaged solution that provides a complete tool setto rapidly
deploy an enterprise-wide on-premise data warehouse out of the box.
SAP Data Warehouse Cloud — A cloud solution that provides business userswith easy to
use self-servicetools to acquire, model, and analyze their own data.
© Copyright. All rights reserved.
4
Lesson: Introducing SAP BW/4HANA
SAP SQL Data Warehousing — A family of SAP tools used to develop a completely
customized data warehouse solution from scratch for on-premise deployment that relies
heavily on SQL development.
All three solutions run on the SAP HANA platform and can work together to provide the best
tools to rapidly implement an agile and flexible but well-governed enterprise data warehouse.
This course covers SAP BW/4HANA.
Figure 3: SAP Data Warehousing solutions
SAP BW/4HANA has its origins in its predecessor solution known as SAP Business
Warehouse (BW). SAP BW was introduced to the market in 1998 and received constant
investment from SAP to ensure it kept up with technology trends. SAP BW is a NetWeaver
application written in ABAP language, and requires a database on which to run. SAP allowed
customers to choose the database vendor for their SAP BW implementation. SAP BW can run
on the most popular enterprise databases. In 2012, SAP added SAP HANA as one of the
supported databases and introduced new types of powerful objects that were specifically
optimized for the SAP HANA database. This version is called SAP BW powered by SAP HANA.
In this version, legacy BW objects can still be maintained but are no longer recommended to
be created as they are not optimized for SAP HANA. In 2015, SAP provided a software
component that could be installed in SAP BW powered by SAP HANA. The software
component is called SAP BW/4HANA Starter Add-On. This component ensures that only the
new types of SAP HANA optimized objects can be created in the SAP BW powered by SAP
HANA system. Only maintenance is allowed on the legacy objects. By implementing the SAP
BW/4HANA Starter Add-On, a customer has time to prepare their SAP BW powered by SAP
HANA system for a migration to SAP BW/4HANA, where legacy objects are no longer
supported.
© Copyright. All rights reserved.
5
Unit 1: Understanding Key Concepts of SAP BW/4HANA
Figure 4: SAP BW Evolution
In 2016, SAP completely rewrote SAP BW to run exclusively on the SAP HANA database. The
rewrite was necessary in order to optimize the ABAP code which was originally written to
satisfy the technical requirements of multiple, non-SAP databases. The new SAP HANA
optimized ABAP code pushes a lot of the processing down to the database level, so that
processing occurs right where the data is physically stored. Incredible performance and a
dramatically simplified code line is the result. The rewritten version of SAP BW is called SAP
BW/4HANA and uses only modern SAP HANA optimized modeling objects.
Note:
This course covers SAP BW/4HANA and not SAP BW powered by SAP HANA. The
course codes for SAP BW powered by HANA are BW3xxH and not BW4xx.
SAP BW is still widely used but many customers are now busy migrating their SAP BW
landscapes to SAP BW/4HANA, to take advantages of the power of SAP HANA. SAP provides
tools to automate, simplify, and accelerate the migration to SAP BW/4HANA.
SAP BW/4HANA supports the following three key layers that make up a modern data
warehouse:
Analysis
Data Modeling
Data Acquisition
© Copyright. All rights reserved.
6
Lesson: Introducing SAP BW/4HANA
Figure 5: Three Layers of SAP BW/4HANA
SAP BW/4HANA provides tools that support the connectivity of any source system, SAP and
non-SAP. Data can be extracted, transformed, and loaded to SAP BW/4HANA either
periodically - for example during the night - or even in real-time. Many source systems
support the loading of only the data that has changed or is new since the last load. This is
known as a delta load. One of the most popular sources of data is from the SAP ERP suites
such as SAP Business Suite of SAP S/4HANA, where large numbers of ready-made
extractors are provided by SAP. This could be considered as ‘pre-wiring’ of the SAP sources
to SAP BW/4HANA, and that is one of the most appealing aspects of SAP BW/4HANA for
customers who already run SAP systems. For non-SAP sources, it is possible to develop
extractors using the provided SAP BW/4HANA tools. Many sources support a remote
connection to data, so that real-time views of operational data are possible and no loading and
storing of data is necessary in SAP BW/4HANA.
© Copyright. All rights reserved.
7
Unit 1: Understanding Key Concepts of SAP BW/4HANA
Figure 6: SAP BW/4HANA Three Layered Architecture
SAP BW/4HANA provides tools for the development of dedicated objects that support
advanced data modeling. A modeler creates a data flow that guides data all the way from the
source systems into special storage objects such as Advanced DataStore Objects. As data
travels through the flow, it is possible to define transformations to clean up data, and fill in
missing values using lookups and formulae. During the load, data can be checked for quality
and bad data can be flagged. Once data is loaded it can then be modeled using tools that add
additional business semantics, such as assigning currencies to measures, or defining
hierarchies. The modeling layer is comprised of physical objects that store the data and
logical objects that create ‘shapes’ of data ready to be consumed by the business user.
In order to consume the data model, a developer creates a BW Query on top of the logical
objects, to define the specific layout of the report and any special requirements such as subtotals, sorting order, extra calculations, and filters.
But a BW Query is not an end user reporting tool. A BW Query sits between the data model
and the end report. A reporting tool is not provided with SAP BW/4HANA. Customers usually
have their own preferences for which reporting tool they would like to deploy. SAP offers
cloud and on-premise reporting tools such as SAP Analytics Cloud, SAP Analysis for
Microsoft Office, SAP Crystal Reports, and many more. SAP BW/4HANA also supports nonSAP reporting tools using open standards.
SAP BW/4HANA Content Add-On
A significant asset that is delivered with SAP BW/4HANA is the SAP BW/4HANA Content
Add-On. This provides SAP built extractors, data models, and queries that support the rapid
implementation of SAP BW/4HANA. The SAP BW/4HANA Content Add-On is installed in the
SAP BW/4HANA system and is developed and supported by SAP. Regular updates are
shipped by SAP and the SAP BW/4HANA Content Add-On is fully documented, so customers
can explore before committing to the installation of the content.
© Copyright. All rights reserved.
8
Lesson: Introducing SAP BW/4HANA
The SAP BW/4HANA Content Add-On can be selectively installed so it is possible to
implement only the most useful objects and models. The SAP BW/4HANA Content Add-On
provides objects that many customers would use in order to save huge amount of
development effort, such as extractors for SAP S/4HANA and SAP Business Suite
applications. The SAP BW/4HANA Content Add-On also provides industry-specific models
that follow best practices.
Figure 7: SAP BW/4HANA Content Add-On
SAP BW/4HANA provides tools to browse and install the SAP BW/4HANA Content Add-On
objects and models. Customers can adjust the content but SAP recommend that you copy
the content and then adjust your own copy. This way, you will not have your adjustments
overwritten when SAP deliver updates to the content.
SAP BW/4HANA Content can be used at all phases of the implementation. It can be used to
do the following:
Provide a reference for implementing SAP BW/4HANA using SAP best practices
Accelerate the implementation using ready made models
Provide early reports to business users so they can provide feedback to support the
implementation
SAP BW/4HANA and SAP S/4HANA Embedded Analytics
It is important to have a clear understanding of how SAP BW/4HANA and SAP S/4HANA
Embedded Analytics compliment each other and do not compete.
© Copyright. All rights reserved.
9
Unit 1: Understanding Key Concepts of SAP BW/4HANA
Figure 8: Embedded Analytics and SAP BW/4HANA
Embedded Analytics is included with SAP S/4HANA and provides a comprehensive data
model in the form of ABAP CDS views. These views expose live, operational transaction and
master data tables. Embedded Analytics also provides many ready-to-go reports,
dashbaords, and KPIs that provide business users with a live view of the business
performance. Report building tools are provided so IT and business users can create even
more analytical applications and reports. Embedded Analytics focuses on operational
reporting.
SAP BW/4HANA is a central data warehouse that consolidates data from across the
enterprise from all systems. Although in theory it could be used to cover operational
reporting, its strength is on orchestrating data from multiple systems where data integration
and harmonization is required. SAP BW/4HANA includes advanced data management tools
to support the collection and storage of huge amounts of data across different data
temperatures. SAP BW/4HANA focuses on strategic reporting.
Organizations who implement SAP S/4HANA and SAP BW/4HANA have a complete solution
for operational and strategic analytics.
Note:
SAP Business Suite does not use Embedded Analytics and instead includes SAP
HANA Live for operational reporting. This is similar in concept to Embedded
Analytics but is based on calculation view models within the SAP HANA database.
The SAP BW/4HANA Learning Journey
There are many skills that needs to be developed to support the implementation of SAP BW/
4HANA. SAP provide a learning journey that includes a sequence of multi-day courses that
can be taken in the classroom and also remotely (SAP Live Class), or consumed self-paced
using an SAP Learning Hub subscription.
© Copyright. All rights reserved.
10
Lesson: Introducing SAP BW/4HANA
Figure 9: The SAP BW/4HANA Learning Journey
The courses are as follows:
BW410 — Develop foundation knowledge covering all key aspects of SAP BW/4HANA. The
emphasis is on building the big picture and understanding the key objects and concepts.
BW410 is essential preparation for the follow-on courses.
BW405 — Develop advanced skills in query design. Taking BW410 before BW405 is
recommended but not essential.
BW430 — Develop advanced skills in data modeling. BW410 is an important prerequisite to
this course.
BW450 — Develop advanced skills in data acquisition. BW410 is an important prerequisite
for this course. BW430 is helpful, but not essential.
BW465 — Develop advanced skills in security. BW410 and BW405 are important
prerequisites for this course. BW430 and BW450 are helpful, but not essential.
SAP BW/4HANA Certification exam C_BW4HANA_xx covers topics that are included in the
courses BW410, BW405, BW430, and BW450. It is highly recommended that you study these
courses as part of your certification preparation.
LESSON SUMMARY
You should now be able to:
Describe data warehousing
Describe SAP BW/4HANA
© Copyright. All rights reserved.
11
Unit 1
Lesson 2
Describing how SAP HANA Powers SAP BW/
4HANA
LESSON OVERVIEW
This lesson introduces SAP HANA and how it powers SAP BW/4HANA.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Describe how SAP HANA powers SAP BW/4HANA
What is SAP HANA?
Figure 10: Technology Trends
We have more computing power available than ever before. In recent years, we have seen
memory sizes dramatically increase. The price of memory is falling, so we can afford to buy
more of it. Also, CPUs are more powerful than ever with multiple cores on each CPU, which
means that we have massive parallel processing power. SAP HANA runs on the latest
hardware that uses multi-core processors and huge memory. This in turn means that SAP
BW/4HANA runs with the best performance.
© Copyright. All rights reserved.
12
Lesson: Describing how SAP HANA Powers SAP BW/4HANA
Figure 11: Entire Database in Memory
In the past, databases were stored completely on disk and only the data requested by the
applications would be moved to memory, where it then passed to the CPU for processing. Due
to its limited size, memory would soon become filled and so data in memory would need to be
unloaded back to disk to make way for new data requests. A lot of disk swapping was the
result and this was harmful to the performance of the applications. With the huge memory
sizes now available, we can now store the complete database in memory. This means that
loading from disk to memory is not needed and all data is available instantly at all times to all
applications. SAP HANA is an in-memory database, which means disk is not required.
However, SAP HANA also includes disk so that you can decide how much data you want to
store in memory and how much on disk. Memory produces very fast results, disk is slower.
But memory comes at a higher cost than disk. Not all data is needed to be stored in memory,
especially if the data is rarely used.
© Copyright. All rights reserved.
13
Unit 1: Understanding Key Concepts of SAP BW/4HANA
Figure 12: Processing Push-Down
SAP HANA is not just a database used to store data. It contains multiple, powerful data
processingengines. This means that SAP HANA is able to take on all data processing tasks
that would normally be handled by the application running on the database. When data is
processed in the database, it means that we do not need to move data from the database to
the application layer for processing, and we do not send back the results for storage. No data
movement is needed as all processing is done where the data lives.
So what does this mean for SAP BW/4HANA? It means that SAP HANA takes on the data
processing tasks related to data loading, activation of data, summarizing data, currency
conversion of data, planning function, query processing, and much more. And as SAP HANA
is an in-memory database, we can expect very high performance. So not only do we avoid
moving the data from the database, we also process data completely in memory.
Figure 13: Column and Row Tables
© Copyright. All rights reserved.
14
Lesson: Describing how SAP HANA Powers SAP BW/4HANA
SAP HANA supports the traditional row table architecture but also supports column store
tables. Column store tables are optimal for analytical use cases. Data warehousing, and in
particular querying, is the ideal use case for column tables and that is why almost all of the
tables in SAP BW/4HANA are column store. The key reason for this is that queries almost
never request all of the columns of a table. But when you read a row table, all columns are
included in the read, even those that you did not request. When you read column tables, only
the requested columns are read. This helps with performance and means that we do not fill
memory with data that we did not request.
Figure 14: Compression of Column-Store Tables
Another benefit of column tables is that the data in the tables is automatically compressed
when it is loaded. This massively reduces the footprint of the table, by as much as 90%.
Compression essentially strips out all repetition of column values and a separate store of
dictionary and index information is held in order to recode the original relationship between
values. The benefit of compression is that the stored values are held in a machine-readable
format and the CPU can process them much faster than with variable length alphanumeric
strings. Also, a smaller footprint means we can store more data in memory.
In order to combat poor querying performance, it was usual for databases to calculate and
store summarization of data. These are also known as aggregates. In order to keep the
aggregates in sync with the source tables, we would need to run aggregation roll-ups
whenever new data arrived in the source tables. This can be time consuming and leads to outof-sync source tables and aggregates until the roll-up has completed. As well the time and
resources needed to roll-up the data, we would also need to find additional storage for the
aggregates. Also, the code required to manage the aggregates (create aggregates, roll-up
aggregates, monitor aggregates, delete aggregates, and so on) added complexity. So,
although aggregates helped to improve performance of reporting, they came at a heavy price.
© Copyright. All rights reserved.
15
Unit 1: Understanding Key Concepts of SAP BW/4HANA
Figure 15: Aggregates and Indexes Needed to Improve Performance
SAP BW/4HANA does not need aggregates at all because all aggregations are calculated onthe-fly in SAP HANA memory. This saves on storage. Also, there is no need to roll-up the
newly added data from the source tables to the aggregates so this means we do not have to
wait for this task to run in order to release the newly added data to business users. All data
loaded is available immediately. And of course, the application code is significantly simplified
when we remove all processing of aggregates.
Figure 16: SAP BW/4HANA Does Not Need Aggregates or Indexes
Indexes were also an essential add-on to the tables to improve access performance. Indexes
need managing and code is needed to create, drop, and rebuild them. Also, space is needed to
store them. Plus, access to loaded data is held up while indexes are dropped and rebuilt. SAP
© Copyright. All rights reserved.
16
Lesson: Describing how SAP HANA Powers SAP BW/4HANA
HANA supports indexes but usually they are not required, as the performance of SAP HANA is
already extremely good without them.
Figure 17: SAP HANA is More than a Database
SAP HANA is often referred to as a platform. This is because SAP HANA provides more than a
database. It includes other components, such as the following:
Application Development: A built-in, advanced application server that provides all the
tooling needed to develop and run native SAP HANA applications using various languages.
Advanced Analytical Processing: Powerful data processing engines used to build advanced
data models.
Data Integration and Quality: A complete ETL toolkit to extract, transform, and load data
from anywhere in the organization in real time and batch.
Database Management: Advanced, in-memory database and data management tooling.
What this means to SAP BW/4HANA is that we can take advantage of these SAP HANA
platform components to develop a powerful data warehouse solution.
© Copyright. All rights reserved.
17
Unit 1: Understanding Key Concepts of SAP BW/4HANA
Figure 18: Mixed Modeling
In an SAP BW/4HANA landscape, SAP HANA’s main priority is to manage the database tables
that belong to SAP BW/4HANA. However, as well as the SAP BW/4HANA tables, SAP HANA
can also access non-SAP BW/4HANA tables that are part of a separate application.
Separation of tables in SAP HANA is managed using database schemas. SAP BW/4HANA has
its own schema but you can create additional schemas to manage tables that belong to other
applications.
SAP HANA includes powerful tools to create data models right in the database on any SAP
HANA table in any schema, and even across schemas. The data models in SAP HANA are
called calculation views. SAP BW/4HANA data models can be integrated with SAP HANA
calculation views to create hybrid models. This is known as mixed modeling. Mixed models
combine the best features of SAP HANA calculation views with SAP BW/4HANA modeling.
CompositeProviders are used to combine the models using unions and/or joins.
LESSON SUMMARY
You should now be able to:
Describe how SAP HANA powers SAP BW/4HANA
© Copyright. All rights reserved.
18
Unit 1
Lesson 3
Working with SAP BW/4HANA Tools
LESSON OVERVIEW
This lesson shows the development of SAP BW. This lesson also introduces the Data
Warehousing Workbench and outlines its key functions.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Work with SAP BW/4HANA tools
SAP BW/4HANA Tools
The following three main tools are used to work with SAP BW/4HANA:
Eclipse BW Modeling Tools (BWMT)
BW/4HANA Cockpit
Data Warehousing Workbench
Figure 19: SAP BW/4HANA tools
Modeling and data acquisition design is performed in Eclipse BW Modeling Tools (BWMT).
Eclipse is a very well known, open-source, integrated development environment (IDE). SAP
developed the special SAP BW/4HANA plug-ins so that the tool includes a perspective,
multiple views, menus and icons that support the SAP BW/4HANA developer. Although the
tool is called Eclipse, you may find it being referred to as SAP HANA Studio. This is because
the same tool is used to work with the SAP HANA database. This is very helpful because it
© Copyright. All rights reserved.
19
Unit 1: Understanding Key Concepts of SAP BW/4HANA
means that the developer can easily switch between the SAP BW/4HANA interface and SAP
HANA database interface inside the same tool, using the same look and feel.
Note:
In this course we will often refer to Eclipse BW Modeling Tools (BWMT) as SAP
HANA Studio.
When you open the SAP HANA Studio, you must select a perspective. For SAP BW/4HANA
modeling, choose the BW Modeling perspective.
Figure 20: SAP HANA Studio — A Single Tool for SAP BW/4HANA and SAP HANA
The BW Modeling perspective is used to create and maintain objects that are relevant to the
data staging process in SAP BW/4HANA. These objects are displayed in a tree structure,
where the objects are ordered according to hierarchical criteria. You use context menus to
access the relevant maintenance dialogs and functions of each of the objects in the object
tree. You access this area numerous times in the remainder of this course, while performing
tasks such as creating InfoObjects , DataStoreObjects and DataFlows.
© Copyright. All rights reserved.
20
Lesson: Working with SAP BW/4HANA Tools
Figure 21: SAP HANA Studio — Perspectives
Before you start working with BW modeling in the SAP HANA Studio, you first need to create a
BW project. The BW Project is used to manage the connection to the SAP BW/4HANA backend system you want to work with. The project acts as a container (on the front-end) for the
SAP BW/4HANA metadata objects located in the SAP BW/4HANA system.
You work with BW Projects in the Project Explorer view. Here, the projects display in
alphabetical order (ascending). To work in a BW Project and see the sub-trees of the BW
Project, you have to log on to the BW back-end system. There are several ways to open the
Logon screen. You can double-click the BW Project, or expand the first level of the BW Project.
When you double-click or expand a BW Project with SSO enabled for the connected BW
system, you will not need to enter a user and password as the connection is immediately
established. Once you are logged on to the BW system for a certain project, you remain
logged on for this project unless you exit the SAP HANA Studio.
© Copyright. All rights reserved.
21
Unit 1: Understanding Key Concepts of SAP BW/4HANA
Figure 22: How to create a BW Project
The BW Modeling Tools have powerful user interface (UI) capabilities. This documentation
provides information about how you can set up projects to perform BW modeling tasks. It also
describes how to work with BW metadata objects in the SAP HANA Studio-based integrated
development environment (IDE). In particular, it describes how to define BW metadata
objects like CompositeProviders and Open ODS Views that provide native SAP HANAStudiobased editors. You can also assign the underlying SAP HANA database of the BW system,
thus enabling consumption of SAP HANA views (information models) in BW metadata
objects. The BW project structure then contains a further node, SAP HANA System Library,
which lists the SAP HANA views.
The BW Modeling Tools (BWMT) are a separate perspective in SAP HANA Studio and they
provide an integrated modeling environment for the management and maintenance of BW
metadata objects. The main objective of these tools is to support BW metadata modelers in
today’s increasingly complex BI environments by offering flexible, efficient, and state-of-theart modeling tools. These tools integrate with ABAP development tools as well as with SAP
HANA modeling and the consumption of SAP HANA elements in BW metadata objects, like
Open ODS Views or CompositeProviders .
Like all SAP HANA Studio perspectives, the BW modeling perspective defines the initial set
and layout of tools (views and editors) in the SAP HANA Studio window. In this way, it provides
a set of functions aimed at accomplishing BW modeling tasks.
In particular, it enables working with BW metadata objects that are managed by a BW backend system. When using the BW modeling perspective, you always have to establish a system
connection to the BW-system (technically managed by a corresponding BW project). The BW
perspective enables access to both SAP HANA Studio-based and GUI-based BW Modeling
editors.
The BW modeling perspective is designed for working with BW metadata objects that the user
can access using BW projects. It consists of an editor area, for BW metadata object editors,
and the following views:
Project Explorer
© Copyright. All rights reserved.
22
Lesson: Working with SAP BW/4HANA Tools
Properties
Problems
History
BW Reporting Preview
InfoProvider
You can also open the SAP GUI directly from within SAP HANA Studio.
Figure 23: Launch SAP GUI from SAP HANA Studio
You can search objects in SAP HANA Studio.
© Copyright. All rights reserved.
23
Unit 1: Understanding Key Concepts of SAP BW/4HANA
Figure 24: SAP BW/4HANA Metadata Search
In the BW modeling perspective, you can open and edit all BW metadata objects that are
displayed in the BW projects.
The following list shows you how to search for and open objects with the
dialog box:
Open BW Object
1. With the open BW object dialog box, search for a BW metadata object by name and by
description.
2. Open the editor SAP HANA Studio for the selected object.
3. Enter a search string. The system searches for BW metadata objects in the selected BW
project.
It searches for objects that contain the search string in the prefix of their technical name
or description. The search is not case-sensitive and supports the following wildcards:
*any character * - any string
(including the string length 0). If you do not enter
any wildcards, it ( * ) is used implicitly for the search.
The search results are listed in the Matching Items area of the dialog box.
If you know the object type you are looking for you can also specify this, such as
CompositeProvider. In the results list, you will find all objects that also have a dependency
to the object you are searching for.
They are sorted according to object type and description in ascending order. Select any of
the found objects to open the editor for that object.
© Copyright. All rights reserved.
24
Lesson: Working with SAP BW/4HANA Tools
Figure 25: SAP BW/4HANA Cockpit
The SAP BW/4HANA cockpit is an intuitive, web-based SAP Fiori user interface. It contains
various SAP Fiori apps, organized in groups, for process chain modeling and monitoring, and
for the administration of InfoProviders. Many of the provided tiles display useful information
on their surface, such as number of data loads. Choose a tile to drill into the details.
LESSON SUMMARY
You should now be able to:
Work with SAP BW/4HANA tools
© Copyright. All rights reserved.
25
Unit 1
Learning Assessment
1. What is SAP BW/4HANA?
Choose the correct answer.
X
A A packaged solution that provides a complete tool set to rapidly deploy an
enterprise-wide, on-premise data warehouse out of the box
X
B A family of SAP tools used to develop a completely customized data warehouse
solution from scratch for on-premise deployment that relies heavily on SQL
development
X
C A cloud solution that provides business users with easy to use self-service tools to
acquire and model and analyze their own data
2. What are features of SAP HANA?
Choose the correct answers.
X
A Column store tables
X
B Data is stored in memory
X
C Push processing to the application layer
X
D Data compression
X
E Aggregates and indexes
3. What are tools of SAP BW/4HANA?
Choose the correct answers.
X
A Data Warehousing Workbench
X
B BW Modeling Tool in Eclipse
X
C Bex Analyzer
X
D BW/4HANA Cockpit
© Copyright. All rights reserved.
26
Unit 1: Learning Assessment
4. The CompositeProvider stores no data.
Determine whether this statement is true or false.
X
True
X
False
© Copyright. All rights reserved.
27
Unit 1
Learning Assessment - Answers
1. What is SAP BW/4HANA?
Choose the correct answer.
X
A A packaged solution that provides a complete tool set to rapidly deploy an
enterprise-wide, on-premise data warehouse out of the box
X
B A family of SAP tools used to develop a completely customized data warehouse
solution from scratch for on-premise deployment that relies heavily on SQL
development
X
C A cloud solution that provides business users with easy to use self-service tools to
acquire and model and analyze their own data
Correct — SAP BW/4HANA is a packaged solution that provides a complete tool set to
rapidly deploy an enterprise-wide on-premise data warehouse out of the box
2. What are features of SAP HANA?
Choose the correct answers.
X
A Column store tables
X
B Data is stored in memory
X
C Push processing to the application layer
X
D Data compression
X
E Aggregates and indexes
Correct — Features of SAP HANA include column store tables, data stored in memory,
and data compression
© Copyright. All rights reserved.
28
Unit 1: Learning Assessment - Answers
3. What are tools of SAP BW/4HANA?
Choose the correct answers.
X
A Data Warehousing Workbench
X
B BW Modeling Tool in Eclipse
X
C Bex Analyzer
X
D BW/4HANA Cockpit
Correct — tools of SAP BW/4HANA include Data Warehousing Workbench, BW Modeling
Tool in Eclipse, and BW/4HANA Cockpit
4. The CompositeProvider stores no data.
Determine whether this statement is true or false.
X
True
X
False
Correct: The CompositeProvider stores no data.
© Copyright. All rights reserved.
29
UNIT 2
Working with Master
Data in SAP BW/
4HANA
Lesson 1
Creating an InfoObject: Characteristic
31
Lesson 2
Creating a Generic DataSource
43
Lesson 3
Creating Transformation and Data Transfer Process (DTP) for Attribute Master Data Loading
51
Lesson 4
Outlining the Graphical Data Flow Modeling
56
Lesson 5
Modeling and Administration of SAP BW/4HANA Hierarchies
61
Lesson 6
Deleting and Activating Master Data
65
UNIT OBJECTIVES
Explain the InfoObject: Characteristic
Create a generic DataSource
Create transformation and data transfer process (DTP) for attribute master data loading
Understand the graphical data flow modeling
Model and load a simple SAP BW/4HANA hierarchy
Understand deletion and activation of master data
© Copyright. All rights reserved.
30
Unit 2
Lesson 1
Creating an InfoObject: Characteristic
LESSON OVERVIEW
This lesson introduces InfoObjects. This lesson explains how InfoObjects are used in SAP
BW/4HANA.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Explain the InfoObject: Characteristic
Introducing InfoObjects
The following are the key features of InfoObjects in SAP BW/4HANA:
They can be uniquely identified by their technical name.
They contain technical and business information.
They allow information modeling.
They are used to define reports and to evaluate master and transaction data.
As components of the Metadata Repository (the storage area for all SAP BW/4HANA
objects), InfoObjects contain technical and business analyst information for master and
transaction data in SAP BW/4HANA.
InfoObjects are used throughout the system to create structures and tables where data is
stored. They enable information to be modeled in a structured form. They are also used to
define reports and to evaluate master and transaction data.
SAP delivers InfoObjects within SAP BW/4HANA Content. Technical names of InfoObjects
delivered with BW Content begin with 0 (zero). You can also define your own InfoObjects .
Unlike SAP source systems, the only requirement is that the technical names do not begin
with a number or a special character, and that it is between three and nine characters in
length. There is no need for Z names, as is required for some SAP products.
Figure 26: InfoObjects: Types and Definitions
© Copyright. All rights reserved.
31
Unit 2: Working with Master Data in SAP BW/4HANA
InfoObjects are primarily divided into the major types of key figures or characteristics. The
characteristics type is further divided into time characteristics, technical characteristics, and
units.
Key Figure InfoObjects provide values to be calculated or evaluated. The following are
examples of this type of InfoObject :
Quantity ( 0QUANTITY)
Amount ( 0AMOUNT)
Characteristics InfoObjects are business reference objects that are used to analyze key
figures. The following are examples of these InfoObjects :
Cost center ( 0COSTCENTER)
Material ( 0MATERIAL)
Time Characteristics InfoObjects form the time reference frame for many data analyses and
evaluations. They are delivered with BW Content. The following are examples of these
InfoObjects :
Calendar day ( 0CALDAY ), time characteristic with the smallest granularity
Calendar year ( 0CALYEAR) or fiscal year ( 0FISCYEAR), time characteristic with the largest
granularity
Figure 27: InfoObjects in SAP BW
In classic BW modeling, there is an InfoObject for each field of the table. With the new
InfoProvider types in SAP BW/4HANA, you can also use a field-based approach.
If your enterprise wants to consolidate cost center data from an SAP system and an external
system using a file interface, proceed as described subsequently.
© Copyright. All rights reserved.
32
Lesson: Creating an InfoObject: Characteristic
In our training legacy system, the cost center number is 13 characters long, but the SAP
system only allows 10 characters. To accommodate this limitation, create a new
InfoObject to
represent the 13 character cost center number. Instead of leaving the three added characters
blank when the data is sourced from the SAP system, the three-character system ID will be
appended to all the cost centers from this source.
Figure 28: Our Scenario
Before we examine the maintenance tabs, we must describe the concept of master-databearing characteristics. Master-data-bearing characteristics specify tables of attributes,
texts, or hierarchies that are linked to them to provide additional information. It depends on
your business process and the characteristics involved to decide whether or not to enable
these master data tables. They provide a significant source of information for your reporting
needs in many situations.
You enable master data bearing characteristics by selecting the appropriate checkbox for
text, master data, or hierarchies in the tabs shown in the following figures. If any of these
options are checked, the characteristic is considered to be a master-data-bearing
characteristic.
© Copyright. All rights reserved.
33
Unit 2: Working with Master Data in SAP BW/4HANA
Figure 29: Master Data Bearing Characteristics: Examples
You can use the tabs in the Maintenance menu to define Characteristics InfoObjects and to
change settings. A precise knowledge of the business significance of these characteristics is
required before you can define them in a meaningful way.
The Maintenance screen contains the following tabs:
General
Master data/texts
Attributes
Hierarchy
BI clients
In the Compounding section, you determine whether or not the characteristic is to be
compounded to other InfoObjects . Compounding is the process of combining a
Characteristics InfoObject with another Characteristics InfoObject to ensure the ability to
uniquely define the values of the InfoObject . You must often compound characteristic values
to enable them to be uniquely assigned. While it is not needed in most cases, forgetting it
when it is required will result in meaningless data.
For example, cost center 100 stands for sales and distribution in controlling area 1000, and it
also stands for marketing in controlling area 2000. Define a cost center compounded to the
controlling area characteristic. Another example is Storage Location . In SAP MM, you cannot
find a material if the only information you have is its storage location; you also need to know
the plant. In addition, compounding can be used to define dependencies between objects.
This simplifies navigation in reporting.
© Copyright. All rights reserved.
34
Lesson: Creating an InfoObject: Characteristic
InfoObject: Characteristic - Settings and Tables
Figure 30: General Tab
The General tab is used to determine the basic properties of a characteristic, for example,
description, data type (CHAR, NUM), length (maximum 250 characters), and conversion
routine. You can use compounds to make your characteristic unique.
Figure 31: Master Data Text Tab
On the Master Data/Texts tab, you determine whether or not the characteristic can have
attributes or texts. If the characteristic is to have its own texts, make at least one text
selection (short, medium length, long text, or long text is XL, that is 20, 40, 60 or 1,333
characters). The attributes are assigned to the characteristic on the
Attributes tab. By
selecting any of these checkboxes, the characteristic is designed to bear master data.
© Copyright. All rights reserved.
35
Unit 2: Working with Master Data in SAP BW/4HANA
Figure 32: Attributes Tab
Attributes are InfoObjects (characteristics or key figures) that are used to describe
characteristics in greater detail. For example, the characteristic cost center can be described
in more detail with the profit center and person responsible for maintaining information about
the cost center. In this context, these two InfoObjects are used as attributes. If the With
master data indicator is set on the Master Data/Texts tab shown in the previous figure, you
can specify attributes and properties for these attributes on the Attributes tab. The attributes
themselves are also InfoObjects , because we are using the field information on the InfoObject
to build a column on the primary characteristics master data table.
If you define attributes as Display Attributes , you can only use these attributes as additional
information in reporting when combined with the characteristic. In other words, in reporting,
you cannot navigate within the dataset of an InfoProvider using these attributes.
If you define attributes as Navigation Attributes , you can use them to navigate in reporting.
When a query is run, the system does not distinguish between navigation attributes and
characteristics for an InfoProvider . In other words, all navigation functions in the query are
also possible for navigation attributes. To make attributes available as navigation attributes in
reporting, enable them on the InfoProvider , otherwise, the attributes function as display
attributes.
You can make display and navigation attributes Time-dependent if a validity period is required
for each attribute value. This feature is powerful, allowing you to perform reports based on the
way master data existed at any point in time.
© Copyright. All rights reserved.
36
Lesson: Creating an InfoObject: Characteristic
Figure 33: Master-Data-Bearing Characteristics Table
The Business Explorer tab is used to set the display default values in the Business Explorer.
The settings on this tab determine whether or not the characteristic is displayed as a textual
description, or as a key in the Business Explorer.
When your InfoObject is activated, the system automatically builds the appropriate underlying
tables.
Figure 34: Characteristic InfoObjects: Transfer Routine
© Copyright. All rights reserved.
37
Unit 2: Working with Master Data in SAP BW/4HANA
Figure 35: High Cardinality
Characteristic with High Cardinality (More than 2 Billion Records)
Only use the High Cardinality option if you expect that the SID number range of 2 billion will be
insufficient. Otherwise, create the characteristic without the
High Cardinality property.
If the High Cardinality property is set, the characteristic does not have persistent SID values
or an SID table. This implies that it can only be used in InfoProviders that store the key value
and not the SID value of the contained characteristics.
Restrictions
High cardinality characteristics cannot be used in the following elements:
Compounding parent
Navigation attribute
Hierarchies
SAP HANA analysis processes
The High Cardinality property is only supported for data type CHAR and NUMC with length
less than or equal to 10.
Dependencies
During reporting, SID values must be created as local SIDs as required and the response
times of queries are impacted.
© Copyright. All rights reserved.
38
Lesson: Creating an InfoObject: Characteristic
Figure 36: Generation of SAP HANA Views
External SAP HANA View for SAP BW/4HANA Objects
You can use this flag to specify whether an external SAP HANA view is generated for the SAP
BW/4HANA object.
If this flag is set, an external SAP HANA view is generated. This external SAP HANA view is not
used by the SAP BW/4HANA run time, but can be used as an SAP HANA native access
interface to SAP BW/4HANA models and data. The SAP HANA package where the external
SAP HANA view is deployed can be set using the SPROtransaction. In addition to the SAP
HANA view, the corresponding SAP BW/4HANA authorizations are replicated to SAP HANA
privileges and automatically added (using roles) to the SAP HANA DB user, which
corresponds to the SAP BW/4HANA user.
Dependencies
An external SAP HANA view can be generated for the following object types:
CompositeProvider
BW/4HANA Query
Query as InfoProvider
DataStore Object (advanced)
InfoObject
Generate SAP HANA Calculation Views from SAP BW/4HANA
When you activate SAP BW/4HANA modeling objects, you can generate SAP
HANA calculation views with the same structures. This enables you to create scenarios where
data, which is modeled in SAP BW/4HANA, is merged with data modeled in SAP
HANA with native SAP HANA modeling tools.
The following objects are supported:
DataStore objects
InfoObjects
© Copyright. All rights reserved.
39
Unit 2: Working with Master Data in SAP BW/4HANA
Queries as InfoProviders
CompositeProviders
Local CompositeProviders in the BW/4HANA Workspace and queries
When SAP HANA views are generated, SAP BW/4HANA data is published to SAP HANA.
The SAP HANA views point directly to data and tables that are managed by SAP BW/4HANA.
SAP BW/4HANA data can therefore be consumed directly in SAP HANA. This also provides a
clear interface between the schema managed by the SAP BW/4HANA and an area outside the
SAP BW/4HANAs, that is managed by other tools or by another user group. This interface
makes clear where the services in the SAP BW/4HANA system end, and where the manual
enhancements or enhancements provided by third-party tools begin. It is not possible to
change generated SAP HANA views manually. The SAP HANA views generated by SAP BW/
4HANA can be overwritten at any time by the system and any manual changes would be lost.
You can create more SAP HANA calculation views on these generated calculation views.
These will then be stored in another content package.
Generating SAP HANA calculation views from SAP BW/4HANA enables you to generate SAP
HANA calculation views without using the SAP HANA Modeler. You can access SAP BW/
4HANA data via SQL front ends. All applications that can read SAP HANA calculation views
can process the data (for example, SAP BusinessObjects Analysis, edition for Microsoft
Office, SAP BusinessObjects Web Intelligence, SAP BusinessObjects Explorer, SAP Lumira,
and BI Clients from third-party providers).
When a query is run on the SAP HANA calculation view, the data is requested directly
from SAP HANA, without SAP BW/4HANA being addressed.
Generation of SAP HANA calculation views from SAP BW/4HANA has been implemented as
an interface for standalone data marts. The SAP HANA calculation views are only suitable for
special scenarios. These SAP HANA calculation views are part of the SAP BW/4HANA
InfoProvider lifecycle. They are transported with the corresponding SAP BW/4HANA objects.
The target system should have an SAP HANA database. If it does not, the property that has
the SAP HANA calculation view will be lost.
When an SAP BW/4HANA object is activated with the SAP HANA view, all the dependent SAP
HANA views are also activated. If an error occurs with an SAP HANA calculation view that you
created, this leads to a warning and the SAP BW/4HANA object is activated. The analysis
authorizations in SAP HANA are created during activation of the SAP BW/4HANA objects and
compared with the analysis authorizations in SAP BW/4HANA.
Transaction RS2HANA_ADMINenables you to manage SAP HANA calculation views from SAP
BW/4HANA objects. In this transaction, you see an overview of all SAP BW/4HANA objects
with an external SAP HANA calculation view and various administration and check functions.
© Copyright. All rights reserved.
40
Lesson: Creating an InfoObject: Characteristic
Figure 37: Virtual Master Data
If you want to use virtual navigation attributes and texts in a VirtualProvider based on an SAP
HANA model, you must create virtual master data. The steps are shown in the To Create a
Virtual Master Data procedure.
Figure 38: XXL Attributes (Non-SAP HANA Specific)
On the XXL Attributes tab, you can specify XXL attributes for the characteristic. This tab page
is only visible if you set the Supports XXL Attributes flag on the Master Data/Texts tab page.
© Copyright. All rights reserved.
41
Unit 2: Working with Master Data in SAP BW/4HANA
XXL attributes are XXL InfoObjects, which are logically assigned to the characteristic. You can
use XXL InfoObjects to save additional information for a characteristic as data type STRING or
XSTRING. XSTRING is predefined byte-like ABAP type with variable length. This type ensures
dynamic allocation of memory.
You can further specify the data type by using a MIME type. Numerous formats are supported
including different document types, audio files or video files, texts and images. You can create
the XXL attributes either in the XXL Attributes tab or by using transaction RSD1.
To Create a Virtual Master Data
You want to use virtual navigation attributes and texts in a VirtualProvider based on an SAP
HANA model, so you need to create virtual master data.
1. In the context menu for your InfoArea, copy your
U##_COSTC characteristic.
2. Delete the 0CURRENCYand 0ENTRYDATE attributes.
3. Change attributes and texts to not time dependent.
4. Select only short text.
5. Remove the hidden flag for the text field for master data for your calculation view.
6. On the Master Data/Texts tab, change the details of read access to SAP HANA Attribute
View .
7. Specify an SAP HANA package STUDENT## and your SAP HANA calculation view for
master data.
8. Assign SAP HANA View Fields to your attributes and texts.
9. In each case, select suitable SAP HANA attributes for attributes, texts, and compounding
(if applicable).
10. Save and activate the characteristic.
You can now use the characteristic with virtual master data in your VirtualProvider.
LESSON SUMMARY
You should now be able to:
Explain the InfoObject: Characteristic
© Copyright. All rights reserved.
42
Unit 2
Lesson 2
Creating a Generic DataSource
LESSON OVERVIEW
This lesson introduces DataSources and shows you how to create a generic DataSource to
load master data from an SAP source.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Create a generic DataSource
Generic DataSources
A source system is any system that is available to SAP BW/4HANA for data extraction and
transfer purposes.
Figure 39: Comparison Between Classic and SAP BW/4HANA Source Systems
The following technologies are used to load data to SAP BW/4HANA:
You can use the Operational Data Provisioning Framework (ODP) to transfer data from
various SAP repositories to SAP BW 4HANA.
Operational Data Provisioning offers the following communication channels for data transfer:
Remote Function Call (RFC)
You can access ABAP systems via RFC.
© Copyright. All rights reserved.
43
Unit 2: Working with Master Data in SAP BW/4HANA
Web Service (SOAP via HTTP or HTTPS)
The Web Service implementation can occur outside of ABAP.
The data in the source is available for extraction in the form of operational data providers. An
operational data provider defines interfaces for transaction data and master data (attributes,
texts, hierarchies). Once implemented for the repository in question, these interfaces make it
possible to access data for replication to SAP BW/4HANA. For the SAP repositories, there are
corresponding providers for the operational delta queues. The SAP BW/4HANA system that
the data is transferred to subscribes to these delta queues. For sources that can deliver data
changes, the ODP framework also supports delta procedures. Once an SAP repository has
implemented the relevant interfaces of the ODP framework, it is available for data transfer
with Operational Data Provisioning.
Figure 40: SAP BW/4HANA Source Systems
You can create source systems from the SAP BW/4HANA modeling tools and can call various
source system functions:
In the Data Sources tree in the Project Explorer view, you can create and edit source
systems from the context menu in the relevant folder of the source system type.
In the context menu of a source system, you can specify whether empty folders in the
hierarchy of the source objects (application component hierarchy) are shown or hidden.
For replicating source systems, you can replicate the DataSources via the context menu.
Creating a Source System of Type
SAP HANA Local Database Schema
The SAP HANA source system provides central and unified access to tables, views, and native
DataStore objects in the local SAP HANA database or in an SAP HANA tenant database
schema. In addition, the SAP HANA source system provides these services to sources created
using SAP HANA Smart Data Integration and SAP HANA Smart Data Access.
© Copyright. All rights reserved.
44
Lesson: Creating a Generic DataSource
Creating a Source System of Type
SAP HANA Smart Data Access
The SAP HANA source system provides central and unified access to tables, views, and native
DataStore objects in the local SAP HANA database or in an SAP HANA tenant database
schema. In addition, the system provides these services to sources created using Enterprise
Information Management (EIM) that consists of SAP HANA Smart Data Integration (SDI) and
SAP HANA Smart Data Access (SDA).
Operational Data Provisioning provides a technical infrastructure that you can use to support
two different application scenarios. The first of these is Operational Analytics for decision
making in operative business processes. The other is data extraction and replication.
With Operational Data Provisioning the delta queue is located highly compressed in the source
system. The delta can be directly loaded to the BW InfoProvider using the Data Transfer
Process.
DataSource Definition
DataSources are SAP BW objects that are used to extract and stage data from source
systems. DataSources subdivide the data provided by a source system into self-contained
business areas. Our cost center example includes cost center texts, master data, and Cost
Center Transaction DataSources from two different source systems.
DataSources contains a number of logically related fields that are arranged in a flat
structure and contain data to be transferred into SAP BW.
The configuration transaction code used to set up the generic (customer-defined)
DataSource on the source system (T41_SAP, in our case) is SBIW. SBIW is the central
transaction on an SAP source system, used to customize the data transfer to SAP BW, to
enhance Business Content DataSources , or to develop generic (customer-defined)
DataSources where no Business Content DataSources (for example, customer tables) exist. In
our case, we use transaction code SBIW to create a generic DataSource to read cost center
data from the table where it is stored.
© Copyright. All rights reserved.
45
Unit 2: Working with Master Data in SAP BW/4HANA
Operational Data Provisioning
Figure 41: Operational Data Provider Technology
The (ODP) is the link between business data stored in the structure of DataSources and the
requirements arising from Operational Analytics and the replication of mass data. The
Operational Data Provider defines interfaces for transaction data and master data. Once
implemented, these allow access to data for reporting and analysis, and for replication to
various consumers. For BW DataSources with direct access, there is a generic
implementation of ODP interfaces.
Operational Data Providers are defined in a joint modeling environment for search and
analysis. In a search and analysis model, BW DataSources or other data sources are imported
as nodes. When an Operational Data Provider is defined on a node, the node has analytic
properties added to it. This node defines, for example, whether a particular field is interpreted
as a key figure or a characteristic, whether it is available as a navigation attribute, and which
selection properties a field has.
For Operational Analytics, an Operational Data Provider can be linked with other semantically
related Operational Data Providers , using relations that define foreign key relationships. The
Analytic Manager can derive an InfoProvider from this kind of model. An InfoProvider of this
type is known as a Transient Provider . Instead of being modeled like in BW, it is modeled at
query design time and created at runtime. Operational Data Providers thus allow reporting
and analysis on BW DataSources or other data sources in the business application's operative
system, without having to replicate the data to a BW.
In the implementation of DataSources, the Operational Data Provider implicitly supports
replication of mass data by using the replication properties of the DataSources.
© Copyright. All rights reserved.
46
Lesson: Creating a Generic DataSource
Figure 42: Operational Data Provisioning – Delta Queue (ODP/ODQ)
Operational data provisioning supports extraction and replication scenarios for various target
applications and supports delta mechanisms in these scenarios. In addition, it allows data
transfer out, for example SAP BusinessObjects Data Services, with a service for extraction,
transformation, and loading (ETL). To support the delta procedure, the data from a source is
automatically written to a delta queue using an update process or passed to the delta queue
using an extractor interface. DataSources are currently supported as providers that make the
delta queue data available. The target applications (referred to as subscribers) retrieve the
data from the delta queue and continue processing the data.
The Delta Queue Monitor (transaction ODQMON
) helps you to monitor delta queues in the
following views:
Queues: Here you see all the queues available in the system with the status of each queue,
and the number of associated subscriptions and requests.
Subscriptions: The detailed information for the subscription level is displayed here.
Requests: The detailed information for the request level is displayed here.
Units: The units in which the data from a request can be transferred jointly are displayed
here.
To access the views, use the buttons or the Monitor menu.
The data is stored in a compressed state in the delta queue. A delta request transfers data
records from the queue to the subscriber. The data changes to a queue can also be requested
by more than one subscriber. A subscriber can also request data from a queue as a one-off
request (Full). In this case, the request is not a subscription.
The data is retained in the delta queue for a specified time period in case the subscriber wants
retrieve the data records again.
© Copyright. All rights reserved.
47
Unit 2: Working with Master Data in SAP BW/4HANA
Figure 43: DataSource Creation Access and the Generic Extractor
The previous screenshot shows transaction SBIW in the source system. Here you can create
and change generic DataSources.
Figure 44: Release DataSource for ODP
The ODP API does not show all extractors, it only shows the released ones. Multiple extractors
have been developed by SAP, some became obsolete, some might not work with this API. So
along with the ODP API, a new table is created in the dictionary called ROOSATTR that
© Copyright. All rights reserved.
48
Lesson: Creating a Generic DataSource
contains all the extractors in the API that DataServices 4.0 supports. Initially, this is a very
limited list focusing only on the most important extractors. It will grow over time. It will not
include customer written extractors.
Customer extractors can be added to the table by the RODPS_OS_EXPOSESAP program.
More information on the availability of standard extractors are found in
SAP Note 1558737
and SAP Note 1806637.
Figure 45: DataSource in SAP BW After Replication
To access DataSources and map them to your InfoProviders , you must tell SAP BW/4HANA
the name and fields that are provided by the DataSource. This process is called replication, or
replicating the DataSource metadata. It is accomplished from the Context menu of the folder
where the DataSource is located. Once the DataSource has been replicated into SAP BW/
4HANA, the final step is to activate it. You can activate Business Content data flows entirely
from within the Data Warehousing Workbench . During this process, the Business Content
DataSource Activation in the SAP source system, and replication to SAP BW/4HANA takes
place using a Remote Function Call (RFC).
This following figure shows the progress of our data model by each exercise:
© Copyright. All rights reserved.
49
Unit 2: Working with Master Data in SAP BW/4HANA
Figure 46: Create a Generic DataSource Exercise
LESSON SUMMARY
You should now be able to:
Create a generic DataSource
© Copyright. All rights reserved.
50
Unit 2
Lesson 3
Creating Transformation and Data Transfer
Process (DTP) for Attribute Master Data
Loading
LESSON OVERVIEW
This lesson introduces the data transfer process (DTP). This lesson shows you how to create
a transformation and DTP.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Create transformation and data transfer process (DTP) for attribute master data loading
Data Flow for Master-Data Bearing InfoObject
Figure 47: Data Flow for Master-Data Bearing InfoObject
The following are the steps for the loading process. Note that, in step 2, the
replicated and activated, and also that the characteristic is InfoProvider .
© Copyright. All rights reserved.
DataSource is
51
Unit 2: Working with Master Data in SAP BW/4HANA
1. Create a DataSource on the SAP ECC side to define which fields you want to upload to
SAP BW/4HANA.
2. Release the DataSource on the SAP ECC side using the RODPS_OS EXPOSEreport.
3. Replicate the DataSource to SAP BW/4HANA to make the fields available.
4. Activate the DataSource.
5. Insert the characteristic as an InfoProvider, because the target of a transformation must
be an InfoProvider. (This is done automatically using the data flow function).
6. Create a Transformation to define how the fields of the DataSource are mapped to the
attribute fields of the characteristic.
7. Create and run the Data Transfer Process (DTP) to load the data from the ODQ Delta
Queue to the attributes table.
Figure 48: Loading SAP Source System Master Data Scenario
Cleaning or transforming the data is accomplished in a dedicated SAP BW/4HANA
transformation. Each time you want to convert incoming fields from your source system to
InfoObjects in your SAP BW/4HANA InfoProviders, you create a dedicated Transformation ,
consisting of one transformation rule for each object.
Instead of writing the custom transfer code for each occurrence of cost center in a
transformation, we can attach the code directly to the InfoObject ( U##_COSTC in our case).
By creating a global transfer routine containing our desired logic, we guarantee that this logic
is executed automatically each time the InfoObject cost center is used in a transformation.
With a single code writing effort we are covered everywhere the InfoObject cost center is
used.
Transformation and DTP
You can create SAP BW/4HANA transformations using the context menu of the InfoProvider.
The system uses the InfoProvider as the target of the SAP BW/4HANA transformation. You
© Copyright. All rights reserved.
52
Lesson: Creating Transformation and Data Transfer Process (DTP) for Attribute Master Data Loading
also can create the SAP BW/4HANA transformation using the
Flow object, which is explained later.
Context menu within the Data
Figure 49: Transformation for Attribute Master Data
During this first load process, we are trying to keep things simple. Because we added some
custom global transfer logic directly to our InfoObject, we just need field-to-field mapping for
our third step.
With the exception of our 13–character cost center, all the other fields in the master data of
the cost center in the CSKS table in the SAP ERP system have corresponding InfoObjects; we
need to give the information to SAP BW. To do this, we create a transformation and fieldspecific transformation rules. In our case, all the rules will be of the Direct Assignment type.
The assignments between the fields and the cost center master data table can be performed
by dragging and dropping in the transformation.
© Copyright. All rights reserved.
53
Unit 2: Working with Master Data in SAP BW/4HANA
Figure 50: Creation and Monitoring of the Data Transfer Process
When you run the Data Transfer Process (DTP), the system asks you whether you want to
check the monitor. Here you will find all information about the loading process.
Figure 51: Successful Master Load Tool
© Copyright. All rights reserved.
54
Lesson: Creating Transformation and Data Transfer Process (DTP) for Attribute Master Data Loading
After the loading of the attributes, you can check the master data using the context menu of
the Manage Attributes InfoObject. You can also open the InfoObject and select
Miscellaneous
Maintain Master Data or you access the tables on the Properties tab.
Figure 52: Create Transformation and DTP for Attribute Master Data Exercise
LESSON SUMMARY
You should now be able to:
Create transformation and data transfer process (DTP) for attribute master data loading
© Copyright. All rights reserved.
55
Unit 2
Lesson 4
Outlining the Graphical Data Flow Modeling
LESSON OVERVIEW
This lesson introduces graphical data flows and covers how to create them.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Understand the graphical data flow modeling
Graphical Data Flow
The SAP BW/4HANA Modeling tools contain a graphical user interface. This provides you
with a simple way of creating, editing, and documenting data flows and objects in data flows.
You can also display and modify the data flow, which corresponds to a specific object on the
graphical user interface. We created the first data flow for the attributes with the
Context
menu. We will create the second data flow for texts in the Graphical Data Flow tool.
The Graphical Data Flow Tool
Data flow objects can be used to manage and execute data flow components. Data flow
objects use a graphical user interface.
Graphical Data Flow Modeling
A graphical user interface enables you to easily create data flow objects and data flow
templates. Graphical data flow modeling has various benefits. Graphical top-down modeling
facilitates fast, structured modeling.
© Copyright. All rights reserved.
56
Lesson: Outlining the Graphical Data Flow Modeling
Figure 53: Building a Data Flow Object
A data flow depicts a specific scenario in SAP BW/4HANA. It describes a set of SAP BW/
4HANA objects, including their relationships and interdependencies. The BW Modeling Tools
contain various editors with graphical user interfaces that enable you to create, edit,
document, and analyze data flows and their objects.
Term
Definition
Data flow
The data flow in SAP BW/4HANA defines
which objects are needed at design time and
which objects are needed at run time to
transfer data from a source to SAP BW/
4HANA and cleanse, consolidate, and integrate the data so that it can be used for analysis, reporting, and possibly for planning. A
data flow depicts a specific scenario including all involved objects and their relationships. Data flow object A data flow object is a
TLOGO object in SAP BW/4HANA, which describes a data flow. Data flow objects are created and edited in a graphical editor. They
help you to visualize the SAP BW/4HANA objects (and their relationships) contained in a
data flow. They have no relevance for the
SAP BW/4HANA run time.
© Copyright. All rights reserved.
57
Unit 2: Working with Master Data in SAP BW/4HANA
Term
Definition
Transient data flow
Using an editor, you can flexibly show and analyze the data flow for any persistent, active
SAP BW/4HANA object. This representation
of a data flow that starts from an object is referred to as a transient data flow. The editor
for a transient data flow is referred to as a
transient editor. A transient data flow can be
saved as a data flow object.
Persistent SAP BW/4HANA object
A persistent SAP BW/4HANA object is an object which has already been saved in the metadata tables in the database and is independent of the data flow object. A persistent object can be contained in multiple data flows
and can therefore be used again in different
data flows.
Non-persistent SAP BW/4HANA object
A non-persistent SAP BW/4HANA object is a
draft version of an SAP BW/4HANA object. It
is an object that only attributes such as object type and name have been specified for
so far. It has not been saved on the database.
A non-persistent object can only be displayed and used in the data flow in which it
was created. If you create a non-persistent
object in the transient editor, it will be discarded if you quit the editor without saving
the data flow as a data flow object.
© Copyright. All rights reserved.
58
Lesson: Outlining the Graphical Data Flow Modeling
Figure 54: Data Flow Objects for Transactional Data
You can create a data flow object and benefit from its advantages. For example, you can start
by creating a logical data flow with non-persistent objects and relationships (blueprint) and
then create SAP BW/4HANA objects, transformations, and loading processes later on, in
order to persist data in the metadata tables.
You do not necessarily require a data flow object to model objects and relationships in data
flows. You can also use the transient editor for this. The graphic transient editor provides a far
better overview of a data flow than a tree display can. This means, for example, that when you
expand a data flow in different directions, the graphical representation always remains very
clear. Even loops, which start from one object with transformations (and sometimes further
objects) and return to the initial object, are represented more clearly in the graphical editor
than in a tree display.
To Create a Graphical Data Flow
This procedure explains how to create a data flow in the Data Warehousing Workbench in the
Data Flow tree menu.
1. In the context menu of the InfoArea , choose New
Data Flow.
2. In the Create Data Flow dialog box, in the Data Flow field, enter a technical name and, in
the Description field, enter a description of the Data Flow, and choose Continue .
The Edit Data Flow screen appears. The technical name of a Data Flow is limited to 30
characters.
3. Add the required objects to the Data Flow, select the objects and drag them to the Data
Flow work area. There are different ways of adding persistent and/or non-persistent
objects.
© Copyright. All rights reserved.
59
Unit 2: Working with Master Data in SAP BW/4HANA
4. Connect the objects to each other.
5. Check the Data Flow for consistency, and then choose Check.
A Data Flow is consistent and can be activated if all objects contained in the Data Flow
exist persistently and have the object status Active. If the Data Flow contains nonpersistent objects, warnings appear during the consistency check. However, the Data Flow
can still be saved.
6. Save and activate the Data Flow.
Graphical Data Flow for Loading Text Master Data
Figure 55: Load Text Master Data Using the Graphical Data Flow Exercise
Here is the diagram that presents the next exercise.
LESSON SUMMARY
You should now be able to:
Understand the graphical data flow modeling
© Copyright. All rights reserved.
60
Unit 2
Lesson 5
Modeling and Administration of SAP BW/
4HANA Hierarchies
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Model and load a simple SAP BW/4HANA hierarchy
Hierarchies for InfoObjects
Figure 56: Hierarchy Tab
Hierarchies are used in analysis to describe alternative views of the data. They serve a
grouping function just as they do in other SAP products, for example, SAP ECC. A hierarchy
consists of several nodes and leaves, forming a parent-child relationship. The nodes
represent any grouping you desire, for example, West Region. The hierarchy leaves are
represented by the characteristic values, for example, a salesperson.
On the Hierarchy tab, you determine whether the characteristic can have hierarchies and, if
so, what properties these hierarchies can have. If you select the With hierarchies checkbox,
hierarchies can be created manually for this characteristic. Alternately, they can be loaded
from the SAP system or other source systems.
© Copyright. All rights reserved.
61
Unit 2: Working with Master Data in SAP BW/4HANA
Figure 57: Version Dependent Hierarchy
In SAP BW, external hierarchies are presentation hierarchies, stored in hierarchy tables as a
structure for characteristic values.
In addition, the relationships can be time-dependent. Different hierarchy versions or time
dependencies that exist in the source system can be modeled in SAP BW/4HANA.
Characteristic hierarchies can be used in different hierarchy versions. Different hierarchy
versions in the source system can be modeled in SAP BW/4HANA; however, you can also
create different versions for the same hierarchy from the source system. These versions can
then be compared with one another in a query. For example, during restructuring of the sales
districts for the Main District characteristic of an organization, several hierarchy versions are
created. These hierarchies can be compared to each other in a query.
Figure 58: Time-Dependent Entire Hierarchy
On the Hierarchy tab, you can define that the entire hierarchy can be time-dependent. In other
words, there are different versions for this hierarchy that are valid for a specific time interval
© Copyright. All rights reserved.
62
Lesson: Modeling and Administration of SAP BW/4HANA Hierarchies
only. The system automatically chooses the valid version based on settings in the query. For
example, during restructuring of the sales districts for the Main District characteristic of an
organization, the hierarchy is made time-dependent. This process enables restructuring to be
compared for different times in a query (using the Key Date field).
Figure 59: Time-Dependent Hierarchy Structure
On the InfoObject , you can determine that the hierarchy structure (a hierarchy node) is to be
time-dependent. The hierarchy is then constructed for the current key date or for the key date
specified in the query.
For example, assume that during restructuring of sales districts for an organization, it was
found that an employee is assigned to different cost centers at different times. It is possible to
position characteristic values in the form of intervals under a hierarchy node. Instead of
positioning each cost element value for material costs individually under the material costs
node in a cost element hierarchy, you can specify the cost element values as a cost element
between 100 and 1000. You can also create intervals for characteristic values for which no
master data currently exists. As a result, you do not need to extend the hierarchy for new
master data (because new characteristic values are allocated automatically).
One limitation of the interval option in many areas is that the technical key of the
characteristic value must be meaningful. Most companies do not have smart numbering for
their part numbers or customers. The interval option can, however, in many cases, be used in
financial-related objects, such as general ledger account numbers.
The following are prerequisites for using hierarchies for characteristics:
You cannot create hierarchies for characteristics that are referenced to other
characteristics (that is, reference characteristics).
A characteristic can have more than one hierarchy.
If a characteristic has hierarchies, the maximum length (of the characteristic value) with
compounding is restricted to 32 (not 60) characters.
Reverse plus and minus (+/-) signs for hierarchy nodes can be used to influence the display
behavior of nodes in the query. For each hierarchy node, you can specify whether the plus and
minus (+/-) sign for the transaction data posted on this node is to be reversed (or not) in the
query display.
© Copyright. All rights reserved.
63
Unit 2: Working with Master Data in SAP BW/4HANA
Figure 60: Hierarchies in Reporting
Hierarchies can be used to obtain a better structuring of data if you have thousands of
characteristic values to report.
LESSON SUMMARY
You should now be able to:
Model and load a simple SAP BW/4HANA hierarchy
© Copyright. All rights reserved.
64
Unit 2
Lesson 6
Deleting and Activating Master Data
LESSON OVERVIEW
This lesson explains how to delete and activate master data.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Understand deletion and activation of master data
Deleting and Activating Master Data
Figure 61: Administration: Request Management for InfoObjects
A loading process is called a request. You can view information about requests and check
whether the data has been posted and updated successfully. You can delete the
administrative information for these requests, however, you cannot delete data from the
InfoObject as is possible with DataStore Objects (advanced).
© Copyright. All rights reserved.
65
Unit 2: Working with Master Data in SAP BW/4HANA
Figure 62: Administration: Characteristic Master Data Deletion
You can delete master data and texts directly from the master data table in BW. In contrast to
deleting at single record level, you can use this function to delete all the existing master data
and texts for a characteristic in one action.
Prerequisites: In order to delete master data, there must be no transaction data in BW for the
master data in question. It must not be used as an attribute for InfoObjects and there must
not be any hierarchies for this master data.
You reach the Delete Master Data function from the Context menu of your InfoObject in the
InfoObject tree, and also the InfoProvider tree.
If you choose the Delete Master Data function, the program checks the entries in the master
data table affected to see if they are used in other objects.
When you delete, you are able to choose whether entries in the SID table of a characteristic
are to be retained, or whether they are to be deleted:
If you delete the SID table entry for a particular characteristic value, the SID value assigned
to the characteristic value is lost. If you load new attributes for this characteristic value
later, a new SID value has to be created for the characteristic value. In general, this has a
negative effect on the run time that is required for loading. In some cases, deleting entries
from the SID table can also lead to serious data inconsistencies. This occurs if the list of
SID values generated from the where-used list is not comprehensive, this is rare, however.
Delete, while retaining SIDs
You should choose this option as standard. Even if, for example, you want to make sure
that individual attributes of the characteristic that are no longer needed are deleted before
you load master data attributes or texts. Deleting master data while retaining the entries
from the SID table is also absolutely adequate.
Delete with SIDs
© Copyright. All rights reserved.
66
Lesson: Deleting and Activating Master Data
Note that deleting entries from the SID table is only necessary, or useful, in exceptional
cases. One example is if the composition of the characteristic key is changed and you want
to swap a large record of characteristic values with a new record with new key values.
Figure 63: Administration: Master Data Activation
The SAP BW/4HANA system automatically activates the master data so that it can be used
directly in reporting. Texts are active immediately and can be used directly in analysis and
reporting. You do not need to activate them manually.
LESSON SUMMARY
You should now be able to:
Understand deletion and activation of master data
© Copyright. All rights reserved.
67
Unit 2
Learning Assessment
1. Which of the following are types of InfoObject?
Choose the correct answers.
X
A Key Figure
X
B Currency
X
C Unit
X
D Characteristic
2. What is a DataSource?
Choose the correct answer.
X
A A flat structure of logically related fields that contain data to be transferred into
SAP BW/4HANA
X
B An object that defines master data modeling rules, such as compounding
X
C A store of data used for staging
X
D A structure used to define transformation rules
3. What is replication?
Choose the correct answer.
X
A Copying data from one layer to another
X
B Making the source system fields used in an extraction available to SAP BW/4HANA
X
C Moving data from the source system to SAP BW/4HANA
4. You must first create all objects before including them in a Data Flow.
Determine whether this statement is true or false.
X
True
X
False
© Copyright. All rights reserved.
68
Unit 2: Learning Assessment
5. Why do we create hierarchies?
Choose the correct answer.
X
A To identify the sequence of objects used in a data flow
X
B To provide the sequence logic for the correct activation of the modeling objects
X
C To obtain a better structuring and navigation of data if you have large numbers of
characteristic values in a report
6. You can only delete master data if there is not transaction data in SAP BW/4HANA which
refers to it.
Determine whether this statement is true or false.
X
True
X
False
© Copyright. All rights reserved.
69
Unit 2
Learning Assessment - Answers
1. Which of the following are types of InfoObject?
Choose the correct answers.
X
A Key Figure
X
B Currency
X
C Unit
X
D Characteristic
Correct — types of InfoObject are Key Figure, Unit, Characteristic. Currency is not a type
of InfoObject. The missing type is Time.
2. What is a DataSource?
Choose the correct answer.
X
A A flat structure of logically related fields that contain data to be transferred into
SAP BW/4HANA
X
B An object that defines master data modeling rules, such as compounding
X
C A store of data used for staging
X
D A structure used to define transformation rules
Correct — A DataSource is a flat structure of logically related fields that contain data to be
transferred into SAP BW/4HANA
3. What is replication?
Choose the correct answer.
X
A Copying data from one layer to another
X
B Making the source system fields used in an extraction available to SAP BW/4HANA
X
C Moving data from the source system to SAP BW/4HANA
Correct — Replication is making the source system fields used in an extraction available to
SAP BW/4HANA
© Copyright. All rights reserved.
70
Unit 2: Learning Assessment - Answers
4. You must first create all objects before including them in a Data Flow.
Determine whether this statement is true or false.
X
True
X
False
Correct — A Data Flow can include objects that are not yet created but are simply
placeholders for objects you will create later
5. Why do we create hierarchies?
Choose the correct answer.
X
A To identify the sequence of objects used in a data flow
X
B To provide the sequence logic for the correct activation of the modeling objects
X
C To obtain a better structuring and navigation of data if you have large numbers of
characteristic values in a report
Correct — Hierarchies are used to obtain better structuring and navigation of data if you
have large numbers of characteristic values in a report.
6. You can only delete master data if there is not transaction data in SAP BW/4HANA which
refers to it.
Determine whether this statement is true or false.
X
True
X
False
Correct — You can only delete master data if there is not transaction data in SAP BW/
4HANA which refers to it
© Copyright. All rights reserved.
71
UNIT 3
Working with
Transactional Data in
SAP BW/4HANA
Lesson 1
Introducing InfoProviders
73
Lesson 2
Creating a Key Figure InfoObject
78
Lesson 3
Modeling Data Mart DataStore Objects (Advanced)
81
Lesson 4
Creating a Data Flow for Transaction Data
87
Lesson 5
Creating a Standard DataStore Object and Loading Data from a Flatfile DataSource
94
Lesson 6
Modeling CompositeProviders
112
UNIT OBJECTIVES
Describe InfoProviders
Create a key figure InfoObject
Model Data Mart DataStore Objects
Create a data flow for transaction data
Create a Standard DataStore Object
Load Data from Flatfile DataSource into the DataStore Object
Activate data in a DataStore Object (advanced)
Create a CompositeProvider
© Copyright. All rights reserved.
72
Unit 3
Lesson 1
Introducing InfoProviders
LESSON OVERVIEW
This lessons introduces InfoProviders. This lesson explains how InfoProviders are utilized in
SAP BW.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Describe InfoProviders
InfoProviders in SAP BW/4HANA
What are InfoProviders?
An InfoProvider is an object for which queries can be created and run.
InfoProviders can store persistent data, or they just collect data from other InfoProviders.
The definition correctly infers that an InfoProvider can be either physical storage of data in
real database tables, or a virtual collection of data (such as a view) that only collects data
temporarily to feed it to a query, but does not permanently store it. In this, our first exposure
to InfoProviders, we will focus on the two main physical InfoProviders:
Data Mart DataStore Objects
Standard DataStore Objects
© Copyright. All rights reserved.
73
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 64: Persistence Layers in the SAP BW/4HANA Enterprise Data Warehouse
Data that is extracted from an SAP source system can be stored, initially, in the Operational
Delta Queue (ODQ). Next, in most cases, you must physically and permanently store this data
in SAP BW/4HANA. For permanent storage, and to be able to access the SAP BW/4HANA
data with reporting tools, you must create InfoProviders. SAP BW/4HANA offers a range of
InfoProviders for various purposes. Some store data physically, while others provide an
additional view of the data.
In many situations, it is necessary to incorporate additional layers in the staging process. SAP
BW/4HANA enables you to integrate one or more DataStore (advanced) Objects into the data
flow between the DataSource and CompositeProvider. These DataStore (advanced) Objects
normally save data on a detailed level. The following are the 2 principal types of InfoProviders:
Characteristic InfoObject
Stores master data.
DataStoreObject (advanced)
Stores transaction data on detailed level. Examples include, sales order data on item level.
With transformations, you can transform, enrich, and change the data you extracted from the
source system. This may be necessary for special reporting requirements or to harmonize the
data of different source systems.
The following graphic gives an overview of the ways in which the different InfoProviders can
be used in SAP BW. Each InfoProvider fulfills a separate role, and can be loaded with data
from the source systems. The data can be accessed and reported using the SAP BW reporting
tools.
© Copyright. All rights reserved.
74
Lesson: Introducing InfoProviders
Figure 65: SAP BW/4HANA Data Flow Example
A DataSource is the object in SAP BW that is created for data extraction from the source
system. The DataSource holds information about the location of the required data and about
the structure of the data. The Operational Delta Queue (ODQ) stores the required data in the
SAP source system. It holds the data in the source format (not transformed).
InfoProviders are the objects that are used to store the data permanently or access data from
other tables in SAP BW. They are also the relevant objects on which you base your reporting
requests.
Figure 66: Standard DataStore Object: A Simplified Functional View
© Copyright. All rights reserved.
75
Unit 3: Working with Transactional Data in SAP BW/4HANA
A Standard DataStore Object (advanced) is used to store consolidated and cleansed data
(transaction data or master data) on a document level (atomic level). Although DataStore
Objects can store master data for valid reasons, they primarily store detailed transaction
data. The figure, Standard DataStore Object: A Simplified Functional View, shows the position
of Standard DataStore Objects (advanced) in the overall warehouse design. They can be used
to support detailed operational reporting, or can be part of the warehouse, where they can be
used to hold years of data that may be needed.
Data Mart DataStore Objects (advanced) are designed to store summarized and aggregated
data for long periods of time. Normally, the Standard DataStore Object should be sufficient.
Your goal in designing a warehouse is only to use this type of object if you are dealing with big
amounts of data or many complex calculations, so the reporting on a Standard DataStore
Object (advanced) becomes slow.
SAP BW/4HANA Core InfoProviders
A CompositeProvider is a type of InfoProvider that combines data from a number of
InfoProviders and makes it available for analysis purposes. The CompositeProvider itself does
not contain any data. Its data comes entirely from the InfoProviders on which it is based.
These InfoProviders are connected to one another by a union operation.
A CompositeProvider can consist of different combinations of the following InfoProviders:
InfoObjects
Standard DataStore Objects
Data Mart DataStore Objects
CompositeProviders
Open ODS Views
Figure 67: CompositeProvider Serve as a Virtual Layer for Queries
© Copyright. All rights reserved.
76
Lesson: Introducing InfoProviders
Modelers can use the DataStore Objects (advanced) for modeling the persistence of new
complete scenarios. DataStore Objects (advanced) provide further enhancements, such as
modeling on InfoObjects , as well as on simple fields. DataStore Objects (advanced) are the
central objects for modeling persistence layers. SAP recommends to place a
CompositeProvider between the DataStore Objects (advanced) and the query for flexibility
and performance.
LESSON SUMMARY
You should now be able to:
Describe InfoProviders
© Copyright. All rights reserved.
77
Unit 3
Lesson 2
Creating a Key Figure InfoObject
LESSON OVERVIEW
This lesson shows how to create a key figure InfoObject.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Create a key figure InfoObject
Key Figure InfoObjects
Figure 68: Key Figure InfoObject Type/Unit Tab
If you choose the Amount or Quantity key figure type, you must assign a currency or quantity
unit to this key figure. For the Amount key figure type, you can choose between a fixed
currency (for example, EUR) or a variable currency (for example, 0CURRENCY). For the
Quantity key figure type, you can choose between a fixed quantity unit such as KG, or a
variable quantity unit such as 0UNIT.
© Copyright. All rights reserved.
78
Lesson: Creating a Key Figure InfoObject
Currency or unit is variable, which means you assign a field to hold whatever currency a
specific transaction is in. If you know your whole business or just one measurement is always
in a consistent currency, there is no reason to have a variable field.
Figure 69: Key Figure InfoObject Aggregation
Aggregation rules for the key figure behavior are set on this tab when data is stored in tables
in SAP BW and for Exception Aggregation during execution of reports. This setup guarantees
that key figures are evaluated meaningfully. The aggregation behavior determines whether or
not, and in which way, the key figure values can be summarized using the different
characteristics and their values within the evaluation. The Aggregation rules are only valid for
Data Mart DataStore Objects. Exception Aggregation is just a default aggregation for queries.
Figure 70: Create a Key Figure InfoObject
© Copyright. All rights reserved.
79
Unit 3: Working with Transactional Data in SAP BW/4HANA
A non-cumulative value is a non-aggregating key figure, on the level of one or more objects,
that displays in relation to time. Examples of non-cumulative values include head count,
account balance, and material inventory. These values are non-cumulative with respect to
time. For example, you cannot add inventory for this month and inventory for next month to
calculate the total inventory.
LESSON SUMMARY
You should now be able to:
Create a key figure InfoObject
© Copyright. All rights reserved.
80
Unit 3
Lesson 3
Modeling Data Mart DataStore Objects
(Advanced)
LESSON OVERVIEW
This lesson describes how to model DataStore objects.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Model Data Mart DataStore Objects
The Data Mart DataStore Object
The Advanced DSO consists of three core tables which are generated in the background when
the ADSO is created and activated. The system uses the needed tables depending on the
selected modeling options. Regardless of the use case, the following three tables are always
generated in order to support a quick and flexible change of the data model later on:
Inbound table (uncompressed fact table): Technical name
name>1.
Table of active data (compressed fact table): Technical name
name>2 .
/BIC/A<ADSO technical
/BIC/A <ADSO technical
Change log (not used for Data Mart DataStore Objects): Technical name
technical name>3 .
/BIC/A<ADSO
The data is initially loaded into the inbound table. Reporting reads data from the inbound and
active data tables using a union.
Modeling objects and the management of the related data flow and load monitoring is
completely done in the BW Modeling Tools (BWMT) of SAP HANA Studio. When you activate
the data, the data is copied to the table of active data and grouped according to the
aggregation behavior. Afterward, the data is deleted from the inbound table. The change log is
not filled.
© Copyright. All rights reserved.
81
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 71: DataStore Object Structure
The DataStore Object (advanced) is the central object for data storage and data consolidation
in the SAP BW system. When the required properties are set, the DataStore Object
(advanced) can be used in the various layers of the data warehouse. The type most often
used to store documents is called Standard DataStore Object. Just if the reporting
performance is poor because of the data volume or many complex calculations, you can
decide to store the aggregated data in a Data Mart DataStore Object. Nevertheless, we start
by explaining the Data Mart DataStore Object.
Figure 72: Basic Concept of a Data Mart DataStore Object
No additional keys can be specified for this DataStore Object type, but the records are treated
as if all characteristics are in the key (logical key). Only additive deltas can be loaded (for key
© Copyright. All rights reserved.
82
Lesson: Modeling Data Mart DataStore Objects (Advanced)
figures only the aggregations maximum (MAX), minimum (MIN), and summation (SUM) are
allowed). Therefore, key figures cannot be overwritten. The DataStore Object (advanced) can
contain InfoObjects and fields. This allows you to load data into the BW without assigning
InfoObjects.
Figure 73: Master Data Bearing InfoObject
We want to focus on master-data-bearing characteristic InfoObjects. The following figures
show two of the many master-data-bearing characteristics delivered by SAP BW.
Characteristics that have their own master data tables connected to them are very important
in our overall schema design.
A numerical SID key is generated for each characteristic value. This alias key replaces the
characteristic value and allows reporting with high performance. SID stands for master data
ID or surrogate ID (replacement key).
In this DataStore Object, no InfoObjects that are only display attributes are allowed to be
used. Also, no fields with the following data types are allowed to be used: STRING, RAW,
RAWSTRING, DF16_RAW und DF34_RAW.
An aspect of the master data is that it is shared (linked) with all DataStore Objects that have
the associated characteristic InfoObject. The result is that you use the master data for
different DataStore Objects. The master data is DataStore Object (advanced) independent,
and can be used by several queries from several different DataStore Objects at the same
time. This concept is shown in the figure, Shared Master Data Across DataStore Objects.
© Copyright. All rights reserved.
83
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 74: Shared Master Data Across DataStore Objects
When you create Data Mart DataStore Objects, you can assign characteristics and key figures
to groups. The groups are only used as a sort criterion to provide a clearer overview when
creating a query in the Query Designer.
Figure 75: ADSO of type Data Mart
© Copyright. All rights reserved.
84
Lesson: Modeling Data Mart DataStore Objects (Advanced)
In a Data Mart DataStore Object, all characteristics are key and reporting is done using a
union of the inbound and active tables. The system accesses the inbound table and the active
table (using a union across both tables) in the query. In this case, you can only load additive
deltas. The data is aggregated.
Figure 76: Activate Requests in a Data Mart DataStore Object
During the upload of data, a request is always inserted into the inbound table (new data). Each
request gets its own request ID (timestamp). This feature enables you, for example, to delete
a request from the inbound table after the upload. However this may result in several entries
in the inbound table with the same values for all characteristics except the request ID. This
increases the size of the inbound table and decrease the performance of your queries. During
activation, these records are summarized for each request ID into the active table. After the
data has been activated, it is not possible to delete the data for a specific request ID.
Reporting on this type of DataStore Object is consistent and provides stable navigation. A
query can be run immediately after loading. You do not need to activate data beforehand.
When a query is run, the active table and the inbound table are accessed.
Also, there are the following support functions available:
Display data
Display data model
Check and activate data model
Object directory entry
Write transport request
Where-used list
DataStore Object can be used as a source or target of transformations.
© Copyright. All rights reserved.
85
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 77: Exercise: Create a Data Mart DataStore Object
LESSON SUMMARY
You should now be able to:
Model Data Mart DataStore Objects
© Copyright. All rights reserved.
86
Unit 3
Lesson 4
Creating a Data Flow for Transaction Data
LESSON OVERVIEW
This lesson shows how to create a data flow for transaction data.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Create a data flow for transaction data
Transaction Data Loading in a DataStore Object (Advanced)
Figure 78: SAP BW on HANA Data Flow with Operational Data Provisioning
Business applications store operative data in the form of business documents and master
data. In SAP BW, DataSources and their extractors make it possible to access this data.
DataSources provide a flat analytical view of the data in business documents, such as sales
orders or purchase orders. They contain the business logic that derives an analytical view of
the data from the transactional view. There are various types of DataSource: DataSources for
transaction data, master data attributes, master data texts, and master data hierarchies.
Until now, DataSources have been used to replicate mass data from the operative system to
SAP NetWeaver's Data Warehouse, SAP NetWeaver BW. Here, the data is integrated from
© Copyright. All rights reserved.
87
Unit 3: Working with Transactional Data in SAP BW/4HANA
various sources, consolidated and made available for OLAP analysis. OLAP analyses in SAP
BW are not based directly on DataSources however, they are based on InfoProviders.
InfoProviders provide a view of a dataset from various, semantically related DataSources
(purchase order data, customer data, or product data, for example).
With Operational Data Provisioning, SAP NetWeaver provides a metadata concept that allows
analytic query access for OLAP analysis. This occurs in an operative system with replication
scenarios (including an ETL service with a delta mechanism). ODP is implemented in a
modeling environment, used together with the search, and provides a metadata view in which
a DataSource can be given analytical properties to define an Operational Data Provider (ODP).
An Operational Data Provider can be used to access the data for the replication in various
consumers (BWA or SAP BusinessObjects Data Services, for example) and for the purpose of
operational analytics. DataSources are not suitable for Operational Analytics, as they are too
basic. A transaction data DataSource does not recognize the associated master data
attributes, and the DataSource for master data attributes does not recognize the associated
texts. Operational Data Provisioning uses ODPs here to allow semantically related
DataSources to act as InfoProviders, so that the data is available to the Analytic Engine in an
Operational Analytics scenario without the need for replication to SAP NetWeaver BW.
With Operational Data Provisioning, the delta queue is located highly compressed in the
source system. The delta can be directly loaded to the SAP BW InfoProvider using the data
transfer process.
Figure 79: Operational Delta Queue at Work
A delta queue 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 (for example,
0CO_OM_CCA_9), or retrieved using the extractor interface (for example,
0COSTCENTER_ATTR).
The role of a provider is to provide one or more delta queues of a specific type. The BW
DataSource is an example of a provider. In this case, the delta queue name matches the
DataSource name (for example, 0CO_OM_CCA_9). The target application of the delta queue
is referred to as the Subscriber (of a specific data services system, for example). A
subscription can be defined as follows: a specific subscriber orders data changes from one or
more queues and continues processing the transferred data. Subscribers are categorized by
their subscriber type (for example, SAP BusinessObjects Data Services). A subscription
occurs when the subscriber requests data. Every subscription has a unique transaction
number (for example, 2010-10-22 08:03:52 000001 CET ). A subscriber can have more than
one subscription. A queue can also be in multiple subscriptions for the same subscriber.
© Copyright. All rights reserved.
88
Lesson: Creating a Data Flow for Transaction Data
The data is stored in a compressed state in the delta queue. A delta request transfers data
records from the queue to the subscriber. The data changes to a queue can also be requested
by more than one subscriber. A subscriber can also request data from a queue as a one-off
request (Full). In this case, the request is not a subscription.
The data is retained in the delta queue for a specified time for recovery purposes - in other
words, in case the subscriber wishes to retrieve the data records.
Figure 80: Operational Delta Queue at Work
The Delta Queue Monitor (transaction ODQMON
) helps you to monitor delta queues in the
following views:
Queues
Here you see all the queues available in the system with the status of each queue, the
number of associated subscriptions, and the number of associated requests.
Subscriptions
This view displays the detailed information for the subscription level.
Requests
This view displays the detailed information for the request level.
Units
This view displays units in which the data from a request can be transferred jointly.
Use the button or the Monitor menu to access the views.
Delta Queue Monitor information can be restricted as follows:
Preselection in the Monitor
In the upper area of the monitor screen, you can restrict the data displayed in the queue
using various criteria. This process improves the performance of the monitor.
Provider-Based Restriction
© Copyright. All rights reserved.
89
Unit 3: Working with Transactional Data in SAP BW/4HANA
When you select a specific provider, for example BW DataSource, only the queues
belonging to this provider are displayed in the monitor. Subscribers that have not
subscribed to any of the queues of this provider are not displayed. If you do not select a
provider, all of the queues from all of the providers are displayed in the monitor.
Queue-Based Restriction
When you specify a particular queue, for example a DataSource, only this specific queue is
displayed in the monitor. When specifying the queue, you can use the wildcard search ( * ),
for example, 0FI* , to restrict the monitor display to several queues. If you do not specify a
queue, the monitor display is not restricted.
Subscriber Type Restriction
When you select a specific subscriber type, for example SAP BusinessObjectsData
Services, only the queues that have been subscribed to by a subscriber of this type are
displayed in the monitor. If you do not select a subscriber type, all of the queues of all of
the subscriber types are displayed in the monitor.
Subscriber-Based Restriction
When you specify a particular subscriber, for example a data services system, then only
this specific subscriber is displayed in the monitor. When specifying the subscriber, you
can use the wildcard search ( * ), for example, SAP*, to restrict the monitor display to
several subscribers. If you do not specify a subscriber, the monitor display is not
restricted.
You apply these settings when you change between monitor views.
Figure 81: Scenario — Transaction Data Load from ECC to an ADSO
The previous figure shows our scenario using Operational Data Provisioning with the
0CO_OM_CCA_9DataSource.
© Copyright. All rights reserved.
90
Lesson: Creating a Data Flow for Transaction Data
Figure 82: Setting up the Data Flow
The figure shows our scenario setting up the transformation from the
DataSource to the ADSO.
© Copyright. All rights reserved.
0CO_OM_CCA_9
91
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 83: Data Preview of U##_ADSOA
The previous figure shows the data preview, as well as memory consumption and number of
entries, for the inbound table of the ADSO.
© Copyright. All rights reserved.
92
Lesson: Creating a Data Flow for Transaction Data
Figure 84: Load Transaction Data into a DataStore Object (Advanced) Exercise
LESSON SUMMARY
You should now be able to:
Create a data flow for transaction data
© Copyright. All rights reserved.
93
Unit 3
Lesson 5
Creating a Standard DataStore Object and
Loading Data from a Flatfile DataSource
LESSON OVERVIEW
This lesson explains DataStore Object (advanced) type Standard. This lesson also shows how
to create a flat file DataSource. Finally, this lesson shows how to load data from a flat file
DataSource into the DataStore Object (advanced).
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Create a Standard DataStore Object
Load Data from Flatfile DataSource into the DataStore Object
Activate data in a DataStore Object (advanced)
The Standard DataStore Object
Figure 85: The Standard DataStore Object: A Simplified Functional View
A Standard DataStore Object is used to store consolidated and cleansed data (transaction
data or master data) on a document level (atomic level). Although Standard DataStore Object
can store master data, and there are valid reasons for this, they primarily store detailed
transaction data. The figure shows the position of DataStore Objects in the overall warehouse
© Copyright. All rights reserved.
94
Lesson: Creating a Standard DataStore Object and Loading Data from a Flatfile DataSource
design. They can be used to support detailed operational reporting, or can be part of the
warehouse, where they can be used to hold years of data that may be needed.
A Standard DataStore Object is designed in the same way as a table, it contains key fields (for
example, document number and item) and data fields. Data fields can be all InfoObject types
like key figures, units, time and other types of characteristics (for example, order status,
customer, or time). Defining key fields makes it easier to identify your documents.
A Standard DataStore Object that will contain invoice information on header and item level
only receives the InfoObject invoice and invoice item number as the key fields. All other
objects, such as customer, material, and revenue, are modeled as data fields. It may be that
the dependencies are not easy to model, for example, when the data is not to be updated into
the DataStore Object on a document or document line item level. In this case, it makes sense
to deduce these relationships using an entry relationship model.
The Standard DataStore Object
Designed to save cleansed data at a document level:
-
Consolidation or overwritten.
Overwrite function:
-
Characteristics that are not part of the record identifier (Key) always overwrite (for
example, Order Status ).
-
Key Figures (for example, sales amount or number of document lines) can be set to
overwrite, add, or not update.
Figure 86: Schema of a Standard DataStore Object
Standard DataStore Objects consist of the following three tables:
Active Data table
© Copyright. All rights reserved.
95
Unit 3: Working with Transactional Data in SAP BW/4HANA
In this table, the current status of the data is stored. The table contains a semantic
(business-related) key that can be defined by the modeler (order number, item, or
schedule line, for example). The modeler must define the key correctly because a match
on the key initiates special delta processing during the activation phase (this is discussed
later). This table is also used by the Data Manager for reporting.
Change Log table
During the activation run, changes are stored in the change log. In this table, you can find
the complete history of the changes, because the content of the change log is not
automatically deleted. If supplied with data from the DataStore Object in the delta method,
connected targets are updated from the change log. The change log has a technical key
consisting of a request, data package, and data record number.
Inbound table
During the DTP, records are written first to this table. During the activation process, the
data records are then written to the Active Data table and the Change Log table.
Figure 87: Load Data into the Inbound Table of a Standard DataStore Object
© Copyright. All rights reserved.
96
Lesson: Creating a Standard DataStore Object and Loading Data from a Flatfile DataSource
Figure 88: Example of Data Activation in a Standard DataStore Object
The activation run (activating the data in the inbound table so that it can be used) can either
be triggered automatically via a process chain, or started manually. Data sorting occurs at the
start of the activation run. This process takes place, primarily, according to the semantic key
of the DataStore Object (that is, the table with the active data). Next, the data is sorted
according to the technical key of the activation queue. This is the same as the upload
sequence involving the different data records. The sort sequence guarantees that activation
can run in parallel. The number of data records to be activated determines how many
activation processes are started. You can set whether the processes are to run in parallel or in
series.
The user can choose whether changes called up from the load requests are combined in one
change log request, or generated for each loaded request. A change log request identifies
when the records were activated and moved into the change log from the activation queue.
This process is similar to that of a load request identifying when records were loaded. In most
cases, this process should happen nightly at a minimum. You can activate request by request
or activate many requests together.
© Copyright. All rights reserved.
97
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 89: Example of Data Activation in a Standard DataStore Object (2)
In this example, sales document 4711, with a value of 10, was loaded and activated to the
Standard DataStore Object. Document 4711 was changed in the source system and loaded
again. During the activation the system detects that the key is already there. It has therefore
to overwrite the value in the active data table. In the change log table, every step has a
protocol. That means the new value of 30 replaces the old value of 10. After activation, the
request is deleted in the inbound table.
SAP BW/4HANA distinguishes between four DataStore Object types: Standard , Staging,
Direct Update and Data Mart.
Standard DataStore Object:
Write Change Log: If you choose this option, the delta (new, deleted, and changed records)
is saved in the change log. The change log is used to extract the delta. Only if the DataStore
object has a change log can requests be rolled back from the DataStore object, that is, the
status before the activation of the request can be restored.
Snapshot Support : If your DataSource only delivers the current dataset as FULL, by setting
this indicator, deleted data records can be identified and updated. Upon activation, the
system recognizes records that are in the table of active data but not in the load request.
These are written to the change log as reverse images.
Unique Data Records: If you only load unique data records (data records with nonrecurring key combinations) into the DataStore object, you can select this property. If the
indicator is selected, during activation the system checks whether unique records exist. If
a record already exists, the activation is canceled with an error.
The Standard DataStore Object is completely integrated in the staging process. This
situation means that data can be loaded into and out of the DataStore Objects during the
staging process. Using a change log means that all changes are also written and are
available as delta uploads for connected data targets.
Staging DataStore Object:
Inbound Queue: All loaded data arrives in the inbound queue request by request.
© Copyright. All rights reserved.
98
Lesson: Creating a Standard DataStore Object and Loading Data from a Flatfile DataSource
Compress Data: Compression (which is technically the same as activate) is selected by
choosing Compress Data. Then the data is written to the table for active data (during the
compression process) once it arrives in the inbound table. During activation, the data is
aggregated in accordance with the semantic key and is written to the active data table. In
the query, you will then only see the data that has been activated. To save memory space
and improve loading performance, the change log is never used. Therefore you cannot
perform request-based deletion of data from the DataStore object. You can only delete
data selectively.
Reporting-Enabled : Data is written to the active data table, but is also kept in the inbound
table. Since the data is stored redundantly in the inbound table, the data can be deleted
from the active table and rebuilt from the inbound table. The data is only extracted from
the inbound table. When a query is executed, only the active table is accessed and not the
inbound table.
Direct Update DataStore Object:
In a DataStore object for direct update, you can load the data directly into the table for
active data.
With this DataStore object type, the data is directly written to the table of active data. The
data is written either using a DTP or an API. When loaded with DTP and with the API,
consistency checks are made (for example, SID processing, consistency of time
characteristics, areas locked by cold store or NLS). Activation is not possible with this
type.
Only full extraction is possible. The data is read from the table of active data.
Reporting: All data of the active data table is visible in reporting immediately after the data
is loaded.
Data Mart DataStore Object:
In a Data Mart DataStore object, data is always loaded to the inbound table and can be
optionally moved to the active table by activating the request(s). Activating compresses
the data so it is stored more efficiently removing the technical loading information form
the records. The requests that have been activated are then deleted form the inbound
table.
The change log is not used.
Reporting: All data of the active data table and inbound table merged and is visible in
reporting. Therefore you do not have to activate to view data in reports.
© Copyright. All rights reserved.
99
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 90: Create a Standard DataStore Object
Figure 91: Standard DataStore Object
In general, the data is written to the inbound table. If you choose Activate Data , the data is
written to the table for active data (during the activation and compression process) once it
arrives in the inbound table.
There following three options apply:
© Copyright. All rights reserved.
100
Lesson: Creating a Standard DataStore Object and Loading Data from a Flatfile DataSource
Write change log
If you choose this option, the delta (new and changed records) is saved in the change log.
The change log is used to extract the delta. You can only delete data from the DataStore
Object if the object has a change log.
Keep inbound data, and extract from inbound table
If you choose this option, no data is saved in the change log. The extraction process always
reads the data in the inbound table again - for delta extraction or full extraction.
Unique data records
If you only load unique data records (data records with non-recurring key combinations)
into the DataStore Object , you can select this property. This means that the system does
not check whether the record already exists. You must be sure that no duplicate records
are loaded. This means that the table of active data will only contain unique data records.
Data aggregation is not allowed.
Figure 92: Staging DataStore Object
© Copyright. All rights reserved.
101
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 93: In-Memory Optimized DSO - Features of the New Concept
SAP HANA comes with different engines to process calculation logic and execute
programming code. This is a great opportunity to push data-intensive calculations from the
ABAP application layer into the SAP HANA database.
The result of this enhancement is less data transfer between application layer and database
layer, and much better usage of resources. The Application layer focuses more on
orchestration and triggering the processing within the database. In the end, complex logic can
be processed in very little time, which results in great performance improvements.
The main concepts of software innovations can be summed up as follows:
Bring the logic to where the data is (code push down from application layer to database
layer).
Calculate first, then move results.
Standard DataStore Object (Advanced)
Summary of Key Features of Standard DataStore Objects
Standard DataStore Objects serve as the central persistence model for transactional data
in your EDW, based on SAP BW/4HANA.
They support field-based modeling and InfoObject-based modeling.
They support high-frequency data loads.
They can contain up to 120 key fields (InfoObjects as well as fields).
They are modeled in the Eclipse-based SAP BW Modeling Tools.
© Copyright. All rights reserved.
102
Lesson: Creating a Standard DataStore Object and Loading Data from a Flatfile DataSource
Standard DataStore Objects serve as persistence for Open ODS Views.
Standard DataStore Objects offer custom partitions and indexes for performance-critical
access.
Figure 94: Administration and Data Activation for Standard DataStore Object
The activation run (activating the data in the inbound table) is usually triggered by a process
chain, or can be started manually in test cases. The data is sorted at the start of the activation
run. This takes place, primarily, according to the semantic key of the DataStore Object (that
is, the table with the active data). Next, the data is sorted according to the technical key of the
inbound table.
The user can choose whether the changes called up from the different load requests are to be
combined in one change log request, or generated for each loaded request. A load request
identifies when records were loaded, a change log request identifies when the records were
activated and moved into the change log from the inbound table.
© Copyright. All rights reserved.
103
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 95: Exercise: Create a Standard DataStore Object
© Copyright. All rights reserved.
104
Lesson: Creating a Standard DataStore Object and Loading Data from a Flatfile DataSource
Loading a Flat File into a Standard DataStore Object
Figure 96: SAP BW/4HANA Source Systems
To create a source system of the type File, you only need a technical name and a description,
as follows:
1. In the Context menu of DataSources, choose New
Source System .
2. Optional: Under General Properties, specify the business content type and release.
3. Save and activate the source system.
4. Go to the Project Explorer view in the Data Sources tree in the folder Context menu for
the source system type, and choose Refresh.
© Copyright. All rights reserved.
105
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 97: File System DataSource: Extraction Tab
Nearly every company finds it necessary, at some stage, to load a flat file. It may be during a
pilot project, or when data is purchased (a flat file is often the way in which purchased data is
delivered). The basic terms are the same, but there are many more features.
The main difference between loading from an SAP source system and an external system
using flat files is the DataSource. For an SAP source system, you define the DataSource in the
source system and replicate it into SAP BW/4HANA. If you load from an external system
using flat files, you define the DataSource in SAP BW/4HANA.
You have the option of loading data from any workstation into SAP BW. For performance
reasons, however, you should store the data on an application server and load it from there
into SAP BW. This means that you can also load the data in the background. If you want to
load a large amount of transaction data into SAP BW from a flat file, you can specify the file
type of the flat file. Create the flat file as an ASCII file. From a performance point of view,
loading data from an ASCII file is the most cost-effective method. Loading from a CSV file
takes longer because, in this case, the separator characters and escape characters have to be
sent and interpreted. In some circumstances, however, generating an ASCII file may involve
more effort.
The following figures show each of the file-specific DataSource screens. The General Info
screen is not discussed because it is common to all DataSources and, as its name suggests,
provides identification and other basic information.
Text-type files contain only characters that can be displayed and read as text. CSV and ASCII
files are examples of text files. For CSV files, you have to specify a character that separates
the individual field values. In SAP BW/4HANA, you have to specify this separator character
and an escape character, which specifies this character as a component of the value, as
required. After you have specified these characters, you have to use them in the file. ASCII
files contain data in a specified length. The defined field length in the file must be the same as
© Copyright. All rights reserved.
106
Lesson: Creating a Standard DataStore Object and Loading Data from a Flatfile DataSource
the length of the assigned field in SAP BW/4HANA. In addition to the information listed in the
dropdown box in the figure, make note of the Routine icon located next to the name of the file.
The purpose of this icon is to allow you to create programs that, in turn, create the actual
name and location of the flat file dynamically. By using program logic that includes the current
day or month in the resulting file name (01.2018_sales, for example), you can ensure the
same file is not loaded twice. This is because for next month's load, the required file on the
server would need to be 02.2018.
Be careful to correctly define the format of the file. SAP suggests the use of a header row,
because the system can use this header information to help define the fields on the file.
Figure 98: File System DataSource: Proposal Tab
Before you can transfer data from a file source system, the metadata (the file and field
information) must be available in SAP BW in the form of a DataSource. A DataSource based
on a flat file is an object that contains all of the settings necessary to load and parse the file
when it is initiated by the InfoPackage .
The following list gives some of the features of the SAP BW file adapter and file-based
DataSources:
Automatic field proposals at design time
Automated conversion of external data types and formats provided
Preview option allows a double check of file parsing
Fields can be selected as Not Transferred
The Proposal tab reads the header row and proposes field names and types based on what it
finds. These proposed field names, sizes, and types can be changed on the second most
important tab, the Fields tab.
© Copyright. All rights reserved.
107
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 99: File System DataSource: Fields Tab
The Transfer checkbox and the Internal/External dropdown are on the far right of the GUI on
the Fields tab. The Internal/External format toggle tells the parsing program if the data being
sent is in the format that the user sees in an application, or is it in the format stored on the
database. An example might be the fiscal period 01.1999 (external) versus the period
1999001 (internal). You must also identify or correct the data type if it is proposed in error by
the system. For example, during a test load of a cost center transaction load, the system
proposes the data type RAW, when, it should have been a CHAR field.
© Copyright. All rights reserved.
108
Lesson: Creating a Standard DataStore Object and Loading Data from a Flatfile DataSource
Figure 100: File System DataSource: Fields Tab 2
Because a mistake in the Field or the Extraction tabs can corrupt your data load, it is
recommended to check it with real data. The Preview tab does this for you with the number of
records you request after you activate the DataSource.
Figure 101: Administration: ADSO Display Data
© Copyright. All rights reserved.
109
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 102: Load Plan Data from FlatFile to an ADSO (Change Log like) Exercise
© Copyright. All rights reserved.
110
Lesson: Creating a Standard DataStore Object and Loading Data from a Flatfile DataSource
Overwriting Data in a DataStore Object (advanced)
Figure 103: Overwrite Plan Data in an DataStore Object (Advanced) (DSO-like) Exercise
LESSON SUMMARY
You should now be able to:
Create a Standard DataStore Object
Load Data from Flatfile DataSource into the DataStore Object
Activate data in a DataStore Object (advanced)
© Copyright. All rights reserved.
111
Unit 3
Lesson 6
Modeling CompositeProviders
LESSON OVERVIEW
This lesson introduces CompositeProviders. This lesson also shows how to create and utilize
CompositeProviders.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Create a CompositeProvider
Modeling CompositeProviders
Figure 104: Introducing the CompositeProvider
A CompositeProvider is a special InfoProvider that combines reporting data from several
InfoProviders. The CompositeProvider itself does not contain any data, its data comes
exclusively from the InfoProviders on which it is based. Create your SAP BW/4HANA queries
only on CompositeProviders. You can change the InfoProviders that make up the
CompositeProvider without changing the query.
A query can only be written against a single InfoProvider. A CompositeProvider is a single
InfoProvider to a query through which multiple providers can be indirectly accessed. We have
an InfoProvider with actual data for a logically self-contained business area, and a
corresponding InfoProvider with plan data. You can combine the two InfoProviders into a
CompositeProvider to compare actual and plan data in a query.
CompositeProviders are used for the following reasons:
© Copyright. All rights reserved.
112
Lesson: Modeling CompositeProviders
As an interface for BW Queries.
As a Data Mart Layer. Changes to DataStore Objects will not change your reporting if the
CompositeProviders remain unchanged.
Semantic partitioning of Data Marts can be divided into several smaller units which are
integrated by the UNION-capabilities of CompositeProviders. This process brings much
more flexibility to your data model and enables parallel processing for loading and
reporting processes, resulting in performance gains.
Figure 105: CompositeProviders — Union
You have one InfoProvider with the actual data for a logically related business area and one
equivalent InfoProvider with the plan data. To compare the actual data with the planned data
in one query, combine the two InfoProviders into one CompositeProvider.
This is a homogeneous data model. Homogeneous CompositeProviders consist of
InfoProviders that are technically the same. An example of this is an InfoProvider with exactly
the same characteristics and similar key figures. In this case, the InfoProvider with the plan
data contains key figure planned costs and the InfoProvider with the actual data contains key
figure actual costs.
Homogeneous CompositeProviders represent one way to achieve partitioning within
modeling. You can model a sales scenario that is made up of the sub-processes order,
delivery and payment. Each of these sub-processes has its own (private) InfoObjects (delivery
location and invoice number, for example) as well as a number of cross-process objects (such
as customer or order number). You are advised to model each sub-process in its own
InfoProvider and then combine these InfoProviders into a CompositeProvider.
You can model all sub-scenarios in one InfoProvider, or create an InfoProvider for each subscenario, and combine them into a single CompositeProvider.
© Copyright. All rights reserved.
113
Unit 3: Working with Transactional Data in SAP BW/4HANA
The second option usually simplifies the modeling process and can improve system
performance when loading and reading data. There is one DataStore Object for order, delivery
and payment respectively. You can execute individual queries for the individual InfoProvider,
or obtain an overview of the entire process by creating a query based on the
CompositeProvider.
CompositeProviders can serve to collect and join any of the targets into a logical view that can
be collected and used as the provider to queries. They are similar to database views, which
collect various tables for subsequent access by a programmer.
CompositeProviders are optimized for SAP HANA. They run their SQL operations on SAP
HANA rather than on the ABAP application side - the SQL union or join operation has been
pushed down to SAP HANA.
Supported scenarios are as follows:
Left outer joins cannot be created between inner joins.
Left outer joins can only be created at the end of an assignment chain.
A union can only be created at the end of an assignment chain.
Joins cannot be used in a union.
If possible, use an inner join. An inner join is always faster.
In an SAP BW/4HANA environment, it is common practice to combine data coming from
various sources. This combination of data can be done during the staging process. It is
achieved by enriching data and by persistence of the result of the enrichment on database
level (typically a DataStore Object). It can also be achieved by performing a union or join
operation during the run time of the query.
CompositeProviders provide a new kind of joining data, presenting it to the reporting layer. A
CompositeProvider is an InfoProvider, which combines data from SAP HANA views or from
other classic SAP BW/4HANA InfoProviders by join or union. The CompositeProvider then
and makes this data available for reporting and analysis. CompositeProviders can include
SAP HANA views directly. Modeling a CompositeProvider on top of an SAP HANA view
enables you to define SAP BW/4HANA reporting on top of pure SAP HANA objects.
Figure 106: Key Features of CompositeProvider
The role of the CompositeProvider is to provide a metadata object that forms the datamart
layer within SAP BW. It provides the data for reporting and analysis in the form of an
outbound structure that is semantically rich. It abstracts the underlying BW objects and
provides an outbound interface which can be consumed by any kind of query. It does this by
offering the option to generate an SAP HANA view. SAP recommends that you base BEx
© Copyright. All rights reserved.
114
Lesson: Modeling CompositeProviders
reporting on the new CompositeProvider, as this option offers the flexibility to react to
changes in your reporting requirements. The CompositeProvider modeling editor is purely
based on Eclipse and is delivered as part of the SAP BW/4HANA Modeling Tools. These tools
are shipped as an integral part of the SAP HANA Studio. In the Eclipse-based SAP BW/
4HANA Modeling Tools, BW developers can flexibly combine data from multiple BW
InfoProviders and SAP HANA views.
Figure 107: CompositeProvider in SAP HANA Studio (UNION)
You can configure the assignments for the fields on the right of the screen. On the left, you
see the participating providers. To the right of these, the CompositeProvider's fields are
displayed. In the graphical display, you can add the fields to the CompositeProvider. This is
achieved by either using drag and drop, or by choosing Create Assignments in the Context
menu and creating the assignments. If you add an InfoProvider by dragging and dropping it,
the fields and dimensions (groups) of the InfoProvider are applied and any required
dimensions that do not already exist are created.
You can also add complete dimensions by dragging the dimension to a free area or onto the
root node. If you drag a dimension onto another dimension, only the fields are added to the
new dimension. In the case of SAP BW/4HANA InfoProviders, the InfoObjects are added, and
the dimensions are added as groups. If a field does not exist in the target structure, the
system creates it. If navigation attributes have been added to the CompositeProvider, they
are not navigation attributes anymore. If InfoObject names have been assigned to the fields of
the SAP HANA view, these names are used to create an association for the field in the
CompositeProvider for SAP HANA views. When fields are assigned to the CompositeProvider,
the associations are automatically set.
If an SAP HANA view contains input parameters, these are displayed, and you can edit them
like normal fields. You can only assign input parameters to other input parameters. An input
parameter can be compounded either with an InfoObject or with another input parameter.
© Copyright. All rights reserved.
115
Unit 3: Working with Transactional Data in SAP BW/4HANA
Figure 108: CompositeProvider in SAP HANA Studio (JOIN)
In a state-of-the-art data warehouse, there is always a virtualization layer as the interface for
reporting. You should never directly connect queries to objects that contain data, such as
DataStore Objects. In SAP BW/4HANA, the virtualization layer is built from
CompositeProviders. Although CompositeProviders might appear to be complex in their
design, during query run-time they are pruned of all unnecessary elements so reporting
performance is maintained.
Figure 109: Create a Composite Provider (Union) Exercise
© Copyright. All rights reserved.
116
Lesson: Modeling CompositeProviders
LESSON SUMMARY
You should now be able to:
Create a CompositeProvider
© Copyright. All rights reserved.
117
Unit 3
Learning Assessment
1. What are InfoProviders?
Choose the correct answer.
X
A Objects that define the fields used for extraction from a source system
X
B Objects that reports are based on
X
C Objects that stage data during loading
2. Which of the following are examples of key figures?
Choose the correct answers.
X
A Invoiced quantity
X
B Customer number
X
C Vacation days remaining
3. What is a DataStore Object?
Choose the correct answer.
X
A The central object in SAP BW/4HANA used for data storage and consolidation
X
B A virtual staging object used to combine multiple data sources
X
C An object used to store the results of a query to improve performance
4. What can you find in the Operational Delta Queue?
Choose the correct answer.
X
A Data that is waiting to be loaded to SAP BW/4HANA
X
B A list of reports that are scheduled to run offline
X
C A sequence of housekeeping job steps that can be scheduled to ensure that SAP
BW/4HANA operated efficiently
© Copyright. All rights reserved.
118
Unit 3: Learning Assessment
5. What are the features of a DataStore Object of the type standard?
Choose the correct answers.
X
A A change log to manage the delta process
X
B An activation step to control the release of loaded data to reporting users
X
C Support for loading data using APIs
6. What are the modeling features of a CompositeProvider?
Choose the correct answers.
X
A Union
X
B Join
X
C Aggregate
X
D Rank
© Copyright. All rights reserved.
119
Unit 3
Learning Assessment - Answers
1. What are InfoProviders?
Choose the correct answer.
X
A Objects that define the fields used for extraction from a source system
X
B Objects that reports are based on
X
C Objects that stage data during loading
Correct — InfoProviders are objects that reports are based on
2. Which of the following are examples of key figures?
Choose the correct answers.
X
A Invoiced quantity
X
B Customer number
X
C Vacation days remaining
Correct — Examples of key figures are Invoiced quantity and Vacation days remaining
3. What is a DataStore Object?
Choose the correct answer.
X
A The central object in SAP BW/4HANA used for data storage and consolidation
X
B A virtual staging object used to combine multiple data sources
X
C An object used to store the results of a query to improve performance
Correct — A DataStore Object is a central object in SAP BW/4HANA used for data storage
and consolidation
© Copyright. All rights reserved.
120
Unit 3: Learning Assessment - Answers
4. What can you find in the Operational Delta Queue?
Choose the correct answer.
X
A Data that is waiting to be loaded to SAP BW/4HANA
X
B A list of reports that are scheduled to run offline
X
C A sequence of housekeeping job steps that can be scheduled to ensure that SAP
BW/4HANA operated efficiently
Correct — The Operational Delta Queue contains data that is waiting to be loaded to SAP
BW/4HANA
5. What are the features of a DataStore Object of the type standard?
Choose the correct answers.
X
A A change log to manage the delta process
X
B An activation step to control the release of loaded data to reporting users
X
C Support for loading data using APIs
Correct — A DataStore Object of the type standard has a change log to manage the delta
process and also an activation step to control the release of loaded data to reporting users
6. What are the modeling features of a CompositeProvider?
Choose the correct answers.
X
A Union
X
B Join
X
C Aggregate
X
D Rank
Correct — Modeling features of a CompositeProvider include union, join, aggregate.
Ranking is not a modeling feature of a CompositeProvider.
© Copyright. All rights reserved.
121
UNIT 4
Integrating Native SAP
HANA Models with SAP
BW/4HANA
Lesson 1
Exploring the SAP HANA Modeler Perspective
123
Lesson 2
Outlining Data Provisioning in SAP HANA
128
Lesson 3
Introducing SAP HANA Native Modeling
138
Lesson 4
Combining SAP BW/4HANA InfoProviders with SAP HANA Calculation Views
154
UNIT OBJECTIVES
Explore SAP HANA Studio
Describe data provisioning in SAP HANA
Create SAP HANA calculation views with SAP HANA Modeling
Combine SAP BW InfoProvider with SAP HANA views
© Copyright. All rights reserved.
122
Unit 4
Lesson 1
Exploring the SAP HANA Modeler Perspective
LESSON OVERVIEW
This lesson introduces SAP HANA Studio and in particular, the SAP HANA Modeler
perspective that is used to develop calculation views.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Explore SAP HANA Studio
SAP HANA Modeler
The SAP HANA Studio runs on the Eclipse platform and is both a development environment
and administration tool for SAP HANA.
Administrators use the SAP HANA Studio to start and stop services, to monitor the system, to
configure system settings, and to manage users and authorizations. The SAP HANA Studio
accesses the servers of the SAP HANA database by SQL. Developers can use the SAP HANA
Studio to create content such as modeled views and stored procedures. These development
artifacts are stored in the repository, which is part of the SAP HANA database. The SAP HANA
Studio is developed in Java and based on the Eclipse platform.
The SAP HANA Studio presents its various tools in the form of perspectives. Database
administration and monitoring features are available within the SAP HANA Administration
Console perspective. Additional perspectives include the SAP HANA Modeler perspective and
the SAP HANA Development perspective. For more information about these perspectives, see
the SAP HANA Developer Guide (For SAP HANA Studio) and the SAP HANA Modeling Guide
(For SAP HANA Studio).
© Copyright. All rights reserved.
123
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
Figure 110: SAP HANA Studio — HANA Modeler Perspective
The SAP HANA Modeler perspective is used to build analytic models like attribute views,
analytic views, and calculation views. Using this perspective, you can also maintain database
objects like tables, views, sequences, indexes and so on, and administer the real-time
replication using SLT. This is the most frequently used perspective by modelers in SAP HANA.
© Copyright. All rights reserved.
124
Lesson: Exploring the SAP HANA Modeler Perspective
Figure 111: Add System to Logon to the Database
When an SAP BW/4HANA system is running on SAP HANA database, the SAP BW/4HANA
data is stored in a special schema known as the BW-managed schema. In other SAP HANA
schemas, data can be stored in SAP HANA tables or modeling views. You can now make data
available from any SAP HANA database schema in SAP BW. You can also make SAP BW/
4HANA data (data from the SAP BW/4HANA-managed schema in the SAP HANA database)
available in a different SAP HANA schema. You can use virtual access methods and data
replication methods. The following list shows the various options and provides links to further
information:
In the Catalog section of the SAP HANA Modeler perspective, you can access the SAP HANA
schemas and check the views and tables belonging to that schema.
In the Content section of the SAP HANA Modeler perspective, you can define packages to
create your attribute views, analytic views, and calculation views.
In the Provisioning section of the SAP HANA Modeler perspective, you can create objects, for
example virtual tables.
In the Security section of the SAP HANA Modeler perspective, you can maintain users, roles
and privileges.
© Copyright. All rights reserved.
125
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
Figure 112: Attach SAP HANA System to BW Modeling Perspective
In BW metadata objects, you can use SAP HANA views of the SAP HANA database on which
the SAP BW system is running. To enable the consumption of SAP HANA views (analytic or
calculation views) in BW metadata objects, attach the corresponding SAP HANA system to
the BW project.
© Copyright. All rights reserved.
126
Lesson: Exploring the SAP HANA Modeler Perspective
Figure 113: Explore SAP HANA Modeler (Exercise)
LESSON SUMMARY
You should now be able to:
Explore SAP HANA Studio
© Copyright. All rights reserved.
127
Unit 4
Lesson 2
Outlining Data Provisioning in SAP HANA
LESSON OVERVIEW
This lesson introduces data provisioning in SAP HANA.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Describe data provisioning in SAP HANA
Overview of Data Provisioning
A frequently asked question is “What is the best way for SAP HANA to acquire data as there
are so many different options?”. Let's try to differentiate the various options from a technical
point of view.
Figure 114: Positioning of Data Provisioning
Standalone products are as follows:
SAP Data Services
SAP LT Replication Server (SLT)
© Copyright. All rights reserved.
128
Lesson: Outlining Data Provisioning in SAP HANA
Sybase Replication Server (SRS)
Direct Extractor Connection (DXC)
SAP Process Orchestration/Integration (SAP PI, SAP XI)
SAP BW/4HANA
SAP HANA options are as follows:
SAP HANA Smart Data Access (SDA)
SAP HANA Smart Data Integration (SDI)
SAP HANA Smart Data Streaming (SDS)
Figure 115: SAP BW/4HANA Source Systems
The first and most important point to consider here is: How can I get data into SAP HANA?
If SAP HANA is just one of many sources and targets, or if SAP HANA is not used at all, then
the standalone products do make more sense. Another view is that there are many different
options because of the non-SAP HANA scenarios. These solutions can load everything except
SAP HANA, which sometimes creates confusion.
For example: My task is to integrate various systems, and to load them into Teradata, Oracle,
and SAP BW/4HANA. The sources are an SAP ERP system, 5 Oracle databases, flat files of
various formats, and an SQL server, so SAP HANA has barely any role in it. This sounds like a
perfect SAP Data Services scenario; many sources, many targets and data services in the
middle. SAP HANA is the sole target. A few years ago, if a customer wanted to load, for
example, flat files into SAP HANA, they had to install SAP Data Services (a full blown ETL tool)
just to load a few files from Mainframe (Cobol Copybook), CSV files with a non-default format,
and other sources. Only SAP Data Services, as an ETL tool, provides reading capabilities of
© Copyright. All rights reserved.
129
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
essentially every source system. SAP Data Services allows the data to be transformed easily
so it can be loaded into the target structures. An installation of a full blown ETL tool just for
that!
If real-time is also required, you must install SLT or SRS. If the source data is merely to be
made available, and not copied – the federated or virtual data model use case – configure
SDA as well. In this example, (SQL server database as the source), three products are
needed. All three products have their own installation, their own connector to the source,
different look and feel, and different capabilities.
Customer wants to perform SAP Data Services like transformations in Realtime — not
possible.
Customer wants to perform SAP Data Services like transformations in a CalcView for
virtual data models — not possible.
Customer wants to try out one style, for example, a virtual data mode, switch to batch data
integration for performance reasons, and to real-time data integration for accuracy — no
way.
Customer wants to administer, maintain, and monitor all from SAP HANA — no chance.
Customer wants to read from something less common, MySQL, for example — only SAP
Data Services has that option.
Enterprise Information Management (EIM)
EIM enhances, cleanses, and transforms data to make it more accurate and useful. With the
speed advantage of SAP HANA, the new SAP HANA EIM option can connect with any source,
provision, cleanse, and load data into SAP HANA on-premise or in the cloud. For supported
systems, the new EIM can write back to the original source.
SAP HANA EIM offers the following capabilities:
A simplified landscape; one environment in which to provision and consume data.
Access to more data formats, including an open framework for new data sources.
In-memory performance, which means increased speed and decreased latency.
Take the best concepts of all the products, merge them with existing SAP HANA features, and
you can develop the most powerful and easy to use product from the ground up. SDI does not
reuse any code from the old products. Essentially, SDI is an extension of SDA, which it
enhances using Adapters.
Adapters have the following advantages:
They run outside of the SAP HANA kernel, they are not a stability threat for SAP HANA.
An Adapter SDK writes new adapters easily. SDI provides adapters for the addition of one
exceptional source. They can write a new adapter for that source within hours/days.
They support on premise and cloud deployments – an SAP HANA cloud can read on
premise data as if it was local.
Realtime Push
Adapters support, select and insert or update or delete data. They also support the real
time pushing of change data.
Transformations
All SAP Data Services and SAP HANA transformations are available in SAP HANA.
UIs
© Copyright. All rights reserved.
130
Lesson: Outlining Data Provisioning in SAP HANA
An SAP Data Services-like UI for the assembly of data flows and the configuration of the
individual transforms.
Supports batch reading, real time transformations and virtual data models.
SAP HANA cockpit for monitoring and administration.
It would make sense to use SLT and its trigger based real-time approach to get the changes
from ABAP tables. What is the best method for loading SAP HANA? Since the goal of SDI is to
provide a one-stop solution for all data integration problems with SAP HANA, the correct
answer should be SDI and only SDI.
Supports batch, real-time and virtual access.
Fully integrated with SAP HANA development UIs.
Integrated with SAP HANA Monitoring Cockpit.
Allows virtual table access (SDA) to its sources.
Provides access to a large number of different sources, databases, SAP systems,
applications, cloud apps, internet sources.
Supports cloud and on premise deployment options without any compromise.
Supports real-time transformations.
Simplifies delta loads thanks to the real time push of change data.
Allows complex transformations to be performed easily (SAP Data Services-like).
Keep in mind, there are certain features missing as of today (SPS11), for example, Workflows.
Addressing this situation is a high priority. The product was first delivered with SAP HANA
SPS09 , which is relatively young compared to all others. Again, however, SDI is the supposed
optimal solution only because we have limited the focus to loading into SAP HANA. There are
more than enough use cases, even in the SAP HANA world, where other tools have the edge.
SAP HANA consists of two main areas, smart data integration and smart data quality as
described in the following table.
Table 1: Enterprise Information Management
Feature area
Description
Smart data integration
Real-time, high-speed data provisioning, bulk data movement, and
federation. SAP HANA EIM provides built-in adapters and an SDK
so you can build your own. Smart data integration includes the following features and tools:
Replication Editor in the SAP HANA Web-based Development
Workbench, which lets you set up batch or real-time data replication scenarios in an easy-to-use web application
Smart data integration transformations, exposed as new nodes
in the application function modeler delivered with SAP HANA
studio and SAP HANA Web-based Development Workbench,
© Copyright. All rights reserved.
131
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
Feature area
Description
which lets you set up batch or real-time data transformation
scenarios
Data provisioning agent, a lightweight component that hosts data provisioning adapters, which enables data federation, replication and transformation scenarios for on-premise or in-cloud deployments
Data provisioning adapters for connectivity to remote sources
Adapter SDK to create custom adapters
SAP HANA Cockpit integration for monitoring Data Provisioning
agents, remote subscriptions and data loads
Smart data quality
Real-time, high-speed data cleansing, address cleansing, and geospatial data enrichment. SAP HANA EIM provides an intuitive interface to define data transformation flow graphs in SAP HANA Webbased Development Workbench and SAP HANA studio. Smart data
quality includes application function modeler nodes to perform data quality tasks, such as address cleansing, data cleansing, and geocoding.
SAP HANA Smart Data Access
SAP HANA smart data access allows you to access remote data as if the data was stored in
local tables in SAP HANA, without copying the data into SAP HANA.
Not only does this capability provide operational and cost benefits, but most importantly it
supports the development and deployment of next-generation analytical applications. These
applications require the ability to access, synthesize, and integrate data from multiple
systems in real-time, regardless of where the data is located or what systems are generating
it.
Specifically, in SAP HANA, you can create virtual tables that point to remote tables in different
data sources. Customers can then write SQL queries in SAP HANA, which could operate on
virtual tables. The SAP HANA query processor optimizes these queries, and executes the
relevant part of the query in the target database, returns the results of the query to SAP
HANA, and completes the operation.
The following remote data sources are supported:
SAP HANA
SAP IQ
SAP Adaptive Service Enterprise
SAP Event Stream Processor (supported on Intel-based hardware platforms only)
SAP MaxDB (supported on Intel-based hardware platforms only)
Hortonworks Distribution for Apache Hadoop: version 2.3 (This includes Apache Hadoop
version 1.0.3 and Apache Hive 0.9.0.) (supported on Intel-based hardware platforms only)
Teradata Database (supported on Intel-based hardware platforms only)
© Copyright. All rights reserved.
132
Lesson: Outlining Data Provisioning in SAP HANA
Microsoft SQL Server 2012 (supported on Intel-based hardware platforms only)
Oracle Database 12C
IBM DB2 (supported on Intel-based hardware platforms only)
IBM Netezza Appliance (supported on Intel-based hardware platforms only)
Apache Spark (supported on Intel-based hardware platforms only)
SAP HANA Smart Data Streaming
SAP HANA smart data streaming is a specialized option that processes streams of incoming
event data in real time, and collects and acts on incoming information. SAP HANA smart data
streaming is suited to situations where data arrives as events happen, and where there is
value in collecting, understanding, and acting on this data right away.
The following list gives examples of data sources that produce streams of events in real time:
Sensors
Smart devices
Web sites (click streams)
IT systems (logs)
Financial markets (prices)
Social media
Data flows into streaming projects from various sources, typically through adapters, which
connect the sources to the smart data streaming server. The streaming projects contain
business logic, which they apply to the incoming data, typically in the form of continuous
queries and rules. These streaming projects are event-driven, turning the raw input streams
into one or more derived streams that can be captured in the SAP HANA database, sent as
alerts, posted to downstream applications, or streamed to live dashboards.
© Copyright. All rights reserved.
133
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
Figure 116: Positioning and Key Benefits of SAP LT Replication Server (SLT)
Figure 117: Comparison of Data Provisioning Options
SAP Replication Server
Move and synchronize data across your enterprise in real time with SAP Replication Server.
This proven data replication software can help you satisfy a host of mission-critical needs –
from application high availability and disaster recovery, to seamless, lightning-fast data
distribution, to smart decision making based on up-to-the-second information.
SAP HANA Direct Extractor Connection (DXC)
The SAP HANA Direct Extractor Connection (DXC) provides SAP HANA with out-of-the-box
foundational data models based on SAP Business Suite entities, and is also a data acquisition
method. Customer projects may face significant complexity in modeling entities in SAP
Business Suite systems. In many cases, data from different areas in SAP Business Suite
systems requires application logic to appropriately represent the state of business
documents. SAP Business Content DataSource Extractors have been available for many
© Copyright. All rights reserved.
134
Lesson: Outlining Data Provisioning in SAP HANA
years as a basis for data modeling and data acquisition for SAP Business Warehouse; now
with DXC, these SAP Business Content DataSource Extractors are available to deliver data
directly to SAP SAP HANA.
DXC is a batch-driven data acquisition technique; it should be considered as a form of
extraction, transformation, and load, although its transformation capabilities are limited to
user exit for extraction. A key point about DXC is that in many use cases, batch-driven data
acquisition at certain intervals is sufficient (for example, every 15 minutes).
SAP Data Services
SAP Data Services and SAP Information Steward are part of the Enterprise Information
Management suite of products that target the Information Management personas: the
administrator, the designer, and the subject matter experts in charge of data stewardship and
data governance.
SAP Data Services delivers a single enterprise-class solution for data integration, data quality,
data profiling, and text data processing. The following list gives the advantages of SAP Data
Services:
It allows you to integrate, transform, improve, and deliver trusted data to critical business
processes.
It provides development user interfaces, a metadata repository, a data connectivity layer,
a run-time environment, and a management console; enabling IT organizations to lower
total cost of ownership and accelerate time to value.
It enables IT organizations to maximize operational efficiency with a single solution to
improve data quality and gain access to heterogeneous sources and applications.
SAP Information Steward provides business analysts, data stewards, and IT users with a
single environment to discover, assess, define, monitor, and improve the quality of their
enterprise data assets through the following modules:
Data Insight
Profile data, create and run validation rules, monitor data quality through scorecards, and
create data cleansing solutions based on your data's content-type identification results
and SAP best practices for your specific data.
Metadata Management
Catalog the metadata across their system landscape, analyze, and understand the
relationships of their enterprise data.
Metapedia
Define business terms for data and organize the terms into categories.
Cleansing Package Builder
Define cleansing packages to parse and standardize data.
Match Review
Review results of automated matching on a regular basis and make any necessary
corrections. Match Review maintains a list of records in the My Worklist tab that involves
reviewers' actions for match decisions.
Files can be imported into the Workbench in the following ways:
Dragging and dropping from the file system
© Copyright. All rights reserved.
135
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
Copying and pasting from the file system
Using the import wizard
To import files, drag and drop, or copy and paste. However, this feature depends on the
platform you are using. If your platform does not support these import methods, you can use
the import wizard.
Figure 118: Import Flat File 1 as an Example
© Copyright. All rights reserved.
136
Lesson: Outlining Data Provisioning in SAP HANA
Figure 119: Import Flat File Example 2
LESSON SUMMARY
You should now be able to:
Describe data provisioning in SAP HANA
© Copyright. All rights reserved.
137
Unit 4
Lesson 3
Introducing SAP HANA Native Modeling
LESSON OVERVIEW
This lesson shows how to create SAP HANA calculation views using SAP HANA modeling. This
lesson explains the advantages of calculation views.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Create SAP HANA calculation views with SAP HANA Modeling
SAP HANA Modeling
Figure 120: SAP HANA Data Warehousing
With the modeling functions that are available in SAP BW and SAP HANA, mixed modeling
makes it possible to access SAP BW data from any schema in the SAP HANA database and to
access data from any schema in the SAP HANA database from SAP BW. You can create
scenarios where data, which is modeled in the SAP BW system, is merged with data modeled
in SAP HANA with SAP HANA tools.
When an SAP BW system is running on SAP HANA database, the SAP BW data is stored in a
special schema known as the BW-managed schema. In other SAP HANA schemas, data can
be stored in SAP HANA tables or views. On the one hand, you can access data from SAP BW
to data from any schema in the SAP HANA database. On the other hand, you can access (data
from the schema managed by SAP BW in the SAP HANA database) in another SAP HANA
schema. You can use virtual access methods and data replication methods.
© Copyright. All rights reserved.
138
Lesson: Introducing SAP HANA Native Modeling
Figure 121: SAP BW Powered by SAP HANA: Mixed Scenarios
The following list gives the reasons to combine data from SAP BW data warehouse with data
in SAP HANA that is usually replicated in real time:
To combine historical information, such as trending, with real-time status information that
exists in SAP HANA.
To integrate SAP data in SAP BW with non-SAP data that you have in SAP HANA.
To import SAP BW data models into SAP HANA scenario was developed to address the
Explorer use case. Explorer cannot access SAP BW providers directly and therefore you
need to import these models into SAP HANA and expose its data in Explorer on top of SAP
HANA.
You can create SAP HANA views for SAP BW objects in the following two ways: From the SAP
BW system or from SAP HANA Modeler. Although they present a number of differences, both
approaches can be recommended in equal measure.
You are recommended to generate SAP HANA views from the SAP BW system in the
following situations:
If you mainly use the SAP BW Enterprise Data Warehouse layer and plan to execute
queries directly on the data models, without OLAP functions.
If you want the SAP HANA view to be adjusted automatically when changes are made in
SAP BW
If you want the SAP HANA view to be part of the SAP BW transport system
If you want SAP HANA users to be automatically assigned SAP HANA privileges
If you want CompositeProviders or queries to be used for SAP HANA views
If you want to access the near-line storage or use non-cumulative key figures
However, importing SAP BW objects from the SAP HANA Modeler is recommended in the
following situations:
© Copyright. All rights reserved.
139
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
If you mainly use SAP HANA Modeler and your own ETL tools
If the content package can be individually configured for each object
If you want to keep changes made to the generated SAP HANA view after a re-import
The modeling tools for SAP BW powered by SAP HANA (in short BW Modeling Tools)
represent a new modeling IDE (Integrated Development Environment), which is built on top of
the Eclipse platform.
Their main objective is to support BW model developers working in the increasingly complex
BI environments by providing them with state-of-the-art modeling tools. These tools include
integration with SAP HANA modeling and consumption of SAP HANA elements in BW Open
ODS Views or CompositeProviders, with powerful UI (user interface) capabilities.
Note:
Read note 1954169 first and follow the client installation instructions as described
in that note.
SAP First Guidance - Implementing BW-MT for BW-aDSO
https://scn.sap.com/docs/DOC-60425
Figure 122: Native Modeling in SAP HANA Calculation Views
Calculation Views
A calculation view is used to define more advanced slices on the data in the SAP HANA
database. Calculation views can be simple and mirror the functionality found in both attribute
views and analytic views. However, they are typically used when the business use case
requires advanced logic that is not covered in the previous types of information views.
Calculation views can have layers of calculation logic, can include measures sourced from
multiple source tables, can include advanced SQL logic, and so on. The data foundation of the
© Copyright. All rights reserved.
140
Lesson: Introducing SAP HANA Native Modeling
calculation view can include any combination of tables, column views, attribute views, and
analytic views. You can create joins, unions, projections, and aggregation levels on the
sources.
You can model the following elements within a calculation view:
Attributes
Measures
Calculated Columns
Counters
Hierarchies (created outside of the attribute view)
Variables
Input parameters
Calculation views can include measures and be used for multidimensional reporting, or can
contain no measures and used for list-type of reporting. Calculation views can either be
created using a graphical editor or using SQL script. These options provide maximum
flexibility for the most complex and comprehensive business requirements.
You can choose to further fine-tune the behavior of the attributes and measures of a
calculation view by setting the properties in the following ways:
Apply filters to restrict values that are selected when using the calculation view.
Define attributes and measures as Hidden so that they can be used in calculated columns,
but are not visible to end users.
Set the Drill Down Enabled property to indicate if an attribute is available for further drill
down when consumed.
Set Aggregation type on measures.
Associate a measure with the currency and unit of measure using the
property.
© Copyright. All rights reserved.
Measure Type
141
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
Figure 123: Join Types
Referential Join
A referential join is semantically an inner join that assumes that referential integrity is given,
which means that the left table always has a corresponding entry on the right table. It can be
seen as an optimized or faster inner join, where the right table is not checked if no field from
the right table is requested. That means that only the referential joins will be executed when
fields from both tables are requested. Therefore, if a field is selected from the right table, it
will act in a similar manner to an inner join, and if no fields from the right table is selected, it
will act in a similar manner to a left outer join. From a performance perspective, the left outer
is almost as fast as the referential join, while the inner join is usually slower due to the fact that
the join is always executed.
Referential joins must be used with caution since it assumes that referential integrity is
ensured.
The following list gives the only valid scenario for the referential join:
It is guaranteed that for each row in one table, there is at least one join partner in the other
table.
The joins are ensured in both directions.
Integrity is kept at all times. If that is not the case, then referential joins have the possibility
to give incorrect calculations if the referential integrity is not met – meaning if a delivery
header is created but the items is not processed until a later stage, then any calculations
that use referential joins will be incorrect.
Inner Join and Outer Join
The data that can be selected with a view depends primarily on whether the view implements
an inner join or an outer join. With an inner join, you only get the records of the cross-product
for which there is an entry in all tables used in the view. With an outer join, records are also
selected for which there is no entry in some of the tables used in the view. The set of hits
determined by an inner join can therefore be a subset of the hits determined with an outer
join.
© Copyright. All rights reserved.
142
Lesson: Introducing SAP HANA Native Modeling
Database views implement an inner join. The database therefore only provides those records
for which there is an entry in all the tables used in the view. Help views and maintenance
views, however, implement an outer join. The left outer join selects the complete set of
records from the first table, with the matching records (where available) in the second table. If
there is no match, the right side will contain null. The right outer join selects the complete set
of records from the second table, with the matching records (where available) in the first
table. If there is no match, the left side will contain null.
Text Join
Text join is used in order to get language-specific data. You have a product table that contains
product IDs without descriptions and you have a text table for products that contains
language-specific descriptions for each product. You can create a text join between the two
tables to get the language-specific details. In a text join, the right table should be the text table
and it is mandatory to specify the Language column.
Note:
You can also use LEFT OUTER JOIN for the TEXT description in cases where the
text is not language dependent. In such cases where you do not have a language
column, you cannot use the TEXT join.
Star Joins
Star joins in calculation views help you to join a fact table with dimensional data. The fact table
contains data that represents business facts such price, discount values, and number of units
sold. Dimension tables represent different ways to organize data, such as geography, time
intervals, and contact names.
Figure 124: Examples Of SQL Join Operations
Inner join
Returns all rows when there is at least one match in BOTH tables.
Left outer join
Return all rows from the left table, and the matched rows from the right table.
© Copyright. All rights reserved.
143
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
Right outer join
Return all rows from the right table, and the matched rows from the left table.
Full outer join
Return all rows when there is a match in ONE of the tables in rows from two or more tables,
based on a common field between them.
The union operator is used to combine the result-set of two or more
SELECTstatements.
Figure 125: Attribute View: Text Join
A text join on the COUNTRY.KEY and COUNTRY_TEXT.KEYcolumns with LANG in the
Language column will perform according to the user’s session language, and retrieves the
country description in the corresponding language.
_SYS_BIC:
This schema contains all the column views of activated objects. When the user activates the
Attribute View/Analytic View/Calculation View/Analytic Privilege /Procedure
, the respective
run-time objects are created under _SYS_BIC/ Column Views.
_SYS_REPO:
Whatever objects are in the system are also available in the repository. This schema contains
the list of Activated objects, Inactive Objects, Package details and Runtime Objects
information. Also the _SYS_REPOuser must have the SELECTprivilege with grant option on
the data schema.
_SYS_BI:
This schema stores all the metadata of created column Views. It contains the tables for
created Variables, Time Data (Fiscal, Gregorian), Schema Mapping, and Content Mapping
tables.
_SYS_STATISTICS:
This schema contains all the system configurations and parameters.
_SYS_XS:
© Copyright. All rights reserved.
144
Lesson: Introducing SAP HANA Native Modeling
This schema is used for SAP HANA Extended Application Services.
Figure 126: Build and Consume Content for SAP HANA
Figure 127: Calculation View (Graphical) View Creation Wizard
A calculation view is a powerful and flexible information view, which you can use to define
more advanced slices of the data available in the SAP HANA database. Calculation views are
simple, and mirror the functions found in both attribute views and analytic views and much
more.
© Copyright. All rights reserved.
145
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
However, you use calculation views when your business use case requires advanced logic,
which you cannot achieve by creating the previous analytic views or attribute views. For
example, you can create calculation views with layers of calculation logic, which includes
measures sourced from multiple source tables, or advanced SQL logic. The data foundation
of the calculation view can include any combination of tables, column views, attribute views,
and analytic views. You can create joins, unions, projections, and aggregation levels on data
sources.
Calculation views can include measures and be used for multidimensional reporting or can
contain no measures and used for list-type reporting.
You can create a calculation view to depict a complex business scenario that has layers of
calculation logic and include measures sourced from multiple source tables using the
graphical modeling features of the SAP HANA Modeler.
You can set the calculation view Data Category to Cube or Dimension property based on the
following requirements:
Cube
Use if you want to define a calculation view that is visible in the reporting tools. You must
define at least one measure and the default node is Aggregation or Star Join (based on
your selection in the creation wizard). The Star Join node provides the platform to join the
descriptive data, that is, dimensions from the calculation views of the type dimension with
the fact data from the lower nodes. This way, you are logically creating a star schema
where the join is created from the central entity to the other entities. You can, however,
create a snowflake schema by joining views to the central entity. In a Star Join, having
calculation views with the data category as dimension are treated as shared dimensions.
All the attributes and hierarchies of these shared dimensions are added to the output of
the calculation view. During deployment, the Star Join is always deployed with an
aggregation node on top of it. The Star Join is deployed first with a series of joins and then
the aggregation logic is deployed.
Dimension
Use if you want to define a simple SQL like calculation view, which, for example, is used to
fill simple list user interfaces where recurring attribute values are not a problem, but are
desired. To define this type of view, you do not define any measure. If you do define a view
like this, its behavior is as follows:
-
The output node does not offer any measures (or hierarchies), only attributes, which
can be numerical data types
-
The calculation view is not available for reporting
-
The calculation view is only consumable via SQL
-
The default node is Projection
© Copyright. All rights reserved.
146
Lesson: Introducing SAP HANA Native Modeling
Figure 128: Calculation View (Graphical) Output Node
Attributes contain a subset of columns that can be used as conditions, actions, and in
calculated attributes. To delete attributes from the
Attributes node, choose Remove from the
context menu of the Output pane. However, you cannot delete the attributes that are already
used as actions or conditions.
You can also check object references for elements in the Output pane. Select an object, and
choose References from the Context menu. In the Details pane, you can select an element
from the Parameters , Variables or Columns tab.
Figure 129: Calculation View (Graphical) Calculated Column
Create Calculated Columns
Create new output columns and calculate its values at run time based on the result of an
expression. You can use other column values, functions, input parameters, or constants in the
expression.
© Copyright. All rights reserved.
147
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
Context
For example, you can create a calculated column DISCOUNT using the expression
if("PRODUCT" = 'NOTEBOOK', "DISCOUNT" * 0.10, "DISCOUNT")
. In this sample
expression, you use the if() function, the PRODUCTcolumn and the * operator to obtain
values for the DISCOUNT calculated column.
Note:
If you want to create a calculated measure and enable client side aggregation for
the calculated measure, select the Enable client side aggregation checkbox. This
allows you to propose the aggregation that client needs to perform on calculated
measures.
You can also create an expression by dragging and dropping the expression
elements, operators and functions from the menus to the expression editor. For
expression in SQL language, the modeler supports only a limited list of SQL
functions.
Calculated Column Properties
After creating a calculated attribute or a calculated measure, you can view its properties or
change them based on your business requirements. Select a calculated column in the
Semantics node. Modeler displays the following properties for calculated columns in the
Properties pane.
Data Type
The value of this property specifies the data type of the calculated attributes or calculated
measures.
Semantic Type
The value of this property specifies the semantics assigned to the calculated attributes or
calculated measures.
Hidden
The value of this property determines whether the calculated column is hidden in reporting
tools.
Drill Down Enablement
The value of this property determines whether the calculated attribute is enabled for drill
down in reporting tools. If it is enabled, the value of this property specifies the drill down type.
Display Folder
If the calculated measure is grouped in any of the display folders, the value of this property
specifies the display folder that was used to group related measures.
© Copyright. All rights reserved.
148
Lesson: Introducing SAP HANA Native Modeling
Figure 130: Calculation View (Graphical) Union Mapping
A union node combines multiple data sources, which can have multiple columns. You can
manage the output of a union node by mapping the source columns to the output columns, or
by creating a target output column with constant values.
For a source column that does not have a mapping with any of the output columns, you can
create a target output column and map it to the unmapped source columns. You can also
create a target column with constant values.
Figure 131: Calculation View (Graphical) Semantics Node
The Scenario pane of the editor consists of the following default nodes:
© Copyright. All rights reserved.
149
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
Aggregation / Projection node
This node is based on Data Category value that you choose. If the value is set to Cube, the
default node is an aggregation node. If the property is set to Dimension , the default node is
a projection node. If you are creating graphical calculation view with star join, then the
default node is the Star Join node.
Semantics
This node represents the output structure of the view.
The Details pane consists of the following tabs:
View Properties
This tab displays basic view properties.
Column
This tab contains analytic view local columns that you can define as attributes and
measures. If you are using a star join node, then the Column tab also contains the shared
columns from the underlying views.
Hierarchies
This tab contains the hierarchies from the underlying dimension calculation views and the
hierarchies defined on the calculation view.
Parameters/Variables
This tab contains variables and input parameters, which you use to filter attribute data
based values you provide at runtime or parameterize information views respectively.
Note:
If you are using any attribute view as a data source to model the calculation view,
the Shared section displays attributes from the attribute views that are used in the
calculation view.
The data foundation of the calculation view can include any combination of tables, column
views, attribute views, and analytic views. You can create the following: joins, unions,
projections, and aggregation levels on data sources.
Union: Use the union node to combine the result set of two or more data sources. Union
nodes have two or more inputs. For example, for retrieving the names of all employees of a
store which has different branches, and each branch maintains its own employee records
table.
Join: Use the join node to query data from two or more data sources, based on a specified
condition. Join nodes have two inputs. For example, for retrieving customer details and
location based on the postal code column present in the two tables CUSTOMER and
GEOGRAPHY. The CUSTOMER table has the columns – Customer_ID, Customer_Name ,
Postal_Code, and the GEOGRAPHYtable has the columns – Postal_Code, Region, Country .
Projection: Use the projection node to filter or obtain a subset of required columns of a
table or an information view. Projection nodes have one input. For example, for selecting
the employee name and employee department from a table consisting of many other
columns.
© Copyright. All rights reserved.
150
Lesson: Introducing SAP HANA Native Modeling
Aggregation: Use the aggregation node to summarize data for a group of row values, by
calculating values in a column. Aggregation nodes have one input. For example, for
retrieving total sales of a product in a month. The supported aggregation types are sum,
min, and max.
Rank: Use the rank node to partition the data for a set of partition columns, and perform an
order by operation on the partitioned data. Rank nodes have one input. For example,
consider a TRANSACTION table with two columns, PRODUCTand SALES. If you want to
retrieve the top five products based on its sales, then use a rank node.
Star Joins: Star joins in calculation views help you to join a fact table with dimensional data.
The fact table contains data that represent business facts such price, discount values,
number of units sold, and so on. Dimension tables represent different ways to organize
data, such as geography, time intervals, and contact names.
For the Aggregation node, at run time, the measures are automatically aggregated on the level
defined by the group, by clause. In this case, the output node is deployed as an aggregation
node into the run time model that is created during deployment. Moreover, the model
information is written into the BI metadata consumption tables that is made available to the
BI clients of SAP HANA for reporting.
Note:
If the default node is Aggregation and the Always Aggregate Result property of the
Semantics node is set to True , then the output of measures always appears
aggregated.
Figure 132: Calculation View (Graphical) Build up Data Flow
A calculation view has the following features:
The input for union, join, projection, and aggregation view nodes can consist of data
sources, union, join, projection, or aggregation view nodes.
© Copyright. All rights reserved.
151
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
You can only have one source of input for aggregation and projection view nodes, and two
inputs for a join.
You can add the view nodes even between the two joined view nodes. If you drop a view
node from the Tools Palette to a data source (that is, tables, attribute views, analytic views,
and calculation views) of a view node, the data source is replaced by the newly added view
node such that, the new view node has the data source as its input. For example, if you
drop a Projection view node on the DS1 data source of the existing Aggregation view node,
the Aggregation view node would now have Projection view node as its data source and
DS1 would be the data source of the Projection node.
For join nodes (including star join node), in the property panel, the property Optimize Join
Columns is set to False by default. This property forces a query to retrieve the join columns
from the database although it is not requested in the query. In other words, you are
including those columns in the join, into the group by clause, even if you do not select them
in the query. You can set the join property Optimize Join Columns to True to optimize the
join execution (for example, if your join node includes many join attributes). By setting the
property to True , you can avoid retrieving the join columns that are not specified in the
query. However, the join optimizer cannot remove the attributes, which are used by static
filters if these filters are defined on join columns that have the property Optimize Join
Column set to True .
For an active calculation view, you can preview output data of an intermediate node. This
helps to debug each level of a complex calculation scenarios (having join, union, aggregation,
projection, and output nodes). Choose the Data Preview option from the context menu of a
node. When you preview the data of an intermediate now, SAP HANA Studio activates the
intermediate calculation model with the current user instead of the _SYS_REPOuser. The
data you preview for a node is for the active version of the calculation view. If no active version
for the object exists then you need to activate the object first. Projection between the join and
the initial input node (with filter). Optimizing join columns is supported only for left outer join
or text join (with cardinality 1:1 or N:1) and right outer join (with cardinality 1:1 or 1:N)
© Copyright. All rights reserved.
152
Lesson: Introducing SAP HANA Native Modeling
Figure 133: Create Calculation Views with Star Join Exercise
LESSON SUMMARY
You should now be able to:
Create SAP HANA calculation views with SAP HANA Modeling
© Copyright. All rights reserved.
153
Unit 4
Lesson 4
Combining SAP BW/4HANA InfoProviders
with SAP HANA Calculation Views
LESSON OVERVIEW
This lesson shows how to combine an SAP BW/4HANA InfoProvider with SAP HANA
calculation views.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Combine SAP BW InfoProvider with SAP HANA views
CompositeProvider with SAP HANA View
Figure 134: CompositeProvider with SAP HANA Views
In a CompositeProvider, you can merge data from SAP BW/4HANA InfoProviders with data
from SAP HANA views using union and join, or just merge data from SAP BW/4HANA
InfoProviders and SAP HANA views.
In the Eclipse-based SAP BW/4HANA Modeling Tools, SAP BW/4HANA developers can
combine data flexibly from multiple InfoProvider and SAP HANA views. CompositeProvider
will be the central provider that forms the virtual data mart layer and provides the reporting
© Copyright. All rights reserved.
154
Lesson: Combining SAP BW/4HANA InfoProviders with SAP HANA Calculation Views
and analysis data when using an SAP HANA database. It replaces the as required
CompositeProvider if you are using SAP HANA. The To Create a CompositeProvider
procedure shows you how to create a CompositeProvider.
Figure 135: DWH Modeling Approach Function and Integration
In SAP BW/4HANA, you have to model in stacks. First you model the integration stack and
then the functional stack. You can see it on the left hand side of the figure DWH Modeling
Approach Function and Integration. On the right hand side of the figure, we see the immediate
model – Function before Integration (Field level approach). Here the approach is to define a
minimal amount of meaning to the data so you can immediately execute the query without
creating InfoObjects, Transformations. SAP BW/4HANA without SAP HANA is a powerful
integration framework by itself. You work with SAP BW/4HANA orientated stacks –
Integration and Function modeling, and these are normally based on InfoObjects. If you have
no InfoObjects you cannot model data.
In SAP BW/4HANA, there are two types of modeling side by side. So you can model the
standard way with InfoObjects, and you can model based on fields.
The functions that have been developed for SAP BW 7.5 are powered on SAP HANA and are
created from an architectural point of view, and not from a technological point of view.
Function modeling is possible now without losing all integration aspects.
SAP HANA can work on data like it is - without transforming the data into specific analytic
structures, you can work with virtual objects directly on any field level data. Bringing the
source systems closer to SAP BW/4HANA means that we need to have something
intermediate between the source and the fully fledged and top down modeled EDW described
by InfoObjects. This is achieved in the Open ODS Layer.
© Copyright. All rights reserved.
155
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
Figure 136: SAP HANA BW Open Service Framework
SAP BW/4HANA on SAP HANA and Logical Data Warehousing
We have made the solution portfolio of a Data Warehouse more flexible, so that remote data
can also become components of a Data Warehouse-based solution. This requires that SAP
BW/4HANA is able to interpret such remote data and assign meaning to it. Since all data
outside of SAP BW/4HANA is defined in the shape of fields, the key prerequisite for a virtual
integration of such data lies in field-based modeling on the basis of Open ODS views.
New Openness of SAP BW/4HANA
We have all had the experience of integrating non-SAP raw data in SAP BW/4HANA. You had
to assign and define InfoObjects to the raw data fields. This is no longer a prerequisite for data
integration into SAP BW/4HANA, as SAP BW on SAP HANA 7.40 comes with field-based
modeling. Field-based modeling means that you can integrate data into SAP BW/4HANA with
considerably lower effort than before. Whether data is loaded into SAP BW/4HANA or resides
outside it, you can model and operate on field level data without the need of defining
InfoObjects in advance, and subsequently mapping the fields to the InfoObjects. This makes
the integration of any data much easier. How is this achieved? The new Advanced DSOs allow
storing field-level data in SAP BW/4HANA. Advanced DSOs can only have fields: a mixture
with InfoObjects or just InfoObjects, like the old DSOs. Define the SAP BW on SAP HANA
Open ODS views to model reusable SAP BW-based semantics identifying facts, master data,
and semantics of fields like currency fields or text fields. In addition, Open ODS views can
define associations between Open ODS views and InfoObjects, which means you can model
virtual star schemas. Lastly, you can use Open ODS views in a query or combined with other
Providers in a CompositeProvider like any InfoProvider. SAP BW on SAP HANA is able to
model and work on raw data regardless of where they are located and we can integrate raw
data with the harmonized InfoObject-world by associating InfoObjects in Open ODS views to
fields.
© Copyright. All rights reserved.
156
Lesson: Combining SAP BW/4HANA InfoProviders with SAP HANA Calculation Views
The concept of working with raw data in SAP BW/4HANA, and the early and easy integration
of raw data, results in the new Open ODS layer, bringing SAP BW/4HANA and the sources
closer together.
Figure 137: Enhance CompositeProvider with SAP HANA View Exercise
To Create a CompositeProvider
Create the CompositeProvider. You are in the BW Modeling Tools. This procedure shows you
how to use a wizard to create a CompositeProvider.
1. Define the properties for the CompositeProvider's run time.
2. Generate an SAP HANA view from the CompositeProvider.
3. Set the This CompositeProvider can be added to another CompositeProvider flag, to use
the CompositeProvider as a provider in another CompositeProvider.
4. Under Common Runtime Properties , you can configure various settings at query run time.
Runtime Profile Properties contains the settings for processing the CompositeProvider.
In most cases you do not need to change these settings. These are expert settings and
can be changed later on, if required.
5. Select other participating InfoProviders or SAP HANA views and make assignments.
6. Define the appearance of the CompositeProvider in the query.
7. Activate the CompositeProvider.
© Copyright. All rights reserved.
157
Unit 4: Integrating Native SAP HANA Models with SAP BW/4HANA
LESSON SUMMARY
You should now be able to:
Combine SAP BW InfoProvider with SAP HANA views
© Copyright. All rights reserved.
158
Unit 4
Learning Assessment
1. What can I do with the SAP HANA Modeler Perspective?
Choose the correct answers.
X
A Create CompositeProviders
X
B View database tables
X
C Create calculation views
X
D Execute DTPs
2. Smart Data Access (SDA) supports the extraction, cleansing, and loading of data from
remote source to SAP HANA.
Determine whether this statement is true or false.
X
True
X
False
3. Which is the central modeling object of SAP HANA?
Choose the correct answer.
X
A Analytic View
X
B Open ODS View
X
C Calculation View
X
D Attribute View
© Copyright. All rights reserved.
159
Unit 4: Learning Assessment
4. What should you create to combine calculation views with InfoProviders?
Choose the correct answer.
X
A InfoSource
X
B Open ODS View
X
C DataStore Object
X
D CompositeProvider
X
E BW Query
© Copyright. All rights reserved.
160
Unit 4
Learning Assessment - Answers
1. What can I do with the SAP HANA Modeler Perspective?
Choose the correct answers.
X
A Create CompositeProviders
X
B View database tables
X
C Create calculation views
X
D Execute DTPs
Correct — The SAP HANA Modeler Perspective allows you to create calculation views and
view database tables
2. Smart Data Access (SDA) supports the extraction, cleansing, and loading of data from
remote source to SAP HANA.
Determine whether this statement is true or false.
X
True
X
False
Correct — Smart Data Access (SDA) does not support the extraction, cleansing, and
loading of data from remote source to SAP HANA. SDA is used to connect to remote data
sources for virtual access only and no data is stored in SAP HANA.
3. Which is the central modeling object of SAP HANA?
Choose the correct answer.
X
A Analytic View
X
B Open ODS View
X
C Calculation View
X
D Attribute View
Correct — The central modeling object of SAP HANA is the Calculation View
© Copyright. All rights reserved.
161
Unit 4: Learning Assessment - Answers
4. What should you create to combine calculation views with InfoProviders?
Choose the correct answer.
X
A InfoSource
X
B Open ODS View
X
C DataStore Object
X
D CompositeProvider
X
E BW Query
Correct — You create a CompositeProvider to combine calculation views with
InfoProviders
© Copyright. All rights reserved.
162
UNIT 5
Working with Open ODS
Views
Lesson 1
Creating Open ODS Views
164
Lesson 2
Creating DataSources from Open ODS View
176
UNIT OBJECTIVES
Create Open ODS views
Create DataSources from Open ODS views to persist data in SAP BW/4HANA
© Copyright. All rights reserved.
163
Unit 5
Lesson 1
Creating Open ODS Views
LESSON OVERVIEW
This lesson shows how to create Open ODS views for virtual access of external data sources.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Create Open ODS views
Open ODS View
An Open ODS view enables you to define virtual data models that expose underlying objects
such as SAP HANA database tables and views and SAP BW/4HANA DataSources (that are
enabled for direct access). Open ODS views do not store data. These data models allow fast
and flexible integration without the need to create InfoObjects. This flexible type of data
integration makes it possible to consume external data sources in SAP BW/4HANA without
staging, combine data sources with SAP BW/4HANA models and physically integrate (load)
external data sources by creating DataSources.
The Open ODS view is an SAP BW/4HANA metadata object that provides a structure
description with attributes (fields) and data types. It represents a view on a source and adds
analytic metadata to this source. Supported data sources are objects, which describe their
data in a structure with attributes and data types (such as database tables), views, or SAP
BW/4HANA DataSources. The Open ODS view does not have separate storage for
transaction data or master data. This means persistency and analytic modeling are decoupled
for the Open ODS view.
Although classic modeling with InfoObjects guarantees a high level of consistency in the data
model, any existing modeling already in use for reporting and analysis is difficult to modify.
Modeling with Open ODS views is considerably more flexible. You can create an Open ODS
view with minimum effort for a data source and assign properties to the fields of the Open
ODS view. 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 characteristic. An Open ODS
view modeled in this way makes data available for consumption (for example, with a query).
The view can be enhanced stage by stage for further integration into SAP BW/4HANA.
Open ODS views are the InfoProvider for virtual access of external sources.
© Copyright. All rights reserved.
164
Lesson: Creating Open ODS Views
Figure 138: Overview Open ODS View
Consuming, Combining, and Physically Integrating Data
Consume external data without staging
The Open ODS view allows data sources to be virtually consumed without the need for a
separate SAP BW/4HANA persistence for the data. These data models can be located in a
database schema (of the SAP HANA database in SAP BW/4HANA), which is not managed
by SAP BW/4HANA. Alternatively, the models can be located in other databases, which
can be connected to the SAP HANA database in SAP BW/4HANA using SAP HANA smart
data access.
Combine external data with SAP BW/4HANA models
By using links to InfoObjects, you can combine Open ODS views with SAP BW/4HANA
models and thereby use master data attributes and texts in SAP BW/4HANA. There is
another way of combining the Open ODS view with SAP BW/4HANA models; by using the
Composite Provider.
Physical integration of external data (staging)
For ETL purposes, you can create DataSources for Open ODS views and physically
integrate data sources into SAP BW/4HANA. In this case, the persistence of the Open ODS
view is ensured by a DataStore Object (advanced).
© Copyright. All rights reserved.
165
Unit 5: Working with Open ODS Views
Figure 139: Open ODS Views Source Types
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 for queries and, in subsequent steps, link InfoObjects, for example, to
the fields of the Open ODS view and use the InfoObject properties in your model.
Figure 140: Create Open ODS Views
Transporting Open ODS Views
© Copyright. All rights reserved.
166
Lesson: Creating Open ODS Views
The Open ODS view is integrated into the TLOGO framework and can be transported. The
transport object is FBPA (A version) or FBPD (delivery version). It is important to take certain
dependencies into account for the transport.
Dependencies for Source Table or Source View
If you use a table or a view as the source object of an Open ODS view, the table or the view
must exist in the target system for the transport when the open ODS view is transported. If
you use SAP HANA smart data access, the SDA connection must be configured so that the
table or view is available in the target system.
Dependencies for DB Connect Source System
The Open ODS view does not contain any local system information, such as connection
information for the database or the database schema. This information is specified in the DB
Connect source systems for Open ODS views that access data from database tables or
database views. In the transport target system, assignment table RSLOGSYSMAPmust be
correctly configured for DB Connect source systems. This is used to access tables or views
from Open ODS views.
Authorization Behavior for Fields of Open ODS Views
The Authorization Relevance property on the characteristic field of the Open ODS view allows
you to specify whether or not a field is authorization-relevant. The settings in the Open ODS
view also define which analysis authorizations should be checked for the field when the query
is executed. When the query is executed, the system also checks whether the user has
analysis authorizations. Which analysis authorizations are checked when the query is
executed depends on how the field is set to authorization-relevant.
No Associations Defined for the Characteristic Field: Authorization-Relevance is Defined
Locally
If the Authorization Relevance field property is set locally, the system checks all
authorizations defined for the Open ODS view field.
Note:
In the administration screen for analysis authorizations, you can use
authorization-relevant Open ODS view fields with their InfoObject name for the
authorization definition. The fields display as InfoObjects in the administration
screen for analysis authorizations.
If you have defined an association for a field of the Open ODS view, the authorization behavior
depends on the settings in the Open ODS view as shown in the table.
Table 2: Dependency of the Authorization Relevance Property on Associations
If you have defined an association for a field of the Open ODS view, the authorization behavior
depends on the settings in the Open ODS view as shown in the table.
© Copyright. All rights reserved.
167
Unit 5: Working with Open ODS Views
Settings in the Open ODS view (EclipseBased Editor)
Authorization behavior
You have defined an association and chose
Direct Usage of Associated Object by Name.
The authorization relevance is inherited by
the association and cannot be changed locally.
If the associated object is authorization-relevant, the system checks the analysis authorizations (defined for the associated object)
for the Open ODS field view when executing
the query.
You have defined an association and chose
Usage of System-Wide Unique Name.
The authorization relevance is inherited by
the association. If the associated object is authorization-relevant, the system checks the
analysis authorizations (defined for the associated object) for the Open ODS field view
when executing the query.
You have defined an association, chose Usage of System-Wide Unique Name and used
the pen button Toggle (Toggle Default Value/
Manual Entry) to overwrite the property (set
locally).
The authorization relevance is determined locally. If you have set the field as authorization-relevant, the analysis authorizations defined for the Open ODS view field are
checked when query is executed. The Open
ODS view field is available together with its
InfoObject name as an InfoObject in the administration screen for analysis authorizations.
Even if you do not change the entry after
pressing the pen button. (Toggle Default Value/Manual Entry), the system interprets the
property as being specified locally and not as
the default or inherited value. The analysis
authorizations are checked, which are defined for the InfoObject that represents the
field of the Open ODS view in the authorization maintenance screen. The analysis authorizations of the associated object are not
checked.
© Copyright. All rights reserved.
168
Lesson: Creating Open ODS Views
Figure 141: Field Definitions in Open ODS Views
Open ODS views enable you to define SAP BW/4HANA data models for external data such as
database tables and database views of any SAP schema. These data models allow simple,
flexible integration, without the need to create InfoObjects. The data sources can be used
virtually in SAP BW/4HANA.
Modeling of Open ODS views takes place at the field level, but can be complemented by
InfoObjects and gradually extended, in order to have a higher level of integration. Open ODS
views allow you to switch between virtualization and dedicated Data Warehouse persistencies
and thereby provides a flexible entry point into replication scenarios.
We recommend Open ODS views in cases where the format of the external data is suitable for
integration into a data flow - when an external data model displays a pure fact view or a pure
dimension view. A prerequisite for the integration into an SAP BW/4HANA data flow is that
the source model must be divided into facts, master data, and texts. Based on these units
that can be replicated, Open ODS views allow you to model reporting views on data.
Structure of the Open ODS View Editor
The Open ODS View Editor always contains the General tab. Depending on the semantics of
the Open ODS view, it can also contain the relevant semantic tabs; Facts, Master Data and/
or Texts .
Tab: General
On the General tab, you see the name and description of the Open ODS view, together with
information about the semantics of the Open ODS view.
Table 3: Tabs: Facts, Master Data, Texts
The Facts, Master Data and Texts tabs represent the central area for Open ODS view
maintenance. Open ODS views for master data can have two types of semantics. In this case,
the editor contains both the Master Data tab and the Texts tab.
© Copyright. All rights reserved.
169
Unit 5: Working with Open ODS Views
Tab screen area
Contents
Upper screen area
Here you see information on the source object. The tooltip can also show further details
on the source for certain source types. Certain sources - such as SAP BW/4HANA DataSource, DataStore object (advanced) and
transformation - allow you to navigate to object maintenance.
Left screen area — Source field
Here you see the structure of the source object including the source fields and their
properties. If you are using a transformation
as the source, the InfoSource fields are displayed in the structure of the source object.
General screen area — View Fields
Here you see the structure of the Open ODS
view with the view fields organized in field
categories. The information displayed on the
fields includes the following:
The Associated Object column shows
which association has been configured for
the field.
If navigation attributes have been specified for fields, you can expand the list of
navigation attributes using the arrow button on the field name.
Right screen area — General
Here you see the analytic properties of the
view field for the selected source field/view
field.
Supported Sources for Open ODS Views
The following sources are available for data access with Open ODS views: DataSources in SAP
BW/4HANA, DataStore objects (advanced), database tables or views of the SAP BW/4HANA
SAP HANA database, and databases connected to SAP BW/4HANA using SAP HANA smart
data access. In addition, transformations allow data type conversions, for example, as
sources, if data is consumed outside of the SAP BW/4HANA-managed database schema.
DataSources in SAP BW/4HANA
With source type DataSource (SAP BW/4HANA), Open ODS views for supported source
system types: SAP BW/4HANA, SAP, ODP (SAP extractors), ODP (SAP BW/4HANA) and DB
Connect - can access data, for which DataSources already exist in SAP BW/4HANA. For Open
ODS views, only DataSources are available as sources that support direct access.
DataStore Objects (Advanced)
With the source type DataStore Object (Advanced), Open ODS views can access data from
DataStore objects (advanced). Only DataStore objects for which all reporting takes place on
the active table are supported.
Database Tables or Views of the SAP BW/4HANA SAP HANA Database
© Copyright. All rights reserved.
170
Lesson: Creating Open ODS Views
With source type database table or view, Open ODS views can access data from any schemas
on the SAP BW/4HANA SAP HANA database. Previously, the connection to the relevant
schema had to be configured as a DB Connect source system.
Tables and Views from Databases Using SAP HANA Smart Data Access
With the Virtual Tables Source Type Using HANA Smart Data Access, Open ODS views can
access remote data in different source databases. The source database must be configured
in SAP HANA as a remote source. The connection to the source database and to the relevant
schema is configured using a DB Connect source system.
When an Open ODS view is created with source type Virtual Table using HANA Smart Data
Access, a virtual table is created in SAP HANA. The virtual table points to a remote table,
which is the source object of the Open ODS view, and allows access to data.
Transformations
Using the source type transformation, you can use transformations to perform data
conversions, assignments, and string operations on data, which are consumed using Open
ODS views. This can be useful if you cannot or do not want to use transformations in the data
source on data, which is outside of the database schema managed by SAP BW/4HANA. You
can use a transformation as the source for the Open ODS view, provided that you have
created the corresponding data flow.
Figure 142: Open ODS Views — Field Semantics for Fact and Master Data
The Facts, Master Data , and Texts tabs represent the central area for Open ODS view
maintenance. Open ODS views for master data can have two types of semantics. In this case,
the editor contains both the Master Data tab and the Texts tab.
By using links to InfoObjects, you can combine Open ODS views with SAP BW/4HANA models
and thereby use master data attributes and texts in SAP BW/4HANA. There is another way of
© Copyright. All rights reserved.
171
Unit 5: Working with Open ODS Views
combining the Open ODS view with SAP BW/4HANA models; by using the Composite
Provider.
You can use this view for queries and, in subsequent steps, link InfoObjects, for example, to
the fields of the Open ODS view and use the InfoObject properties in your model.
Note:
Characteristics (key) is only needed for Open ODS views to generate DataSource
and field-based ADSO (Persistence Layer).
Hint:
Associated objects to Open ODS views of the type master are only relevant for
navigation if the query is executed on the master ODS view – if the master ODS
view is associated to an ODS view type fact, then only texts (if exist) are offered.
Figure 143: Open ODS View — Associations to SAP BW/4HANA InfoObjects
The Authorization Relevance property on the characteristic field of the Open ODS view allows
you to specify whether or not a field is authorization-relevant. The settings in the Open ODS
view also define which analysis authorizations should be checked for the field when the query
is executed. When the query is executed, the system also checks whether the user has
analysis authorizations. Which analysis authorizations are checked when the query is
executed depends on how the field is set to authorization-relevant.
© Copyright. All rights reserved.
172
Lesson: Creating Open ODS Views
Hint:
In the administration screen for analysis authorizations, you can use
authorization-relevant Open ODS view fields with their InfoObject name for the
authorization definition. The fields display as InfoObjects in the administration
screen for analysis authorizations.
You can associate certain fields of your Open ODS view with SAP BW/4HANA InfoObjects.
The following list gives examples of these fields:
BEx default settings
Hierarchies
Texts
Master data attributes
Master data navigational attributes
SAP BW/4HANA Analysis authorizations
As with an InfoObject, the Open ODS view can combine language-independent semantics for
the attribute keys with language-dependent semantics for texts. You can add extra semantics
for an Open ODS view that you created with one of the two other semantics (texts or
attributes).
When you use associations on fields of the type characteristic , you can link an Open ODS view
to master data and texts of other Open ODS views or InfoObjects. This allows you to inherit
properties from the associated object, assign additional key fields (compounding), and use
texts and navigation attributes of the associated objects in queries on the Open ODS view.
In the case of fields with the type key figure , you can add associations to InfoObjects. This is
particularly relevant if you want to reuse formulas or variables (defined on the associated
InfoObject) in queries.
© Copyright. All rights reserved.
173
Unit 5: Working with Open ODS Views
Figure 144: Open ODS View — Naming Conventions of Fields and InfoObjects
Figure 145: SAP BW/4HANA Field-Based Modeling on any Data — Summarized
© Copyright. All rights reserved.
174
Lesson: Creating Open ODS Views
Figure 146: Create Open ODS Views Exercise
LESSON SUMMARY
You should now be able to:
Create Open ODS views
© Copyright. All rights reserved.
175
Unit 5
Lesson 2
Creating DataSources from Open ODS View
LESSON OVERVIEW
This lesson explains how to generate a DataSource from an Open ODS view.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Create DataSources from Open ODS views to persist data in SAP BW/4HANA
Create DataSources from Open ODS Views
Figure 147: Incremental Modeling of Data Delivery — Staging into Advanced DSO
For existing Open ODS views, you can also automatically create 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.
You can keep your data model completely virtual, but add additional transformation logic in a
standard SAP BW/4HANA Transformation Rule. This means, for existing Open ODS views,
you can also automatically create 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,
the InfoSource. Leverage the Generate function of both modeling environments in order to
achieve this.
The following objects are created: BW/4HANA DataSource (type SAP HANA Local Database
Schema), Transformation Rule and Advanced DSO as well as DataTransferProcess:
© Copyright. All rights reserved.
176
Lesson: Creating DataSources from Open ODS View
The system creates an Advanced DSO with an active table in the InfoArea of the open ODS
view. The fields of this table are transferred from the fields of the structure of the Open
ODS view. Associations to other Open ODS view fields are ignored.
The Advances DSO is based on fields or where InfoObjects are associated to InfoObjects.
The system replaces with Open ODS view with the source object. The source object is now
the ADSO.
The system creates a transformation between DataSource and ADSO.
The objects generated with the data flow are written to the $TMP local package without a
transport prompt. Change the package assignment in the SAP BW/4HANA transport
connection of the SAP BW/4HANA back end system and write the objects to a transport
request manually.
The source of the Open ODS view is now the active table of the ADSO. Without loading the
data, this data model will not see any data. Be aware that you duplicate (replicate) data in this
case from a source outside of the SAP BW/4HANA-managed SAP HANA-schema into the
SAP BW/4HANA-managed schema. The outbound interface of the original Open ODS view
remains unchanged. All Business Explorer (BEx)-based queries will remain unchanged, all
connections to CompositeProiders are not impacted at all.
Some key considerations of this scenario:
The following objects are created: BW/4HANA DataSource (type SAP HANA Local
Database Schema), Transformation Rule and InfoSource (as target of the
Transformation).
The system creates an InfoSource in the NODESNOTCONNECTEDapplication component.
The fields of this InfoSource are copied from the fields of the structure of the Open ODS
view. Associations to other Open ODS view fields are ignored when creating the
InfoSource.
The InfoSource is based on fields or where InfoObjects are associated to InfoObjects.
The system replaces with Open ODS view with the source object. The source object is now
the transformation.
The system creates a transformation between DataSource and InfoSource.
© Copyright. All rights reserved.
177
Unit 5: Working with Open ODS Views
Figure 148: Properties of Advanced DSO
The DataStore Object (advanced) is the central object for data storage and data consolidation
in the SAP BW/4HANA system. If the required properties are set accordingly, the DataStore
Object (advanced) can be used in the various layers of the data warehouse.
The DataStore Object (advanced) can contain a mixture of InfoObjects and fields. You can
load data into the SAP BW/4HANA system without assigning InfoObjects and all the functions
are still available. Thanks to its new Request-Management, the DataStore Object (advanced)
is particularly well suited to deal with frequent loading and large amounts of data.
The ODP source system is available to help you update data from one InfoProvider to another
InfoProvider in a different SAP BW/4HANA system (data mart). Modeling for the DataStore
Object (advanced) is integrated in the BW/4HANA Modeling Tools.
© Copyright. All rights reserved.
178
Lesson: Creating DataSources from Open ODS View
Figure 149: Data Flow Generation of Open ODS View
Creating a Data Flow for Open ODS Views
For Open ODS views with the Database Table source type, View or Virtual Table Using HANA
Smart Data Access, you can create a data flow with a DataStore Object (advanced) or a
transformation. When the data flow is created, the source of the Open ODS view is
automatically replaced with the created object.
Data Flow with DataStore Object (advanced)
You can create a DataStore Object (advanced) with data flow as data persistency for the
Open ODS view. For reporting purposes and for using the CompositeProvider, we recommend
using the Open ODS view directly.
Transformation
You can use the transformation with data flow to perform data type conversions, assignments
or string operations, for example on the source data of an Open ODS view.
© Copyright. All rights reserved.
179
Unit 5: Working with Open ODS Views
Figure 150: Open ODS View — Switch to Persistence
SAP BW/4HANA developers can start developing, testing and prototyping data, before having
to work the underlying data model. It supports agile development and provides more flexibility
in projects.
In many situations in your project, data persistence is required, and a traditional ETL process
needs to be in place. That is where the Advanced DSO (ADSO) comes into play. From SAP
BW/4HANA 7.4 SP8, it is now possible to generate an Advanced DSO from your existing Open
ODS view, inheriting all InfoObject assignments and field information. When used on an SAP
ERP DataSource, it creates a transformation to that DataSource and a Data Transfer Process.
Figure 151: Open ODS View with Smart Data Access — Switch to Persistence
© Copyright. All rights reserved.
180
Lesson: Creating DataSources from Open ODS View
Consume external data without staging
The Open ODS view allows data sources to be virtually consumed without the need for a
separate SAP BW/4HANA persistence for the data. These data models can be located in a
database schema (of the SAP HANA database in SAP BW/4HANA), which is not managed by
SAP BW/4HANA. Alternatively, the models can be located in other databases, which can be
connected to the SAP HANA database in SAP BW/4HANA using SAP HANA Smart Data
Access.
Open ODS View and Logical Data Warehouse
The Open ODS view provides a number of functions that are important for establishing logical
data warehouse components in a solution.
The accessibility of external data
Every source that is accessible to SAP HANA is a potential source for an Open ODS view. The
Open ODS view accepts the following: SQL views, SAP HANA views, tables, and virtual SAP
HANA tables representing a remote DB view or a remote table (SAP HANA smart data
access).
The capacity of external data structures to be modeled
An Open ODS view assigns a source semantics (facts, master data, texts). Throughout
multiple Open ODS views, it is possible to have semantics on the same source. It is important
for the source views to be cut so that they do not contain a combination of facts and master
data (attributes).
The capacity of external data to be modeled
An Open ODS view assigns semantics (characteristic, key figure, currency and so on) to the
fields in the source structure. A single source field can have multiple semantics assigned to it
(characteristic and key figure for example). Text fields can be addressed directly as texts in
the SAP BW/4HANA sense. If multilingualism is required, text fields can be used together
with other attributes in a source structure, and can be interpreted as such by an ODS view.
The integration of external data
Open ODS views can be associated with other Open ODS views. The association of master
data Open ODS views with a fact Open ODS view produces a star schema for example. Open
ODS views can be associated with InfoObjects and can thus address them directly. Open ODS
views can be mapped to other SAP BW/4HANA InfoProviders in CompositeProviders.
The necessary flexibility and stability in relation to other source structures
The Open ODS view makes it possible to flexibly exchange source structures with one
another. The Open ODS view supports the logical data warehouse approach, meaning that the
location of the data is immaterial: If a service level of source A at location B is not met, the
source data from A must be able to move to location C without affecting the queries and so on
built on source structure A. It is important that the new source structure A offers the same
fields at location C.
Support for changing the location of the source and for transferring it to the data warehouse
In addition to the interchangeability of the source structures, the Open ODS view also
supports the optional generation of a DataSource, a DataStore Object (advanced) and a data
flow from the definition of the Open ODS view. The Open ODS view is thus the central object
for virtually integrating external data into the data warehouse.
© Copyright. All rights reserved.
181
Unit 5: Working with Open ODS Views
Figure 152: LSA — Holistic Framework for SAP BW/4HANA on SAP HANA
An important aspect of in-memory technology is the paradigm shift that results in dataintensive business logic being pushed down to be calculated by the database instead of the
application server. In SAP BW/4HANA, this in-memory programming paradigm has been
followed for several years by the SAP BW/4HANA Accelerator (BWA) and taken over by SAP
HANA. It has a tremendous impact on SAP BW/4HANA and on the Layered Scalable
Architecture (LSA). While the key principles remain the same, SAP HANA brings much more
modeling options in order to streamline your enterprise data warehouse architecture. This
flexibility advantage is represented by SAP in the updated reference architecture, LSA
powered by SAP HANA (LSA++) .
The following list gives the properties of LSA++:
Reporting on Propagator is allowed.
Transformations could be moved from the Business Transformation Layer into Query
Design or to SAP HANA. Queries can use SAP HANA Views directly via direct access on
SAP HANA, or by using CompositeProvider.
Virtualization Layer on top of both architected Data Marts and Propagators by leveraging
UNION or JOIN by CompositeProvider.
© Copyright. All rights reserved.
182
Lesson: Creating DataSources from Open ODS View
Figure 153: Create DataSources from Open ODS Views Exercise
To Generate a Dataflow
1. In the maintenance screen for the Open ODS view, choose Generate.
2. In the subsequent dialog box, you can change the proposed name for the DataSource.
3. The system now creates a DataSource in the source system of the Open ODS view in the
NODESNOTCONNECTEDapplication component. The fields of this DataSource are
created from the source fields of the Open ODS view.
4. The system replaces with Open ODS view with the source object. The source object is now
the DataSource.
5. Choose Generate again.
6. In the subsequent dialog box, select DataStore Object (advanced) as the target object
type.
7. Change the suggested name for the DataStore Object .
8. Specify what to do with the data types of the fields. The BW analytic manager only
supports specific data types for reporting. If the source uses different data types, these
types are automatically converted at run time. If you create the target object with BW data
types, this conversion does not need to be performed at run time. In addition, this makes it
easier to use the target objects in other BW objects.
9. To create, choose Enter.
© Copyright. All rights reserved.
183
Unit 5: Working with Open ODS Views
LESSON SUMMARY
You should now be able to:
Create DataSources from Open ODS views to persist data in SAP BW/4HANA
© Copyright. All rights reserved.
184
Unit 5
Learning Assessment
1. Open ODS views are defined using InfoObjects.
Determine whether this statement is true or false.
X
True
X
False
2. What additional objects can be generated from an Open ODS view?
Choose the correct answers.
X
A DataSource
X
B Transformation
X
C DataStore Object
X
D CompositeProvider
© Copyright. All rights reserved.
185
Unit 5
Learning Assessment - Answers
1. Open ODS views are defined using InfoObjects.
Determine whether this statement is true or false.
X
True
X
False
Correct — Open ODS views are defined using fields. InfoObjects can be optionally
associated with the defined fields to provide additional features
2. What additional objects can be generated from an Open ODS view?
Choose the correct answers.
X
A DataSource
X
B Transformation
X
C DataStore Object
X
D CompositeProvider
Correct — A DataSource, Transformation, and DataStore Object can be generated from
an Open ODS view using the Generate DataFlow option of the open ODS view
© Copyright. All rights reserved.
186
UNIT 6
Working with
Transformations and
Data Transfer
Processes (DTP)
Lesson 1
Implementing Transformations
188
Lesson 2
Creating Data Transfer Processes (DTP)
210
UNIT OBJECTIVES
Implement transformations
Implement data transfer processes (DTP)
© Copyright. All rights reserved.
187
Unit 6
Lesson 1
Implementing Transformations
LESSON OVERVIEW
This lesson takes a detailed look at data transformation and DTP in SAP BW/4HANA.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Implement transformations
Transformations in Detail
The data flow in SAP BW/4HANA defines which objects are needed at design time and which
processes are needed at run time. These objects and processes are needed to transfer data
from a source to SAP BW/4HANA. They cleanse, consolidate, and integrate the data, so that
it can be used for analysis, reporting, and planning. The individual requirements of your
company processes are supported by numerous options for designing the data flow. You can
use any data sources that transfer the data to SAP BW/4HANA or access the source data
directly, apply simple or complex cleansing and consolidating methods, and define data
repositories that correspond to the requirements of your layer architecture.
In SAP BW/4HANA, the metadata description of the source data is modeled
with DataSources. A DataSource is a set of fields that are used to extract data of a business
unit from a source system and transfer it to the entry layer of the SAP BW/4HANA system or
provide it for direct access.
Using the transformation, data is copied from a source format to a target format in SAP BW/
4HANA. Transformation thereby allows you to consolidate and cleanse data from multiple
sources. You can perform semantic synchronization of data from various sources. You
integrate the data into the SAP BW/4HANA system by assigning fields from the DataSource
to InfoObjects. In the data flow, the transformation replaces the update and transfer rules,
including transfer structure maintenance.
InfoProviders consist of several InfoObjects. They are persistent data repositories that are
used in the layer architecture of the Data Warehouse or in data views. They provide data for
analysis, reporting, and planning. You also have the option of writing the data to other
InfoProviders. Using an InfoSource (optional in the data flow), you can connect multiple
sequential transformations. You therefore only require an InfoSource for complex
transformations (multi-step procedures). You use the data transfer process (DTP) to transfer
the data within SAP BW/4HANA from one persistent object to another object, in accordance
with certain transformations and filters. Possible sources for the data transfer include
DataSources and InfoProviders; possible targets include InfoProviders and open hub
destinations. You can also distribute data to other systems using an open hub destination. In
SAP BW/4HANA, process chains are used to schedule the processes associated with the
data flow, including InfoPackages and data transfer processes.
The complexity of data flows varies. As an absolute minimum, you need a DataSource, a
transformation, an InfoProvider, and a data transfer process.
© Copyright. All rights reserved.
188
Lesson: Implementing Transformations
Figure 154: Enhanced Data Flow — Info Sources
Using an InfoSource (optional in the data flow), you can connect multiple sequential
transformations. You only require an InfoSource for complex transformations (multistep
procedures).
Figure 155: Transformation Display Options
The transformation process allows you to consolidate, cleanse, and integrate data. You can
semantically synchronize data from heterogeneous sources. When you load data from one BI
© Copyright. All rights reserved.
189
Unit 6: Working with Transformations and Data Transfer Processes (DTP)
object into a further BI object, the data is passed through a transformation. A transformation
converts the fields of the source into the format of the target.
You create a transformation between a source and a target. The BI objects DataSource,
InfoSource, DataStore object, and InfoObject serve as source objects. The BI objects
InfoSource, InfoObject, and DataStore object serve as target objects.
Figure 156: Expert, Start, and End Routines
You use routines to define complex transformation rules. Routines are local ABAP classes
that consist of a predefined definition area and an implementation area. The TYPESfor the
inbound and outbound parameters and the signature of the routine (ABAP method) are
stored in the definition area. The actual routine is created in the implementation area. ABAP
object statements are available in the coding of the routine. Upon generation, the coding is
embedded in the local class of the transformation program as the method.
The routine has a global part and a local part. In the global part you define global data
declarations, CLASS DATA.. These are available in all routines. You can create function
modules, methods, or external subprograms in the ABAP Workbench if you want to reuse
source code in routines. You can call these in the local part of the routine. If you want to
transport a routine that includes calls of this type, the routine and the object called should be
included in the same transport request. Transformations include different types of routine:
start routines, routines for key figures or characteristics, end routines, and expert routines.
© Copyright. All rights reserved.
190
Lesson: Implementing Transformations
Figure 157: Expert, Start, and End Routines 2
Expert Routine
This type of routine is intended for use in special scenarios. You can use the expert routine if
the other transformation functions are not sufficient. You can use the expert routine as an
interim solution until the necessary functions are available in the standard routine. You can
use this to program the transformation yourself without using the existing rule types. You
must transfer the messages to the monitor yourself. If you have already created
transformation rules, the system deletes them once you have created an expert routine.
Navigation attributes of the source of the transformation are not available in the expert
routine.
Note:
If the target of the transformation is a DataStore object, key figures are updated
by default with the Overwrite (MOVE) aggregation behavior.
© Copyright. All rights reserved.
191
Unit 6: Working with Transformations and Data Transfer Processes (DTP)
Figure 158: Access the Start Routine
Start Routine
The start routine is run for each data package at the start of the transformation. The start
routine has a table in the format of the source structure as input and output parameters. It is
used to perform preliminary calculations and store these in a global data structure or in a
table. This structure or table can be accessed from other routines. You can modify or delete
data in the data package.
© Copyright. All rights reserved.
192
Lesson: Implementing Transformations
Figure 159: Start Routines Conceptually
The following list shows the Start Routine Parameters:
Importing
-
REQUEST: Request ID.
-
DATAPAKID: Number of current data package.
Exporting
-
MONITOR: Table for user-defined monitoring. This table is filled by means of row
structure MONITOR_REC (the record number of the processed record is inserted
automatically from the framework).
Changing
-
SOURCE_PACKAGE: Structure that contains the inbound fields of the routine.
Raising
-
CX_RSROUT_ABORT: If a raise exception type CX RSROUT_ABORT is triggered in the
routine, the system terminates the entire load process. The request is highlighted in the
extraction monitor as having been terminated. The system stops processing the
current data package. This is useful for serious errors.
© Copyright. All rights reserved.
193
Unit 6: Working with Transformations and Data Transfer Processes (DTP)
Figure 160: End Routine
An end routine is a routine with a table in the target structure format as an inbound parameter
and an outbound parameter. You can use an end routine to post-process data, package-bypackage, after transformation. For example, you can delete records that are not to be
updated, or perform data checks.
Note:
If the target of the transformation is a DataStore object, key figures are updated
by default with the Overwrite (MOVE) aggregation behavior. You have to use a
dummy rule to override this.
End Routine
In the SAP ERP system, you load data using the General Ledger: Transaction
Figures DataSource (0FI_GL_1) into the DataStore object FIGL: Transaction
Figures (0FIGL_O06). You want to create an end routine to fill the additional InfoObject Plan/
Actual Indicator (ZPLACTUAL). You also want the routine to read field Value Type. If the value
is 10 (actual), value A is written to the Plan/Actual Indicator InfoObject; if the value is 20
(plan), value P is written to the Plan/Actual Indicator InfoObject.
In transformation maintenance, choose Create End Routine. In the routine editor opens enter
the following lines of code:
*---------------------------------------------------------------------*
METHOD end_routine.
*=== Segments ===
FIELD-SYMBOLS:
<RESULT_FIELDS> TYPE _ty_s_TG_1.
© Copyright. All rights reserved.
194
Lesson: Implementing Transformations
*$*$ begin of routine - insert your code only below this line *-*
loop at RESULT_PACKAGE assigning <RESULT_FIELDS>
where vtype eq '010' or vtype eq '020'.
case <RESULT_FIELDS>-vtype.
when '010'.
<RESULT_FIELDS>-/bic/zplactual = 'A'. "Actual
when '020'.
<RESULT_FIELDS>-/bic/zplactual = 'P'. "Plan
endcase.
endloop.
*$*$ end of routine - insert your code only before this line *-*
ENDMETHOD.
"end_routine
*---------------------------------------------------------------------*
The code loops through result_package searching for values that have the value type 10 or 20.
For these values, the appropriate value is passed on to InfoObject Plan/Actual
Indicator (ZPLACTUAL) .
Once the code is entered, you can exit the editor and save the transformation. An edit
icon next to the End Routine indicates that an end routine is available.
The following list shows the End Routine Parameters:
Importing
-
REQUEST: Request ID.
-
DATAPAKID : Number of current data package.
Exporting
-
MONITOR: Table for user-defined monitoring. This table is filled using row structure
MONITOR_REC(the record number of the processed record is inserted automatically
from the framework).
Changing
-
RESULT_PACKAGE: Contains all data that has been processed by the transformation.
Raising
-
CX_RSROUT_ABORT: If a raise exception type CX_RSROUT_ABORTis triggered in the
routine, the system terminates the entire loading process. The request is highlighted in
the extraction monitor as Terminated. The system stops processing the current data
package. This can be useful if serious errors occur.
© Copyright. All rights reserved.
195
Unit 6: Working with Transformations and Data Transfer Processes (DTP)
Note:
In the default setting, only fields that have a rule in the transformation are
transferred from the end routine. Choose Change Update Behavior of End
Routine to set the All Target Fields (Independent of Active Rules) indicator. Fields
that are only filled in the end routine are then updated and not lost. This function is
only available for standard DataStore objects, DataStore objects for direct writing,
and for master data tables.
If only the key fields are updated for master data attributes, all the attributes are
initialized, regardless of the settings described here. For more information, see
SAP Note 1096307.
Figure 161: SAP HANA-optimized Transformation Rules
If your SAP BW/4HANA runs on an SAP HANA database, it is possible, or necessary in certain
cases, to process the data transfer process (DTP) with the SAP HANA Execution processing
mode. The processing type is defined in the header data area in DTP by setting the
corresponding SAP HANA Execution flag.
When processing the data transfer process in SAP HANA, the following rules apply:
The data transfer process can be processed with processing type SAP HANA Execution if
the data transfer process check finds that all transformations can be executed in SAP
HANA. In this case, the flag in the data transfer process maintenance screen is inputready, and you can set the flag if the prerequisites for this in the data transfer process are
met. If this is already the case during creation, the flag is set by default.
The data transfer process must be processed with processing type SAP HANA Execution if
you are using ABAP Managed Database Procedures in one of the transformations for the
data transfer process. In this case, the flag is set in the data transfer process maintenance
screen and is not input-ready. Processing type SAP HANA Execution is therefore set.
© Copyright. All rights reserved.
196
Lesson: Implementing Transformations
The data transfer process cannot be processed with the processing type SAP HANA
Execution, if you are using an ABAP routine in one of the transformations for the data
transfer process. In this case, the flag is set and not input-ready in the data transfer
process maintenance screen, and a processing type is set that can be executed on the
ABAP server.
Note:
If you have a path in which one transformation contains an ABAP routine and
another transformation contains ABAP Managed Database Procedures, you
cannot define a data transfer process for this path. In this case, change the
transformation so that either the ABAP routine or the ABAP Managed Database
Procedures can be used, but not both.
Transformation in SAP HANA Database
If you are using an SAP HANA database, all transformations are processed in the SAP HANA
database, where possible. When a transformation is activated, the system checks whether the
transformation can be performed in SAP HANA. If so, you can set whether the transformation
should be performed in SAP HANA or on the application server. You set this when you create
a data transfer process. If the transformation has an ABAP Managed Database Procedure
however, it must be performed in SAP HANA.
When you choose Check to the right of the transformation's name field, you can verify
whether the transformation can be performed in SAP HANA. The system then attempts to
create the transformation in SAP HANA. If this is successful, the transformation is flagged
with Can be performed in SAP HANA. If the check is not successful, you can find out why by
viewing the log. If you need special transformations that are not possible with the standard
transformation rules, you can create these as ABAP Managed Database Procedures in SAP
HANA. This function is only intended for use by experts. You need to be registered as a
developer, in order to use this function.
Note:
You have to model date calculations (such as sy-date + 1) with the
ADD_DAYS_TO_DATE formula, both for internal and external display.
The following objects are supported as targets:
DataStore object (standard and Staging)
DataStore object (advanced)
Semantically-partitioned objects based on DataStore objects
Open hub destinations with DB tables (without database connection) or third-party tools
The following objects are not supported for executing transformations in SAP HANA:
Queries as InfoProviders
ABAP routines (rule types Routine, Characteristic Routine, Start Routine, End Routine and
Expert Routine)
Rule groups
© Copyright. All rights reserved.
197
Unit 6: Working with Transformations and Data Transfer Processes (DTP)
Near-line connections
DataStore Objects
To read data from DataStore objects, the entire key must be provided.
Figure 162: SAP HANA-based Expert Routines
Processing Type Prerequisites
If the transformation supports execution in SAP HANA, the following prerequisites have to be
met in the DTP in order to use processing type SAP HANA Execution:
Error handling is deactivated.
No requests are in the DTP error stack.
No list is maintained for semantic grouping, the data is not extracted and posted in
semantic groups.
If the target of the DTP is a DataStore object, on the Update tab, Subsequent Processing
without Master Data is selected.
If the target of the DTP is an open hub destination, the destination is a database table or a
third-party tool.
If the source of the DTP is a DataStore object, on the Extraction tab, the parameter for
DeltaInit extraction from Active Table (with Archive) is not set.
Check and Set the Processing Type
The processing type is preset when creating the DTP if the prerequisites for this are met or
processing in SAP HANA is required because of the transformation. While editing the DTP,
you can set the input-ready SAP HANA Execution flag. The system then performs a check. If
one or more of the prerequisites is not met, it is not possible to set the flag, and the system
displays messages about the incompatibilities in a pop-up.
© Copyright. All rights reserved.
198
Lesson: Implementing Transformations
If the SAP HANA Execution flag is set in the DTP, and you make a change to the DTP, which is
incompatible with the SAP HANA execution (activating error handling for example), the
system removes the flag and displays messages about the incompatibilities in a pop-up.
Choose Check Availability to check whether processing in SAP HANA is possible in display
mode.
Parallel Processing
Requests are processed in parallel processes. A parallel process is derived from the main
process for each data package. This parallel process extracts and processes the data. On
the Extraction tab page, the Parallel Extraction field is selected. See SAP Note: 1935460.
Note:
For DTPs that would use processing type Extraction and Processing Parallel
Except for Delta Init. for processing in the ABAP server, the following applies if
using processing type SAP HANA Execution: The Parallel Extraction on
the Extraction tab is selected, and full requests or delta initialization requests are
extracted and processed in parallel from the active table.
Figure 163: SAP HANA-based Expert Routines 2
The following list shows the effects that a change to the transformation will have for an active
DTP with the processing type SAP HANA Execution:
If execution in SAP HANA is not supported any more after the transformation changes, the
system changes the processing type of the DTP to a suitable processing type in the ABAP
server and reactivates the DTP.
If the transformation is inactive, the system also sets the DTP to inactive.
In most other cases, the DTP remains active.
© Copyright. All rights reserved.
199
Unit 6: Working with Transformations and Data Transfer Processes (DTP)
If changes to transformations cause the error stack to change, the system reactivates the
DTP.
If execution is possible in SAP HANA after the transformation changes (or meets another
prerequisite in the DTP, such as deactivating error handling), processing type SAP HANA
Execution is not automatically set in the DTP. It needs to be set by the user via the SAP HANA
Execution flag.
Figure 164: Transformation Rules: Rules Details
A transformation consists of at least one transformation rule. Various rule types,
transformation types, and routine types are available. The following rules allow you to create
simple to highly complex transformations:
Transformation rules
Transformation rules map any number of source fields to at least one target field. You can
use different rules types for this.
Rule type
A rule type is an operation that is applied to the relevant fields using a transformation rule.
For more information, see Rule Type.
Transformation type
The transformation type determines how data is written into the fields of the target. For
more information, see Aggregation Type.
Rule group
A rule group is a group of transformation rules. Rule groups allow you to combine various
rules. For more information, see Rule Group.
Routine
© Copyright. All rights reserved.
200
Lesson: Implementing Transformations
You use routines to implement complex transformation rules yourself. Routines are
available as a rule type. There are also routine types that you can use to implement
additional transformations. For more information, see Routines in the Transformation.
Figure 165: Transformation Rules
Rule Type
The rule type defines whether and how a characteristic or key figure or a data field or key field
is updated into the target.
Direct Assignment
The field is filled directly from the chosen source InfoObject. If the system does not propose a
source InfoObject, you can assign a source InfoObject of the same type (amount, number,
integer, quantity, float, time) or create a routine. If you assign a source InfoObject to a target
InfoObject that has the same type but a different currency, you have to translate the source
currency to the target currency using a currency translation, or transfer the currency from the
source.
If you assign a source InfoObject to a target InfoObject that has the same type but a different
unit of measure, you have to convert the source unit of measure into the target unit of
measure using a unit of measure conversion, or transfer the unit from the source.
Constant
The field is filled directly with the value entered. The 0RECORDMODEInfoObject is an
exception to this. The system chooses constant for this, but no value is required. In this case,
the constant is required for delta administration (after images) with DataStore objects or
InfoObjects as InfoProviders. Apart from this, no records are deleted. If your DataSource
returns a suitable field for 0RECORDMODE, you can assign this directly instead.
Formula
The InfoObject is updated with a value determined using a formula. For more information
see, Transformation Library and Formula Builder.
© Copyright. All rights reserved.
201
Unit 6: Working with Transformations and Data Transfer Processes (DTP)
Read Master Data
The InfoObject is updated by reading the master data table of a characteristic from the source
with a key and a value and contains the corresponding InfoObject as an attribute. The
attributes and their values are read from the key and are then returned.
Note:
The Financial Management Area characteristic is included in the target but is not a
characteristic in the source. There is a characteristic (cost center, for example) in
the source however. This has the Financial Management Area characteristic as an
attribute. You can read the Financial Management Area attribute from the master
data table and use it to fill the characteristic in target.
Note:
It is not possible to read additional attributes for the attributes. You have to use
routines for this. If you have changed master data, you have to execute the change
run. This is because the active version is read when the master data is read. If this
cannot be found, the system raises an error. If the attribute is time-dependent,
you also have to define the read time: On the current date (sy-date), at the
beginning or end of a period (determined by the time characteristic in the
InfoSource), or on a constant date that you enter directly. Sy-date is used in the
default setting.
Read from DataStore Object
The InfoObject is updated is a similar way to master data reading, by reading a characteristic
in a DataStore object. There is no time-dependency however. Data is read from both the
database and near-line storage. If a near-line storage is found, the system checks
automatically whether it contains data and reads it.
The process of reading master data and DataStore objects on demand is performanceoptimized. The disjunct keys of a complete data package are read from the database using
mass access and buffered for further processing. This means that customer-defined
buffering with a start routine is not necessary because the performance is very similar.
The system can only read this data if the data part of the DataStore object contains the target
field. The source fields are then identified using the complete key. The assignment only works
using InfoObjects. If the source is a DataSource, you have to assign an InfoObject to the field.
Note:
If there are more key fields in the DataStore object than in the source,
performance problems can occur.
Staging DataStore objects need a semantic key. To avoid performance problems
here, the data must be unique. You can define how the system should behave if
reading fails: The system either displays an error message or provides a constant.
Read from DataStore Object (advanced)
To read from a DataStore object (advanced), the system first provides you with a proposal for
how the fields can be assigned. The key fields must be assigned to the source fields of the
transformation. When assigning the fields, the names do not need to be identical.
© Copyright. All rights reserved.
202
Lesson: Implementing Transformations
Routine
The field is filled by a transformation routine that you have written.
Note:
For DataStore objects and InfoObjects: You cannot use the return code in the
routine for data fields that are updated by being overwritten. If you do not want to
update specific records, you can delete these from the start routine.
If you generate different rules for different key figures/data fields for the same
characteristic, a separate data record can be created from the data record's
source for each key figure.
If you fill the target key figure from a transformation routine, currency translation
has to be performed using the transformation routine. This means that no
automatic calculation can be performed.
Time Update
When performing a time update, automatic time conversion and time distribution are
provided. Direct update: The system performs a time conversion automatically.
Time Conversion
You can update source time characteristics to target time characteristics using automatic
time conversion. This function is not available for DataStore objects, as time characteristics
are treated as normal data fields. The system only offers time characteristics that have an
automatic time conversion routine.
Time Distribution
You can update time characteristics with time broadcasting. All the key figures that can be
added are split into correspondingly smaller units of time. If the source contains a time
characteristic (such as 0CALMONTH) that is not as precise as a time characteristic of the
target (such as 0CALWEEK), you can combine these characteristics in the rule. The system
then performs time broadcasting in the transformation.
Initial
The field remains empty.
No Transformation
The key figures are not written to the InfoProvider. If there is an end routine, all fields in the
end routine's field list are transferred to the data target.
Unit of Measure Conversion and Currency Translation
You can convert data records into the unit of measure or currency of the target
transformation.
0RECORDMODE Calculation for ODP
If the source of your transformation is a DataSource that is supplied with data via an
operational data provider (ODP), and the target is either a DataStore object or InfoObject, you
need the 0RECORDMODErule type Calculation for ODP for the ODQ_CHANGEMODEand
ODQ_ENTITYCNTRsource fields.
This rule type can also be used to calculate the 0RECORDMODEfield. If you load deltas from
an ODP that does not return just one image type (after images, delete images and new images
for example), this change behavior is provided by the ODQ_CHANGEMODEand
© Copyright. All rights reserved.
203
Unit 6: Working with Transformations and Data Transfer Processes (DTP)
ODQ_ENTITYCNTRfields. The 0RECORDMODEfield has to be calculated from these fields for
use in the SAP BW/4HANA system.
Aggregation Type
You use the aggregation type to control how a key figure or data field is updated to the
InfoProvider.
For InfoObjects
Only the Overwrite option is available. With this option, new values are updated to the
InfoObject.
For DataStore Objects
Depending on the type of data and the DataSource, you have the
options Summation, Maximum, Minimum or Overwrite. For numerical data fields, the system
uses characteristic 0RECORDMODEto propose an update type. If only the after-image is
delivered, the system proposes Overwrite. However, it is useful to change this. For example,
the counter data field # Changes is filled with a constant 1, but still has to be updated (using
addition), even though an after-image only is delivered.
Summation
Summation is possible if the DataSource is enabled for an additive delta. Summation is not
supported for the CHAR, DAT, TIMS, CUKY or UNIT data types.
Overwrite
Overwrite is possible if the DataSource is delta enabled.
Note:
The 0RECORDMODEcharacteristic is used to pass DataSource indicators (from
SAP systems) to the update. If you are not loading delta requests to the DataStore
object, or are only loading from file DataSources, you do not need the
0RECORDMODEcharacteristic.
Caution:
When the system updates data, it does so in the chronological order of the data
packages and requests. It is your responsibility to ensure the logical order of the
update. The orders must be requested before deliveries, otherwise incorrect
results may be produced when you overwrite the data. When you update,
requests have to be serialized.
© Copyright. All rights reserved.
204
Lesson: Implementing Transformations
Figure 166: Transformation Rule Type Formula
The transaction for editing transformation rules and update rules offers a transformation
library. You can use this when working with the formula builder.
Note:
When you work with VirtualProviders, do not use formulas, as no inversion is
possible for this. Use routines in this case.
When you use the transformation library together with the formula builder you can create
formulas without the need for ABAP coding.
The transformation library has over 70 pre-defined functions, in the following categories:
Functions for Character Strings
Date Functions
Basic Functions
Mathematical Functions
Suitable Functions
Other Functions
Note:
A type check is not performed for formula. This means the system does not check
if the formula result matches the type of the target field.
© Copyright. All rights reserved.
205
Unit 6: Working with Transformations and Data Transfer Processes (DTP)
You can implement self-defined functions in the transformation library in the formula builder.
You can integrate existing function modules in these self-defined functions. You can make
functions that are not currently contained in the transformation library available for frequent
use.
The formula builder has both standard and expert mode. In standard mode, you can only
enter formulas using the buttons and by double-clicking on functions and fields. In expert
mode, you can enter formulas directly. You can also toggle between the two modes when
entering a formula.
Note:
The procedure, To Create a Formula, shows you the steps and syntax to create a
formula in the Formula Editor .
Figure 167: Time Broadcasting
You can divide calendar month 07.2001 into weeks 26.2001, 27.2001, 28.2001, 29.2001,
30.2001 and 31.2001. Every key figure that can be added receives 1/31 of the original value for
week 26.2001, 7/31 for each of weeks 27,28,29 and 30, and exactly 2/31 of it for week 31.
Time broadcasting always applies to all key figures.
© Copyright. All rights reserved.
206
Lesson: Implementing Transformations
Figure 168: Transformation: Rule Groups
Rule Group
A rule group is a group of transformation rules. It contains one transformation rule for each
key field of the target. A transformation can contain multiple rule groups. Rule groups allow
you to combine various rules. For a characteristic, you can create different rules for different
key figures.
Each transformation initially contains a standard group. Besides this standard group, you can
create additional rule groups. If you have defined a new rule in rule details, you can specify
whether this rule is to be used as a reference rule for other rule groups. If it is used as a
reference rule, then this rule is also used in existing rule groups as a reference rule where no
other rule has been defined.
The source contains the following three date characteristics:
Order date
Delivery date
Invoice date
The target contains one general date characteristic. Depending on the key figure, this is filled
from the different date characteristics in the source. Create three rule groups which,
depending on the key figure, update the order date, delivery date, or invoice date to the
target.
© Copyright. All rights reserved.
207
Unit 6: Working with Transformations and Data Transfer Processes (DTP)
Figure 169: Rules Groups
Figure 170: Rules Groups Example
To Create a Formula
You want to create a formula. The company code field ( 0COMP_CODE) is not included in your
data target or InfoSource. However, you can determine the company code from the first four
character spaces of the cost center ( 0COSTCENTER).
You create the following formula: SUBSTRING( cost center, '0' , '4')
You must use the syntax: SUBSTRING(String, Offset, Length)
© Copyright. All rights reserved.
.
.
208
Lesson: Implementing Transformations
Figure 171: Formula Editor
1. In the transformation library, on the right-hand side under Show Me, choose the
category Strings . From the list, choose the Substring . The syntax of the formula displays in
the formula window: SUBSTRING( , , ).
2. The cursor automatically appears over the first parameter that needs to be specified.
3. From the list on the left-hand side of the screen, choose the Cost Center.
4. Place the cursor where you want to enter the next parameter.
5. Use the Constant button (for the Offset parameter) and enter the number
are added automatically.
0. The commas
6. Place the cursor where you want to enter the next parameter.
7. Use the Constant button (for the Length parameter) and enter the number
4.
8. Choose Back.
The formula is now checked and saved if it is correct. You receive a message if errors
occurred during the check, and the system highlights the erroneous element in color.
LESSON SUMMARY
You should now be able to:
Implement transformations
© Copyright. All rights reserved.
209
Unit 6
Lesson 2
Creating Data Transfer Processes (DTP)
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Implement data transfer processes (DTP)
DTP Details
Figure 172: Extraction Mode and Filter Setting in Data Transfer Process (DTP)
Data Transfer Process (DTP)
A data transfer process (DTP) is an object that determines how data is transferred between
two persistent objects (source and target) in SAP BW.
The data transfer process transfers data within SAP BW from one persistent object to
another, in accordance with certain transformations and filters. You can create a
transformation between the source and the target of the data transfer process. Alternatively,
you can use InfoSources, which do not have persistence, to perform the data transfer process
with several consecutive transformations (a transformation path).
© Copyright. All rights reserved.
210
Lesson: Creating Data Transfer Processes (DTP)
The data transfer process makes the transfer processes in the data warehousing layer
transparent. Optimized parallel processing improves the performance of the transfer process
(the data transfer process determines the processing mode). You can use the data transfer
process to separate delta processes for different targets and you can use filter options
between the persistent objects on various levels, between two DataStore Objects for example.
Data transfer processes are used for standard data transfer, for real-time data acquisition,
and for accessing data directly.
Features of DTP
You use a process chain to define a data transfer process. Alternatively, you can define a data
transfer process for an InfoProvider in an object tree in the Data Warehousing Workbench. We
recommend using process chains. In this case, the data transfer process is executed when it
is triggered by an event in the predecessor process in the process chain. Alternatively, in
process chain maintenance, you can run a data transfer process in the background. A debug
mode is also available.
The request is an instance that is generated at the run time of the data transfer process. The
request is processed in the steps that have been defined for the data transfer process
(extraction, transformation, and filter). The monitor for the data transfer process request
shows the header information, request status, and the status and messages for the individual
processing steps.
With a data transfer process, you can transfer data either in full extraction mode or in delta
mode. In full mode, the entire dataset of the source is transferred to the target; in delta mode,
only the data that was posted to the source since the last data transfer is transferred. The
data transfer process controls delta handling and therefore allows you to fill several targets
with different deltas from one source. With a data transfer process, you do not need to
explicitly initialize the delta method as you do when copying data with an InfoPackage.
The data transfer process helps you to handle data records with errors. When you define the
data transfer process, you can determine how the system responds to errors. At run time, the
incorrect data records are sorted and written to an error stack (request-based database
table). A special error DTP further updates the data records from the error stack into the
target. It is easier to restart failed load processes if the data is written to a temporary storage
after each processing step. It also allows you to find records that have errors. In the monitor
for the data transfer process request, or in the temporary storage for the processing step (if
filled), you can display the data records in the error stack. In data transfer process
maintenance, you determine the processing steps after which you want to store data
temporarily.
If required, you can define a filter criteria for each data transfer process. This means that you
can use multiple data transfer processes with different selection criteria to efficiently transfer
small sets of data from a source into one or more targets, instead of transferring large
volumes of data. You can specify single values, multiple selections, intervals, selections based
on variables, or routines. Choose Change Selection to change the list of InfoObjects that can
be selected. The icon next to the button indicates that predefined selections exist for the data
transfer process. The tool tip for this icon displays the selections as a character string.
© Copyright. All rights reserved.
211
Unit 6: Working with Transformations and Data Transfer Processes (DTP)
Figure 173: Loading Data from SAP HANA to DSO (Advanced)
Figure 174: Create Transformations and Load Transaction Data with DTP Exercise
© Copyright. All rights reserved.
212
Lesson: Creating Data Transfer Processes (DTP)
LESSON SUMMARY
You should now be able to:
Implement data transfer processes (DTP)
© Copyright. All rights reserved.
213
Unit 6
Learning Assessment
1. Why do you implement an InfoSource?
Choose the correct answer.
X
A To store data at the most detailed level
X
B To provide a modeling object that is accessed by queries
X
C To break up transformations into several layers
2. Your dataflow sequence is defined as: DataSource > Transformation > InfoSource >
Transformation > DataStore Object. What is the minimum number of DTPs required to
load the data?
Choose the correct answer.
X
A One
X
B Two
© Copyright. All rights reserved.
214
Unit 6
Learning Assessment - Answers
1. Why do you implement an InfoSource?
Choose the correct answer.
X
A To store data at the most detailed level
X
B To provide a modeling object that is accessed by queries
X
C To break up transformations into several layers
Correct — InfoSources are used to break up transformations into several layers so that
multiple sources and targets are easy to integrate into the dataflow
2. Your dataflow sequence is defined as: DataSource > Transformation > InfoSource >
Transformation > DataStore Object. What is the minimum number of DTPs required to
load the data?
Choose the correct answer.
X
A One
X
B Two
Correct — One DTP is required because they are used to move data from one persistent
layer to the next. InfoSources are not persistent.
© Copyright. All rights reserved.
215
UNIT 7
Operating SAP BW/
4HANA
Lesson 1
Managing DataStore Objects (Advanced)
217
Lesson 2
Creating Process Chains
226
Lesson 3
Managing SAP HANA Delta Merge in SAP BW/4HANA
240
UNIT OBJECTIVES
Managing DataStore objects (advanced)
Create a process chain
Explain SAP HANA delta merge
© Copyright. All rights reserved.
216
Unit 7
Lesson 1
Managing DataStore Objects (Advanced)
LESSON OVERVIEW
This lesson covers administration of the DataStore Object (advanced). This lesson also
covers how to delete and compress requests of a DataStore Object (advanced).
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Managing DataStore objects (advanced)
To Manage DataStore Objects (Advanced)
You can display technical information about the contents of a DataStore object using
the Manage DataStore Object function. You can perform administrative tasks, such as delete
requests. As a prerequisite, the DataStore object must be active.
1. Open your advanced DataStore Object (Advanced) and choose the Manage the DataStore
Object (Advanced) icon.
2. The system displays all requests that are loaded to the DataStore object. You can group
the requests by day, month or year. The status displays as cumulative. The
DM flag
indicates whether the deltas have been updated to other connected InfoProviders. A flag
is not shown for full updates or if an InfoProvider is not connected. The TSNs (transaction
sequence numbers) display in a monotonously ascending order.
3. Choose the request to call the detail view. You can view details about individual load
requests here. You can also view logs and call the monitor.
4. You can activate load requests. To activate multiple load requests using a single activation
request, choose Activate .
5. You can delete load requests. You can delete multiple requests at one time. Load requests
cannot always be deleted. Double-clicking a request to display the details of the request, a
process log and a history.
6. Choose Utilities
Display New Data in the main menu to view the content of the inbound
table. Choose Display Active Data to view the content of the table of active data. Choose
Display Change Log to view the content of the change log.
7. Choose Utilities
Delete Active Data in the main menu to delete data from the active
table, and if required, rebuild the data later. This also applies to the data of the inbound
table and the change log.
© Copyright. All rights reserved.
217
Unit 7: Operating SAP BW/4HANA
DataStore Object (Advanced) Administration
Figure 175: Administration — DataStore Object Type Data Mart
The Manage the DataStore Object (advanced) function allows you to display technical
information about the contents of a DataStore object. You can perform administrative tasks
here, such as delete requests.
© Copyright. All rights reserved.
218
Lesson: Managing DataStore Objects (Advanced)
Figure 176: Activate Requests in a DSO (Advanced) Type Data Mart
Figure 177: Administration — DSO (Advanced) Type Data Mart
During upload of data, a full request will always be inserted into the /BIC/A<ADSO>1 fact
table. Each record gets its own request ID, package ID and record ID. This feature enables
you, for example, to delete a request from the /BIC/A<ADSO>1 fact table after the upload.
However this may result in several entries in the fact table with the same values for all
characteristics except the request ID. This will increase the size of the fact table unnecessarily
© Copyright. All rights reserved.
219
Unit 7: Operating SAP BW/4HANA
and consequently decrease the performance of your queries. During compression, these
records are summarized to one entry and are deleted from the /BIC/A<ADSO>1 table and
moved to the /BIC/A<ADSO>2 table. In the /BIC/A<ADSO>2 table there is no request ID,
package ID and record ID. Once the data has been compressed, it is not possible to display or
delete the data for a specific request ID.
Figure 178: Administration — Delete all Data in DSO (advanced)
By double-clicking on a request, you can call the detail view. You can see details about every
individual load request here. You can also view logs and call the monitor.
You can activate load requests. You can also activate multiple load requests using a single
activation request. To do this, choose Activate .
© Copyright. All rights reserved.
220
Lesson: Managing DataStore Objects (Advanced)
Figure 179: Administration — Delete Request from DSO (advanced) (Model Template Standard DSO)
You can delete load requests and you have the option of deleting multiple requests at one
time. But load requests cannot always be deleted. In a DataStore Object of the type Data
Mart, you can delete requests only if they are not activated. In a DataStore Object of the type
Standard, you are able to roll back requests because the change log is used to find out how
the data looked like before the load so a reversal can be executed.
© Copyright. All rights reserved.
221
Unit 7: Operating SAP BW/4HANA
Figure 180: Administration — Delete Request from DSO (advanced) with Active Delta DTP to Target
If a request has already been loaded to a subsequent target, you cannot delete it. First you
have to delete it from the subsequent target and than you can delete it from the source
InfoProvider.
Figure 181: Administration — DSO (advanced) Selective Deletion
© Copyright. All rights reserved.
222
Lesson: Managing DataStore Objects (Advanced)
Figure 182: Administration — DSO (advanced) Delete Change Log Data
After implementation of the SAP note #2253065 , the RSDSO_REMOVE_REQS_PC
program is
available in your SAP BW on SAP HANA system. This program internally calls Function Module
M, RSDSO_REMOVE_REQUESTS_API
to delete change log requests in batch.
DSO activation on standard DSO
You have performed loads to your DSO. For each load, you will find the following two request
IDs:
Load request (created at the time of loading)
Activation request (created at the time of activation)
If you have more than one DTP load request that is yet to activate, and you have decided to
activate only one request, then this request ID will help to selectively process the records
from the new table to active and change log table.
DSO activation is similar to your DTP load processing, where the new table acts as a source
and your active table and change log table act as targets.
When you select the get delta request by request in DTP settings, the delta requests from the
source are processed one after another and it will create separate request IDs for each run.
SQL Approach
The following list shows the basic SQL operations that are logically performed at the back end
while activating the ODS:
Insert
Update
Delete
© Copyright. All rights reserved.
223
Unit 7: Operating SAP BW/4HANA
Select
Truncate
Rollback takes place when you delete an activate request. The following list looks at each
operation in detail and how it is associated with the record modes:
On Active table, SQL operations such as Insert, Update, Delete and Select are performed.
On Change log table, only Insert operation are performed.
On New table, SQL operations such as Insert, Select, and Truncate are performed.
Active and Change log table Vs. SQL
As already mentioned, when you perform DSO activation, the data is brought from the New
table to Active and Change Log tables.
Note:
Activation of DSO always refers (queries) to the Active table because the change
log is a temporary storage area used for delta mechanism. Some cases, like
selective deletion, only perform on an Active table. The data remains in the change
log but if you load the same data again it creates a new record with the record
mode N and it does not update the old record already present in the change log
table. This indicates that the DSO activation refers to Active table only. To
determine the record mode for the records, initially a Select query triggers on the
Active table before moving the records from the New table. Based on the return
code of select query, the record mode for the change log as well as the type of
SQL operation to be performed on Active table is decided.
Case 1: The return code is NULL
No entries were found in the active table for the record combination (present in New table).
Both the Active and Change log table get an Insert query triggered and the records from the
New table are passed to Active table as well as to the Change log table (with record mode N).
Case 2: If the return code is NOT NULL (the records from source are not reversed or deleted)
Entries have been found in the active table for the record combination (present in the New
table). The following two actions take place:
The Active table gets an Update query triggered to update the modified fields into Active
table.
The Change log table gets an Insert query triggered. The record that already exist in the
active table are inserted with a record mode X (key figures will get multiplied by 'minus').
The record from the new table will be inserted with the record mode " "(BLANK).
Case 3: If the return code is NOT NULL (the records from source with reversed or deletion
Indicator)
Entries have been found in active table for the record combination (present in the New table).
The following two actions take place:
The Active table gets a Delete query triggered to delete or reverse the records from the
Active table.
© Copyright. All rights reserved.
224
Lesson: Managing DataStore Objects (Advanced)
The change log table gets an Insert query triggered. The record that already exist in the
active table are inserted with record mode "X" (key figures will get multiplied by 'minus')
and the record coming from New table is inserted with the record mode D/R .
Figure 183: Delete Or Compress the Requests of a DSO (Advanced) Exercise
LESSON SUMMARY
You should now be able to:
Managing DataStore objects (advanced)
© Copyright. All rights reserved.
225
Unit 7
Lesson 2
Creating Process Chains
LESSON OVERVIEW
This lesson explains process chains and covers how to create a simple process chain.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Create a process chain
Process Chain Creation
A process chain is a sequence of processes that are scheduled to wait in the background for
an event. Some of these processes trigger a separate event that can, in turn, start other
processes.
In an operating BI system, there are a multitude of processes that occur regularly. The
following list shows you what you can do with a process chain:
Process Chain Use
Automate the complex schedules in SAP BW with the help of the event-controlled
processing.
Visualize the processes by using network graphics.
Centrally control and monitor the processes.
© Copyright. All rights reserved.
226
Lesson: Creating Process Chains
Figure 184: Process Chains in the BW Cockpit
The following list gives the fundamental principals of the process chain:
Openness. The abstract meaning of a process as any process with a defined beginning and
end enables openness with regard to the type of process that can be integrated into a
process chain. The principle of openness is applied to the theory behind process chains, in
that both user-defined programs and processes can be implemented. In addition, you can
include process chains in other process chains, known as metachains. In doing so, you are
can integrate process chains from the system in which the metachain is found, or from
other systems. In this context, we are refer to local or remote process chains
Security. Using process chains offers a high amount of process security, which is based on
the following principals of background management:
-
Processes are scheduled before they run and can be monitored with the standard batch
monitor.
-
Background events start subsequent processes.
-
Short dumps and terminations are recognized and handled respectively.
Flexibility. The subsequent process must get all the information it needs for a correct run
from its predecessors. This allows new process types to be integrated without the existing
types having to be adjusted.
Integration
A process chain is a BI object with a transport connection and a connection to the
BI document management.
© Copyright. All rights reserved.
227
Unit 7: Operating SAP BW/4HANA
Figure 185: Network Graphic of a Process Chain
Automatism
If you use process chains, processes (for example, run a data transfer process (DTP) to
update data in a data target, or activate data in the DataStore Object) run in the background
for example, every night at 12:00pm. If you add a specific process in a chain, the system can
add automatically additional, relevant, standard processes.
Figure 186: Event-Controlled Processing by Process Chain
© Copyright. All rights reserved.
228
Lesson: Creating Process Chains
An SAP event is a flag that is created by using the SM62View and Maintain Background Events
transaction. Events are used to trigger the jobs in SAP and it is used to manage the
dependency across multiple jobs without using process chains. An event by itself does not do
anything. Background job needs to be defined and configured to wait for the event. So, use
SM36to create background job, specifying the new event name as the Start Condition
.
New background jobs always can be defined as a periodic job. This allows you to trigger the
job in the future, as opposed to one time only.
Figure 187: Process Chain: Start Process, Application Process, and Collection Process
Start Process Definition
You can define the start condition of a process chain with the start process.
Figure 188: Start Process Variant — Scheduling Option
Start Process Utilization
© Copyright. All rights reserved.
229
Unit 7: Operating SAP BW/4HANA
The background control options are available to directly schedule the start process. You can
start the process chain immediately (when activating the process chain), at a specified time,
or after a particular event. When you activate the process chain the start process is scheduled
in the background, as defined in your selections.
If there are insufficient options available, you can trigger the start of the process chain using
API. You can use the SAP NetWeaver Scheduling Framework to start the chain and to have
more extensive scheduling options. You can also trigger the start of a process chain using a
metachain. If the process chain you set the start condition for is integrated into another
process chain, it is called a metachain. The process chain is started directly by this
metachain.
Note:
If you start the start process using a metachain, it is not scheduled after you have
activated the related process chain. The process is only started once the
metachain that it is integrated into is running.
All other processes in a chain are scheduled to wait for an event.
The start process has the following features:
Only the start process can be scheduled without a predecessor process.
The start process cannot be a successor of another process.
Only one start process is allowed for each process chain.
A start process can only be used in a single process chain.
If you want to define more than one start condition to execute a process chain or part of a
process chain, use the interrupt process as well as the start process.
Application Process Definition
Application processes are processes that you want to automate in process chain
maintenance. They represent activities typically performed in the operative use of SAP BW.
Table 4: Application Processes Supported by Process Chain Maintenance
Application processes are processes that you want to automate in process chain
maintenance. They represent activities typically performed in the operative use of SAP BW.
Process Category
Load process and postprocessing
Application Process Type
Delete overlapping requests from the DataStore object (advanced)
Data transfer process
Set quality status / data release
Trigger delta merge
Start SAP HANA remote subscription
© Copyright. All rights reserved.
230
Lesson: Creating Process Chains
Process Category
Application Process Type
Data target administration
Activate requests in DataStore Objects (advanced)
Delete all data target content
Archive data from a DataStore object
Scheduling Data Archiving Processes Using Process Chains
Clean up old requests from the DataStore object (advanced)
Other SAP BW processes
Replicate authorizations of SAP BW users to SAP HANA
Execute SAP HANA analysis process
Execute planning sequence
Switch aDSO to plan mode
Switch aDSO to load mode
Other
Job in SAP CPS
Event in SAP CPS
Creating Database Statistics for Virtual Tables
You can also develop your own reusable, custom processes using ABAP.
Collection Process Definition
A collection process collects several chain strings to form one string in the process chain
maintenance.
Figure 189: Maintenance of Process Chains
© Copyright. All rights reserved.
231
Unit 7: Operating SAP BW/4HANA
Collection Process Utilization
Process chain management handles collection processes in a particular way. The system
makes the variant names consistent and guarantees that all processes of the same name that
have been scheduled more than once, trigger the same event. This enables the several chain
strings to be collected to form one and also makes multiple-scheduling of the actual
application processes unnecessary.
The following collection processes are available in the process chain maintenance:
And Process (Last)
This process does not start before all events of the predecessor processes, that is
including the last event, that it has waited for, have been successfully triggered. Use this
collection process when you want to combine processes and when further processing is
dependent on all these predecessors.
Or Process (Every)
The application process starts every time a predecessor process event has been
successfully triggered. Use this collection process when you want to avoid multischeduling the actual application process.
XOR Process (First)
The application process starts when the first event in one of the predecessor processes
has been successfully triggered. Use this collection process when you want to process
processes in parallel and schedule further independent processes after these ones.
Figure 190: SAP Supplied Processes
© Copyright. All rights reserved.
232
Lesson: Creating Process Chains
Figure 191: Structure of a Process (Design Time, Run Time) with Example Execute Data Transfer Process
A process in the context of process chains is a procedure inside, or external to, an SAP
system with a defined beginning and end. A distinction is made between a start process, an
application process, and a collection process.
To automate runs in SAP BW, processes are brought together in process chains. The
processes are scheduled in the background. Each process can trigger one or more events, in
turn other processes are triggered.
A process is characterized in the following ways:
The process type
A load process is an example of a process type. The process type decides which tasks the
process has and which properties it has in the maintenance. The process type is set in the
RSPROCESSTYPESview. For more information, see Maintenance of Process Types .
The process variant
The process variant is the name of the process. Within the process chain context, it
displays the configuration of a process of a particular type set at the time of definition. A
variant is only consistently defined together with the process type. A process can have
various variants. During the load process, for example, an InfoPackage represents a
process variant. The user defines the process variant at the time the process is scheduled.
With some process types, the variants are determined internally and are stored as GUIDs.
The process instance
The process instance is the characteristic value of the process. It contains the most
important information that the process, or subsequent processes wants to communicate.
For example, in the load process, this is the name of the request. If the process is ended,
the instance is transferred to the process chain management and saved. The logs for the
© Copyright. All rights reserved.
233
Unit 7: Operating SAP BW/4HANA
process are stored under the process instance. The instance is determined by the process
itself at run time, and is normally determined consistently, independent of time or system.
Work environment for monitoring process chains
Environment scenario
More information
Monitoring of Periodic Process Chains (Transaction
RSPCM
)
With transaction RSPCMyou
monitor the last run of selected process chains in an SAP
BW system. Use this transaction to regularly check the
status of the current runs for
selected process chains. You
can navigate to the detailed
log view for a process chain
run from here.
Monitoring Current Runs of
Periodic Process Chains
App for process chain monitoring
With the app for process
chain monitoring, you can
monitor the last run of selected process chains in an SAP
BW system. On your mobile
device, you can use the app
for process chain monitoring,
to check the status of process chains, analyze errors,
and repeat any failed processes or send e-mails about
errors.
App for Process Chain Monitoring
Log view for runs of a process You go to the log view of
chain in process chain mainprocess chain maintenance
tenance (transaction RSPC)
from the process chain maintenance (transaction RSPC)
or process chain maintenance for a given process
chain (transaction RSPC1).
You check the logs for process chain runs here. Use this
transaction to display one or
more runs for a process
chain in the log view.
Process Chain Maintenance
for a Given Process Chain
Run (Transaction RSPC1)
© Copyright. All rights reserved.
Process Chain Log Display
Use this transaction to call
the log view for this run by
specifying the log ID of a concrete process chain run.
234
Lesson: Creating Process Chains
Work environment for monitoring process chains
Environment scenario
More information
BW Monitor in the Computing
Center Management System
(CCMS
)
The Alert Monitor of the CCMS BW Monitor in CCMS
displays the runs for a given
time and the relevant status
information for process
chains. Use the BW Monitor
in the CCMSto monitor your
system landscape centrally
and globally, and to apply external monitoring tools.
Technical Contents
The technical content provides you with objects for
evaluating the process chain
status. Use the technical content to report about the status of the process chains (for
example in a service contract
as administrator) or to use
custom dashboards for global monitoring of your system
landscape.
Technical Content in the BW
Administration Cockpit
Figure 192: Maintenance of Process Chains — Object Trees
You can define the start condition of a process chain by using a start process. The
background control options are available to schedule the start process directly. You can start
the process chain immediately (when activating the process chain), at a specified time, or
© Copyright. All rights reserved.
235
Unit 7: Operating SAP BW/4HANA
after a particular event. When you activate the process chain the start process is scheduled in
the background, as defined in your selections.
If there are not sufficient options available, you can trigger the start of the process chain using
API. Use the RSPC_API_CHAIN_STARTfunction module. The SAP Scheduling Framework can
be used to start the chain using the API and has more extensive scheduling options. You can
also trigger the start of a process chain using a metachain. If the process chain that you set
this start condition for is integrated into another process chain, this is called a metachain. The
process chain is started directly by this metachain.
All other processes in a chain are scheduled to wait for an event.
The start process has the following special features:
Only the start process can be scheduled without a predecessor process.
The start process cannot be a successor of another process.
Only one start process is allowed for each process chain.
A start process can only be used in a single process chain.
If you want to define more than one start condition to execute a process chain or part of a
process chain, use the interrupt process and the start process.
Figure 193: Example of Maintenance of Process Variants
© Copyright. All rights reserved.
236
Lesson: Creating Process Chains
Figure 194: How to Schedule a Process Chain
Process Chain RunsApp
You can check process chain runs and start new runs in the Process Chain Runs app.
In the log view, you get information about the time of creation, change, or activation as well as
about the chain runs displays. Symbols display the status of the runs. Yellow indicates that
the chain is active, green that the chain ended successfully, red that the chain ended with
errors or was terminated.
You can re-select the log for this process chain by choosing Go to
Other Log (on the
toolbar of the process chain maintenance). The system updates the overview of the process
chain runs according to your time selection. The system also refreshes the status of the runs.
© Copyright. All rights reserved.
237
Unit 7: Operating SAP BW/4HANA
Figure 195: Monitoring of Process Chain Runs — Error Analysis
Figure 196: Monitoring of Process Chain Runs — Repair/Repeat Processes
You can restart any chain process (instance) that was terminated, this in turn ends the chain
run. The process can be repeated either automatically or manually.
Depending on the process type, you can start a process in the following two ways:
© Copyright. All rights reserved.
238
Lesson: Creating Process Chains
A process can be repaired and the terminated instance is executed again. This enables you
to restart processes that cannot be repeated with a new instance, because the data to be
edited is attached to the instance, as with a data transfer process. A data transfer process,
for example, cannot be repeated with a new request number, because the data itself is
attached to the request.
A process can be repeated. In this case, a new instance is created.
Restarting a process in a process run can either be controlled manually in the log view
(process chain maintenance screen), or the restart can be automated by using the options in
the plan view (process chain maintenance screen).
Prerequisites
You can restart a terminated process, if this is possible for the process type. In the plan view
of process chain maintenance you can set whether a process can be repaired or repeated
when terminated. Go to Settings
Maintain Process Types (in the RSPROCESSTYPEStable).
Caution:
Do not change the settings for the SAP process types. This can lead to
inconsistencies in the data handled by the process.
LESSON SUMMARY
You should now be able to:
Create a process chain
© Copyright. All rights reserved.
239
Unit 7
Lesson 3
Managing SAP HANA Delta Merge in SAP BW/
4HANA
LESSON OVERVIEW
This lesson explains SAP HANA delta merge, its advantages, and how to perform a delta
merge.
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Explain SAP HANA delta merge
SAP HANA Delta Merge in SAP BW/4HANA
Figure 197: SAP HANA — Insert Only on Delta
The column store uses efficient compression algorithms that keep all relevant application
data in memory. Write operations on this compressed data are costly, as they require
reorganizing the storage structure. Updating and inserting data into a sorted column store
table is a very costly activity, as the sort order has to be regenerated and thus the whole table
is reorganized each time. SAP has addressed this challenge by separating these tables into a
main storage (read-optimized, sorted columns) and delta storages (write-optimized, non
sorted columns or rows). All changes go into a separate area called the delta storage. The
© Copyright. All rights reserved.
240
Lesson: Managing SAP HANA Delta Merge in SAP BW/4HANA
delta storage exists only in main memory. Only delta log entries are written to the persistence
layer when delta entries are inserted. There is a regular database activity which merges the
delta storage into the main storage. This activity is called delta merge. The following graphic
shows the different levels of data storage, and distinguishes the main storage from the delta
storage.
Figure 198: Phases of the Delta Merge
If you are using an SAP HANA database, data modifications are initially saved in a delta
storage that is optimized for write access. The modifications are transferred to the main
storage by a delta merge. Data modifications are initially stored in the database in a delta
storage optimized for write access. Most of the data is saved in a highly compressed format in
the main storage, however, it is optimized in terms of required memory space and read
performance. A delta merge is used to transfer modifications from the delta storage to the
main storage. First, an asynchronous check is performed for see whether a delta merge is
required.
The check and the delta merge, if data has been changed during Data Warehouse load
processes, are either performed automatically by the system or must be triggered manually.
This depends on the following object types:
The data transfer process (DTP) has an Update tab that contains the Trigger Database
Merge checkbox. This controls the delta merge, once the DTP request has been
successfully processed. This checkbox is selected in the default setting.
For DataStore objects (advanced), the Trigger Database Merge checkbox is selected by
default. After activation, an automatic check is run to ascertain whether a delta merge can
be performed.
© Copyright. All rights reserved.
241
Unit 7: Operating SAP BW/4HANA
Figure 199: Delta Merge Management in SAP BW
Triggering Delta Merge via Process Chain
In exceptional cases, performing a delta merge after processing a DTP request is not
recommended, due to load balancing issues. In this case, an alternative method triggers the
delta merge via a process type.
Context
In exceptional cases only, which result in load distribution problems, we recommend
deselecting the checkbox in the DTP and using the Trigger Delta Merge process type to trigger
the delta merge. An example of this is an object that data is loaded into from multiple sources.
The delta merge check is only performed at the end of the entire loading process.
Note:
Make sure that the DTP or process type always triggers a delta merge. If no delta
merge takes place, the data remains in delta storage. Over time, this results in
storage problems and has a negative impact on read performance.
You are in the plan view of the process chain where you want to include the process. The
Process type Trigger Delta Merge is available in the Load Process and Post-Processing
process category. The following steps show you how to carry out this task:
1. Drag and drop the Trigger Delta Merge process type to a suitable position in the process
chain.
2. A dialog box appears. To create a new process variant, choose the Page button.
3. Enter a name and a description for the process variant and choose the
© Copyright. All rights reserved.
Check button.
242
Lesson: Managing SAP HANA Delta Merge in SAP BW/4HANA
4. On the process variant maintenance screen, specify the type and name of the object for
the delta merge.
5. Save your entries and return to the plan view for the process chain.
6. Link the process to the required loading processes.
Figure 200: Delta Merge — Before and After
If you use an SAP HANA database, data modifications are initially saved in a delta storage that
is optimized for write access. However, most of the data is saved in a highly compressed
format in the main storage, which is optimized in terms of required memory space and read
performance. A delta merge is used to transfer modifications from the delta storage to the
main storage. First, an asynchronous check is performed to see whether a delta merge is
required. If a threshold value is exceeded, the merge is carried out in the delta storage. When
a read access is executed, the data is read from the main storage and the delta storage and
the results are merged together.
The check and the delta merge, if data has been changed during Data Warehouse load
processes, are either performed automatically by the system or must be triggered manually.
This depends on the relevant object type as shown in the table.
Table 5: Delta Merge
The check and the delta merge, if data has been changed during Data Warehouse load
processes, are either performed automatically by the system or must be triggered manually.
This depends on the relevant object type as shown in the table.
© Copyright. All rights reserved.
243
Unit 7: Operating SAP BW/4HANA
Object Type
Delta Merge
DataStore Object type Standard
After activation, an automatic check is run to
see whether a delta merge can be performed.
This also applies to DataStore objects that
belong to a semantically partitioned object.
DataStore Object type Staging
The check and the delta merge are not performed automatically. This also applies to
objects that belong to a semantically partitioned object. The data transfer process
(DTP) has an Update tab that contains the
Trigger Delta Merge checkbox. This controls
the delta merge, once the DTP request has
been processed. This checkbox is selected in
the default setting.
Figure 201: Perform an SAP HANA Delta Merge in SAP BW/4HANA Exercise
LESSON SUMMARY
You should now be able to:
Explain SAP HANA delta merge
© Copyright. All rights reserved.
244
Unit 7
Learning Assessment
1. For a DataStore Object of type Data Mart, you can only delete requests if they have not
already been activated.
Determine whether this statement is true or false.
X
True
X
False
2. What is a process variant?
Choose the correct answer.
X
A A sequence of job steps used to load data to SAP BW/4HANA
X
B A log generated once the process chain has ended
X
C An alternative path in a process chain that executes under certain conditions
X
D A specific configuration of an individual job step in a process chain
3. What happens if you do not run an SAP HANA delta merge?
Choose the correct answers.
X
A Read performance of InfoProviders decreases
X
B Data is not tracked for changes
X
C Storage requirements increase
X
D You cannot combine calculation views and InfoProviders
© Copyright. All rights reserved.
245
Unit 7
Learning Assessment - Answers
1. For a DataStore Object of type Data Mart, you can only delete requests if they have not
already been activated.
Determine whether this statement is true or false.
X
True
X
False
Correct — For a DataStore Object of type Data Mart, you can only delete requests if they
have not already been activated
2. What is a process variant?
Choose the correct answer.
X
A A sequence of job steps used to load data to SAP BW/4HANA
X
B A log generated once the process chain has ended
X
C An alternative path in a process chain that executes under certain conditions
X
D A specific configuration of an individual job step in a process chain
Correct — A process variant is a specific configuration of an individual job step in a
process chain
3. What happens if you do not run an SAP HANA delta merge?
Choose the correct answers.
X
A Read performance of InfoProviders decreases
X
B Data is not tracked for changes
X
C Storage requirements increase
X
D You cannot combine calculation views and InfoProviders
Correct — If you do not run an SAP HANA delta merge then the read performance of
InfoProviders decreases and storage requirements increase
© Copyright. All rights reserved.
246
UNIT 8
Glossary
Lesson 1
Glossary
248
UNIT OBJECTIVES
Understand the key terms used with SAP BW/4HANA
© Copyright. All rights reserved.
247
Unit 8
Lesson 1
Glossary
LESSON OBJECTIVES
After completing this lesson, you will be able to:
Understand the key terms used with SAP BW/4HANA
LESSON SUMMARY
You should now be able to:
Understand the key terms used with SAP BW/4HANA
© Copyright. All rights reserved.
248
Glossary
Analysis Authorization
Security object used to define data access rules
for reporting users
Application Component
Object used to organize DataSources so that they
are easy to find using a hierarchical structure
Attribute
Used to provide additional descriptive information
of a characteristic, such as telephone number of
an employee, and is used to provide the reporting
user with useful information
Badi Provider
An InfoProvider that is developed using ABAP
code and is used as a virtual data source when a
standard InfoProvider does not fit the
requirements
BW Project
A BWMT object used to manage all data flow and
modeling objects for exactly one SAP BW/4HANA
instance, and also stores connectivity information
between the BW Modelling Tools in Eclipse to your
SAP BW/4HANA application and its associated
SAP HANA database
BW Query
Built on top of an InfoProvider to define the key
elements of a report, such as which
characteristics and key figures are allowed, filter
values and default row and column layout
BW Workspace
Agile data modeling environment used by
business user to develop their own ad-hoc data
models within the SAP BW/4HANA system
BW/4HANA Cockpit
SAP Fiori-based interface for all administration
activities, such as scheduling data loading, data
load monitoring, cleaning up logs, and so on
BWMT
BW Modelling Tools for Eclipse — The tooling that
was developed by SAP and integrated into Eclipse
for all your SAP BW/4HANA development
Calculated Key Figure
A query object whose value is generated at runtime from a defined formula such as ‘profit
contribution %’
The main multi-purpose modeling object for
native modeling in the SAP HANA database and
this can be consumed by SAP BW/4HANA
InfoProviders
Characteristic
One of the types of InfoObject used to model
business entities, such as product or customer,
and provides the essential technical and business
metadata such as data type, length, text lengths,
and can optionally store master data
CompositeProvider
Modeling object used to develop the virtual layer
using unions and joins of other InfoProviders and
is consumed by queries
Compound
A modeling technique to combine two or more
characteristic InfoObjects to create unique values.
For example, the COST CENTRE characteristic
‘Cafeteria’ does not identify which cafeteria, but
when compounded with the COUNTRY
characteristic value ‘France’, we create ‘France
Cafeteria’
DataFlow
Used to define the entire end-to-end sequence of
objects across all layers both physical staging and
virtual layers and is useful to help with
visualization and navigation of complex flows
DataSource
Objects used to create the inbound data layer and
are based on fields from the source systems. For
SAP source these are created in the source
system and replicated to SAP BW/4HANA
DataStore Object (Advanced)
Multi-purpose modeling object used to store
transaction data and is used in data flows across
the various staging layers with its advanced delta
handling features
DTP
Data Transfer Process — a scheduling object used
to define the data loading parameters such as
filters, packet size, and error handling rules
Extension Node
Component of SAP HANA platform used to
manage warm data temperature of SAP BW/
4HANA
Calculation View
© Copyright. All rights reserved.
249
Hierarchy
Used to developed a drill-down model used in
reporting tools that is based on SAP BW/4HANA
data
Operational Delta Queue — The delta queue
component of the ODP framework where new
records generated in the source system are held
awaiting extraction to SAP BW/4HANA
InfoArea
Open Hub
Object used to organize InfoProviders, BW Queries,
InfoObjects in a hierarchical structure
The component of SAP BW/4HANA that handles
data distribution from SAP BW/4HANA to external
target systems
InfoObject
Used to define the metadata of entities such as
customer, revenue, year. There are four types of
InfoObject: characteristic, key figure, unit, and time
InfoProvider
Open ODS View
Used to define a virtual data model that by-passes
data staging and is defined using fields and not
InfoObjects
The umbrella term used to describe any provider of
data to a query, such a CompositeProvider,
DataStore Object, ODS View
Process Chain
InfoSource
Replicate
Used in the data flow to create a non-persistent data
staging hub to collect one or more data sources of
inbound data that can then be distributed to one of
more data targets with different data transformation
rules
After defining a DataSource in an SAP source
system, you need to replicate it to SAP BW/4HANA
using a built in tool so that the data flow can be
completed in SAP BW/4HANA
Key Figure
One of the four types of InfoObject and is used to
define a measure such as revenue, cost, quantity
A unique generated wrapper used to identify each
individual data load and can easily be tracked to see
where and how it has been used in SAP BW/4HANA
LSA++
Restricted Key Figure
Layered Scalable Architecture — best practice
modeling blueprint develop by SAP to guide
customers to building a sustainable and efficient
data warehouse with SAP BW/4HANA
A query object that is based on a standard key figure
and applies one or more filter values, an example
could be ‘Planned Quantity version 2.3’
Navigation Attribute
Smart Data Access — Component of SAP HANA that
provides real time access to external data sources
and can be leveraged by BW/4HANA to provide a
live connection to a large number of data sources
where no data persistency in BW/4HANA is required
An attribute that has been enabled to allow the
business user to use it for filtering, sub-totals and
drill-down in a report
NLS
Near Line Storage — Component of SAP BW/
4HANA that provides a permanent connection from
SAP BW/4HANA to an archive data store such as
Hadoop for cold data temperature management
ODP
A sequence of job steps used to automate the
loading of data to SAP BW/4HANA
Request
SAP HANA SDA
SAP HANA SDI
Smart Data Integration — ETL tooling that is part of
SAP HANA but can be leveraged by SAP BW/4HANA
to extract data from non-SAP sources in real-time or
batch with optional data transformations
Operational Data Provider — A data source that is
setup as an ODP in the source system can be
consumed by SAP BW/4HANA using the ODP type
source systems
SAP HANA SDQ
ODQ
SAP HANA Studio
© Copyright. All rights reserved.
Smart Data Quality — An extension of SAP HANA
SDI to add data cleansing and enrichment
capabilities to the data flow
250
The name given to Eclipse IDE when used in the
context of SAP HANA native development (not
SAP BW/4HANA development)
Semantic Group
Modeling object used to define data partitioning
logic to improve reporting performance
SID
Surrogate ID — Every characteristic value used in
reporting has one of these to accelerate reporting
navigation by substituting the external
characteristic value (for example, England) with a
4 byte integer internal value (for example, 2834)
that is much quicker to process than variable
length string values. They are generated and
managed internally by SAP BW/4HANA and are
not exposed to the business user
Transformation
An object in the data flow that defines the rules
used to map and transform data from one data
staging layer to the next
Variable
A query object that defines a placeholder for a
filter whose value cannot or should not be fixed in
the query, and instead should be entered or
generated at run-time of the query
© Copyright. All rights reserved.
251
© Copyright. All rights reserved.
252