Describing SAP S/4HANA embedded analytics

Objectives

After completing this lesson, you will be able to:

  • Describe how ABAP CDS Views are used in SAP S/4HANA Embedded Analytics

ABAP CDS Views

To exploit the high performance of the in-memory database of SAP HANA, SAP introduced a new data modeling framework called Core Data Services (CDS). CDS is available in two versions:

ABAP CDS and native SAP HANA CDS. The concepts for both versions are identical.

In this course, we will focus on ABAP CDS, although the principles described apply to native SAP HANA CDS (SAP HANA Cloud and on-premise).

CDS is a data definition language that is used to define views on data sources that encapsulate rich semantics. Semantics provide information about the data and the view that consumption tools can use. For example, to determine how to present the currency of the measures, how to format the dates, how the data can be joined to another view to provide additional fields, whether a view can be consumed directly by an analytic tool or only by another view.

Within the view it is possible to combine any tables or views, add calculations and hierarchy information. CDS views are used in analytics scenarios including planning.

ABAP CDS is a component of SAP NetWeaver and is an enhancement to the traditional ABAP DDIC framework. ABAP CDS goes far beyond the capabilities of the ABAP DDIC tooling where simple views were created using a tool known as SE11.

ABAP CDS views push down the processing steps to the database to optimize performance which is why they are popular with developers who want the best performance from their applications.

Each ABAP CDS view corresponds to a counterpart SQL view in the database. So, if you create an ABAP CDS view from scratch the system would automatically create a mirrored SQL view on the database level to enable the push down principle.

Using ABAP CDS views, we can create a comprehensive virtual data model. The virtual data model is the foundation for all analytical requirements and provides ready-to-consume data that has been processed. The data has undergone a series of steps that started with the raw data in the tables and moved the data through a series of modeling actions to generate the final output. We cannot expect a business user to perform these complex data modeling steps. For example, joining tables requires deep knowledge of the tables, their relationships and the meaning of the columns. Also, without applying filters to the tables, too much data can be exposed and that generates too much information – a problem for ease of understanding.

A data model should also provide rich semantics that are not present in the underlying tables. The additional metadata adds more meaning to the data. For example, we can identify that a numeric column is actually a price and also point to the column where the currency is defined. With metadata defined in the virtual data model we can let the consuming applications know how to process the model. For example, we can indicate to the consuming applications whether a view is suitable for a particular reporting scenario, such as drill-down reporting. We can also indicate whether the view can be consumed directly or needs to be processed by another view. A virtual data model is usually built using views in a layered approach. This supports a low-redundancy model by reusing the lowest-level views. Any change to the lower-level views is consumed through the stack, so a change to the lowest-level view, such as adding a new column, will affect all higher-level views.

The lower layers of the virtual data model consume raw data from the tables and model it into basic, consumable data shapes. Think of these lower-level views as forming the data modeling layer where data is prepared. The top level of the virtual data model is also created using ABAP CDS views but this top level should be regarded as the analytical layer and not data modeling. This is because the top level is where queries are defined. Queries are defined using a special type of ABAP CDS view where additional consumption-related information can be provided, such as whether totals are required.

SAP provides a rich virtual data model with SAP S/4HANA so that analytics can be developed very quickly using consumable data shapes.

For SAP S/4HANA on-premise, ABAP CDS views can be developed and maintained using graphical tools (aimed at business users) or using a code editor (aimed at developers). For SAP S/4HANA Cloud, only graphical tools are used.

Note
The graphical tools used to develop ABAP CDS views actually generate the same types of source files as if they were created manually using a text editor.

ABAP CDS views are defined using a special syntax that was developed by SAP to provide a powerful way to describe data models. In these views you will find a combination of SQL and syntax that provides the additional meta-data. ABAP developers are usually already familiar with ABAP CDS views.

SAP S/4HANA embedded analytics

The focus of SAP S/4HANA embedded analytics is the support of operational analytics. Operational analytics applies to the day-to-day activities of a business and relates to the real-time decision making at the moment of risk or moment of opportunity. SAP S/4HANA embedded analytics does not focus on strategic analytics.

SAP S/4HANA embedded analytics provides powerful analytical tools directly inside the transactional environment. This is why the solution is called embedded analytics.

Using SAP S/4HANA embedded analytics, business users and leaders can get insight into operational business areas using live data that comes from the transactional and master data tables of SAP S/4HANA.

Bringing Transactions and Analytics Together

In SAP S/4HANA, transactions and analytics are combined on a single, in-memory SAP HANA platform. In the past, transactional operations such as creating a sales order and analytical operations were handled in separate systems. However, we know that business processes are usually a sequence of transactions that include analysis throughout the process. You simply cannot separate them as one coming after the other.

Launch the video to learn more about how transactions and analytics come together.

SAP S/4HANA embedded analytics provides the business user with insights during a business task. For example, sales employees can observe their customers' buying patterns and adjust their sales approach accordingly. In logistics, we can identify delivery routes that have often led to delays in the past, so that better route planning decisions can be made at the time of order creation.

With SAP S/4HANA embedded analytics there is no need to move data from a transactional system to an analytical system, as is the case with other data modeling solutions. Live data from the SAP S/4HANA transaction tables is immediately ready for modeling and analysis. This means we do not have multiple copies of data, we don't have the latency, and we don't have to take care of monitoring the data loads.

In the past, the data from the online transactional processing (OLTP) systems would be periodically copied to online analytical processing (OLAP) systems. SAP S/4HANA embedded analytics combines these functions in the same system. No data is copied.

Overview

There are two components of SAP S/4HANA embedded analytics: the virtual data model and analytical apps.

The Virtual Data Model (VDM)

This section will explain the role of the virtual data model.

The tables of SAP S/4HANA are not intended to be consumed directly by business users for analysis. The tables store data in a raw format that typically requires considerable processing before it is useful for analysis. For example, tables need to be joined, filtered, aggregated, values converted and much more. A single database table on its own rarely provides anything useful, especially when it comes from a large ERP system such as SAP S/4HANA. Due to the complexity and the large number of the tables, it is a challenge to find the right information. Business users would need the assistance of technical experts to find the data they need. This can be complex.

The virtual data model (VDM) sits on top of the database tables and processes the data in real time so that it is available in a usable form. The word virtual is used because there is no data persistence in the model. Data moves from the database tables through the model to the consuming application in real time.

The consuming application does not need to know the database tables and communicates only with the virtual data model, which it regards as the data source. The virtual data model is developed entirely using ABAP CDS views which provide the data modeling logic.

Log in to track your progress & complete quizzes