SAP S/4HANA Embedded Analytics Architecture and Integration: Part 1

Rakesh12 · ‎2024 Jul 25

SAP S/4HANA Embedded Analytics Architecture and Integration: Part 1

SAP S/4 HANA Embedded Analytics architecture comprises of 4 layers ,namely

Persistency layer
Modeling layer
Access layer
Visualization layer

In this blog I will be emphasizing more on persistency and modeling layer.

This section explains the building blocks that are part of the business reporting architecture and technical architecture. Building blocks such as persistency layer, modeling layer , access layer, and visualization layer are part of the business reporting architecture and building blocks : SAP S/4HANA backend system ,SAP S/4HANA frontend HTML5,and SAP Fiori frontend server.

Business Reporting Architecture

Let’s have a look at the business reporting architecture with the SAP S/4HANA

Embedded analytics and SAP FIORI UI. There are main 4 layers in SAP S/4HANA:

Persistency layer : This layer refers to all the database tables of SAP S/4HANA . HANA is the native in memory database used to store all the application tables in SAP S/4HANA for online analytical processing (OLAP) and online transaction processing(OLTP).
Modelling layer: This layer refers to all the ABAP core data services (CDS) views that are built on the top of the database tables. This tables in S/4HANA are exposed as virtual data models(VDMs) . VDM is intended to be interpreted by view browsers and other functionality which is based on the virtual data model.so, these views can be consumed directly by rich client UIs(such as Fiori tile, SAP Business objects )without any additional software layer.

Before moving to VDM view types and Data Category we need to know about Annotations . which is very much important in embedded analytics.

Annotation : which defines the technical and semantic attributes of a CDS object. It provides metadata for a filed/view which is understandable by different run time frameworks eg. Analytic Framework. Annotation can be further categorized into

View Annotations :For the entire CDS view ,placed in front of the DEFINE VIEW statement.
Element Annotations: For elements in the projection list ,placed in front of or after the element.
Parameters Annotation: for parameterized CDS view , placed in front of or after the parameter.
Extension Annotations: for CDS view extension ,placed in front of the extend view statement.

Some of the important annotations :

@Abapcatalog.sqlViewName:’XXX’ :Auto creates SQL view corresponding to CDS view with the given name ‘XXXX’

@Abapcatalog.preserveKey:true :preserve key true ignores defaults keys from the database table/view and preserves keys defined explicitly in the view. possible values –true /false

@Accesscontrol.authorizationCheck:#check: Tells whether an authorization check should be performed or not.

@EndUserText.label:’xxxx’:It’s a free text which provides info to the end user.Maximum length would be 40 characters.

@AbapCatalog.compiler.compareFilter:true: Defines the evaluation of filter conditions in path expressions of the CDS view.

Furthermore few annotations will be discussed under VDM view types and Data category.

VDM view types and Data Category :

Basic View : Basic view is created on top of the HANA database

@VDM.viewType: #BASIC

Composite View : on top of basic view we will create a composite view. Here the source of the composite view is Basic view. Composite view cannot access directly from the database table.

@VDM.viewType: #COMPOSITE

Consumption View : consumption view is the final view which is created on top of the composite view. This consumption view is accessed by UI Applications and other tools.

@VDM.viewType: #CONSUMPTION

Data Category : which is going to define the data based on the business requirement. Data Category has 3 types

Dimension : otherwise called as basic view which represents the master data e.x : Material Master ,customer Master etc

@analytics.dataCategory:#DIMENSION

Fact : Represents Transaction data which contains Measures.

Should not be joined with master data views.

@analytics.dataCategory:#FACT

Cube: cube is also nothing but a transaction data but it can be mapped with Master data. Also contains measures. consumption views are built on top of the cube.

@analytics.dataCategory:#CUBE

Associations and joins are the two main topics to be known in embedded analytics.

Associations:

Associations are having similar functionality of joins to fetch data from multiple tables based on join condition ,but they are ‘joins on-demand’ which means they will only be triggered when user would access the required data which needs the association of required tables.

Associations are defined with ‘cardinality’.syntax:association[<cardinality>]

0..1
0..n or 0..*
1..0
1..n or 1..*

n should be an integer(non-zero),this basically establishes the relationship between the source and target table.

Here the source table is vbak and the target table is vbap which are associated together with cardinality 1..* which means ,for every one record in vbak with vbeln (on condition filed)there can be a minimum of 1 record and a maximum of n(*) records in vbap with vbeln (on condition filed).

If we are confused about what kind of association, we should configure in the cds view then we can apply a rule of thumb: ‘always use: association [1]. This will always trigger an outer join and will work in all cases.

Joins:

It is used to join multiple table together to convert data into a meaningful information and represent to business.

Unlike the association ,if we have used 4 tables with join condition in cds view ,all the joins will get executed when we trigger cds view even though business is looking for fields from any two tables.

Supported join types:

Inner join
Left outer join
Right outer join
Cross join

Note: Look forward my next blog ,covering on access and visualization layer.