Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 34

S/4HANA Deep Dive Session

Data Model Changes in SD


23rd Jan 2018
Agenda
• SAP S/4 HANA High level Database
• Columnar data storage
• Parallel processing
• Simplifying application
• Key Functionalities: Simplified data model
• Simple data model diagram
• Comparison
• Sales order in S/4 HANA
• CDS Views
• Advantages from Simplified data model
• Appendix: SAP SD data model
• Q&A
2
SAP S/4 HANA High level Database
• SAP S/4 HANA is an in-memory data platform that can be deployed on premise or on demand.
• SAP S/4 HANA can make full use of the capabilities of current hardware to increase application
performance, reduce cost of ownership, and enable new scenarios and applications that were not
previously possible.
• SAP S/4 HANA runs on multi-core CPUs with fast communication between processor cores, and containing
terabytes of main memory
• S/4 HANA has Columnar Data Storage
• A database table is conceptually a two-dimensional data structure organized in rows and columns.  SAP S/4
HANA supports both, but is particularly optimized for column-order storage

3
Columnar Data Storage
 Columnar data storage allows highly efficient compression. If a column is sorted, often there are repeated
adjacent values. SAP HANA employs highly efficient compression methods, such as run-length encoding,
cluster coding and dictionary coding.
 Columnar storage, in many cases, eliminates the need for additional index structures. Storing data in
columns is functionally similar to having a built-in index for each column. The column scanning speed of the
in-memory column store and the compression mechanisms allow read operations with very high
performance

4
Parallel Processing
• SAP S/4 HANA is designed to perform its basic calculations, such as analytic joins, scans and aggregations in
parallel. Often it uses hundreds of cores at the same time, fully utilizing the available computing resources of
distributed systems.
• Column-based storage also allows execution of operations in parallel using multiple processor cores. In a
column store, data is already vertically partitioned. This means that operations on different columns can easily
be processed in parallel. If multiple columns need to be searched or aggregated, each of these operations can
be assigned to a different processor core. In addition, operations on one column can be parallelized by
partitioning the column into multiple sections that can be processed by different processor cores.

5
Simplifying Applications
• SAP S/4 HANA makes it possible to calculate aggregates on large amounts of data on-the-fly with high
performance. This eliminates the need for materialized aggregates in many cases, simplifying data models,
and correspondingly the application logic.
• Furthermore, with on-the fly aggregation, the aggregate values are always up-to-date unlike materialized
aggregates that may be updated only at scheduled times.

6
Key functionalities: Simplified Data Model

Status Tables • Elimination of VBUK and VBUP

Addition of new fields • 79 fields in VBAK and 97 in VBAP

Simplified VBFA • Addition & Elimination of fields

Field length extension • SD doc category from Char 1 to 4

• Elimination of redundancies from VAKPA, VAPMA


Document Index Tables
etc.

Pricing • Table KONV is replaced by PRCD_ELEMENTS


Simplified Data Model in Pricing and Condition Technique

• Replacement of table KONV with the new table PRCD_ELEMENTS as data persistency for pricing
results.
• KONV is and can still be used for data declaration purposes. It still defines the structure of the
pricing result within the application code.
• The concatenated variable key field VAKEY of a condition table has been removed from all
condition header tables, including
– KONH (pricing),
– NACH (output determination),
– KOND3 (campaign determination),
– KONDN (free goods determination),
– KONHM (portfolio determination),
– J_3GPRLHD (CEM price list determination), and
– WIND (document index). The concatenated variable data field VADAT has also been removed.
• Several field length extensions are applicable in the new data model
8
Simplified Data Model in Pricing and Condition Technique

• Business Impact
– No impact on the standard SAP business processes
– The SAP internal program logic has been adapted to the new persistency and the new field lengths.
– Pricing results of existing documents created before the system conversion (that is, the content of
table KONV) are converted as part of the system conversion and transferred automatically to the
new data table.
– It might be required to adapt custom code that is related to the changed data model.
– Customer code has to be adapted according to the cookbooks in SAP Note 2220005.

9
Simple data model diagram

10
Comparison

 VBUK and VBUP are still present in S/4 HANA but they are not filled when an order is created.
 The status fields have been added through append structure.
 An append field to the document header status table VBUK must be added to one or several of the document
header tables VBAK, LIKP, or VBRK. This decision depends on which of the document types the respective field
is relevant for.
 An append field to document item status table VBUP must be added to one or more of the document item
tables VBAP or LIPS.
Table Name Description Append Name

VBAK Sales Order Header VBAK_STATUS

VBAP Sales Order Item VBAP_STATUS

LIKP Delivery Header LIKP_STATUS

LIPS Delivery Item LIPS_STATUS

VBRK Billing Document Header VBRK_STATUS


11
Display Table
VBAK:

VBAP:

12
Sales order in S/4 HANA
Sales order in S/4 HANA System:

VBAK table contains both the header details as well as the header status:

Header status fields are now added to VBAK table:

13
Sales order in S/4 HANA
VBUK / VBUP are still present in S/4 HANA:

ut of document header tables. Thenot
Since the status tables are data is fetched
being filled depending upon the document
it can be questioned why thetype.
tables are still present and not
removed from system altogether. The reason for this is to enable smooth transition for those opting for
migration to S/4 HANA system.
 New function modules have been written which read the document status fields from VBAK , LIKP, VBRK
tables and populate in output whose structure is similar to that of VBUK.

14
Advantages from Simplified data model
• Reduced memory footprint: since the fewer tables are involved this means reduction of redundant data and
simplified document flow.
• Now if we need to query the order table on the basis of document status we can simply do so by single query
on VBAK table instead of join on VBAK and VBUK.
• Increased performance of HANA queries
• Functional scope enhancement through extended field lengths

15
Virtual Data Model (VDM)
• A virtual data model (VDM) is a structured representation of HANA database views used in SAP HANA Live for SAP Business
Suite and follows consistent modeling rules.
• SAP HANA Live is a Virtual data model on top of suite tables which uses native SAP HANA SQL views called Calculation
views for real-time operational Reporting.
• A virtual data model consists of the following types of views:
– Query views
– Reuse Views
– Private Views
– Value Help Views

• Issue with using VDM were -


– This model didn’t support hierarchies properly. Hierarchies help businesses to analyze their data in a tree structure through
different layers with drilldown capability. For example, a time hierarchy consists comprises of levels such as fiscal year, fiscal
quarter, fiscal month and so on.
– Since, the HANA Live virtual data models were defined in the HANA database layer itself as HANA calculation views it led to
duplication of security roles between Business Suite for transactional processing and HANA database for operational reporting.

16
Virtual Data Model (VDM)

17
Virtual Data Model (VDM)

18
Virtual Data Model (VDM)

19
Virtual Data Model (VDM)

20
CDS Views

21
CDS Views

22
ABAP CDS Views
• Core Data Services are used to build design-time data-persistence models”
• It is an infrastructure that can be used by database developers to create the underlying (persistent) data
model which the application services expose to UI clients.
• With CDS, data models are defined and consumed on database server rather than on application server
• CDS simplifies and harmonizes the way you define and consume your data models, regardless of the
consumption technology.
• Technically, it is an enhancement of SQL which provides you with a data definition language (DDL) for defining
semantically rich database tables/views (CDS entities) and user-defined types in the database.

23
ABAP CDS Views – Value Proposition
Semantically rich data • CDS builds on the well-known entity relationship model and is declarative in nature, very close to
conceptual thinking. 
models 

Compatibility across any • CDS is generated into managed Open SQL views and is natively integrated into the SAP HANA layer.
These views based on Open SQL are supported by all major database vendors 
database platform 

• CDS offers a variety of highly efficient built-in functions — such as SQL operators, aggregations, and
Efficiency expressions — for creating views. 

• The CDS syntax supports domain-specific annotations that can be easily evaluated by other
Support for annotations.  components, such as the UI, analytics, and OData services. 

Support for conceptual • CDS helps you define associations that serve as relationships between different views. Path expressions
can be used to navigate along relations. Introducing an abstraction of foreign key relationships and joins,
associations associations make navigation between entities consumable

• Customers can extend SAP-defined CDS views with fields that will be automatically added to the CDS
Extensibility.  view along with its usage hierarchy.
24
ABAP CDS Views - Example
• Fiori App Manage Customer Returns – uses CDS view to select the data for Creating Customer Return
• The reference documents for the Customer Returns Application are found in the CDS view CRETSREFDOC.

25
ABAP CDS vs. HANA CDS

• HANA CDS can function only on SAP HANA while ABAP CDS is open
• ABAP CDS uses Restricted ABAP but no such restrictions for HANA CDS
• A good example are built-in functions. A built-in function like CURRENCY_CONVERSION offered in ABAP
CDS must be available on any database platform and  – very important – must behave in the same way
on all platforms
• ABAP specialties like client handling or table buffering that are not available in HANA CDS, but supported in
ABAP CDS.

26
Appendices: SAP SD Data model

27
Appendices: SAP SD Data model

28
Appendices: SAP SD Data model

29
Appendices: SAP SD Data model

30
Appendices: SAP SD Data model

31
Appendices: SAP SD Data model

32
Appendices: SAP SD Data model

33
Thank you! – Any Questions?

34

You might also like