Getting an Overview of the Virtual Data Model

SAP S/4HANA comes with pre-build content in form of SAP Core Data Services for real-time operational reporting. The content is represented as a VDM - virtual data model -, which is based on the transactional and master data tables of SAP S/4HANA.

The Virtual Data Model realized in S/4 HANA by Core Data Services (CDS Views). Core Data Services 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, you define a persistence model that includes objects such as tables, views, and structured types. The database objects specify what data to make available for consumption by applications and how that data is made available.

CDS views are built using the ABAP editor for Eclipse using the ABAP Development Tools (ADT) in Eclipse of the S/4HANA System. They are stored in the ABAP repository. When the CDS view is activated, an SQL-Runtime-View is generated in the SAP HANA database in order to actually execute the data read and transformation inside the SAP HANA Database Layer.

• No latency
• No data duplication
• Ready-to-use content
• Integration scenarios with SAP BW
• Full ABAP Lifecycle Integration
• Supporting Authorizations
• Supporting Hierarchies
• …

Standard reporting in SAP S/4HANA is done with the help of SAP S/4HANA Embedded Analytics reports, which is standard reporting using SAP Fiori tiles.

Embedded Analytics is available by default and allows drill-down to the document level.

• Fiori reports
• Convenient reporting options from the same S/4 system
• Customers can add their own reports
• Export to Excel pivot tables.

You can also use SAP Analysis for Microsoft Office (AFO) in your SAP S/4HANA system and create SAP Analysis for Microsoft Office workbooks which can also be placed on SAP Fiori tiles.

• Array-based reports
• Cell-based reports
• All CDS views are available.

Using SAP Analytics Cloud (SAC) for reporting means working with a Live Connection between SAC and SAP S/4HANA. This means that the data is read from the corresponding tables at runtime.

• Completed reports are available as part of the delivered content.
• SAC reporting stories can also be placed on SAP Fiori tiles!
• SAP offers embedded SAC stories.
• A lot of dashboarding use cases are offered.

The approach to embed stories and create dashboards and visualizations using SAC continues to stay a strategic use case, as SAC combines BI, augmented and Predictive Analytics, and planning capabilities into one cloud environment.

In the following we will focus on SAP S/4HANA Embedded Analytics as the standard tool for reporting in SAP S/4HANA.

The Virtual Data Model (VDM) is a structured representation of so-called CDS views (Core Data Service) and follows consistent modeling rules.

It provides direct access to SAP business data using standard SQL or OData requests. The structure allows the VDM to display abstract database tables in a way that is based on business semantics and therefore easier to consume.

CDS views allow bringing the logic used in the SAP ABAP applications to the database perspective. They are created and maintained using Data Definition Language (DDL) and were enriched with the following features: 

• Entities - structured tables with custom-defined types. 
• Associations - the ability to create joins on-demand, i.e., the join is only executed when the data from the table associated are needed. 
• Expressions - used to create calculated fields. 
• Annotations - used to add component-specific metadata to the source code of any CDS entity.

To access exactly the data, you need for your own apps, you can reuse existing released CDS views already available in the VDM. For example, you can define views that aggregate and analyze data in a layered fashion, starting with existing views delivered by SAP and then adding views to match your specific use case.

A VDM is therefore a hierarchy of views, in which each layer adds more business context, until the top layer is consumed by the application. The lowest VDM layer sits on top of the database tables and consumes the most important data directly from the tables. The next VDM layer consumes from the first virtual layer to refine the data, apply filters, add calculations, convert currencies, change the description of the columns, and so on. There is no technical, fixed limit to the number of layers in a VDM. However, for consistency and governance, the number of layers and their purpose are usually well-defined.

The VDM represents the simplified and harmonized business-oriented model. The term "Virtual" refers to the fact that the VDM may deviate from the traditional persistent model of database tables, in a way that makes it easier to understand. The VDM is a semantic model of the application data, represented in ABAP CDS views. The VDM is a reusable, stable, and compatible platform for SAP internal development, partners, and customers, increasing development efficiency and fostering ease of consumption.

This additional layer makes it possible for the different applications and frontend tools to reuse the coding and database logic created in the VDM, simplifying the implementation of new features and keeping the costs down. The VDM presents the business data of an SAP system as an understandable, comprehensive, and executable model for consumers in transactional and analytical applications and external Interfaces.

• Improved performance
• Extensibility
• Security and privacy: Full ABAP integration, allowing for instance to re-use existing reporting authorizations, etc.
• Consistence: Build consistent calculations like deviations, margins etc.
• CDS Views are not application-specific but across-applications due to Joins but without redundant physical data.

The most important component in the VDM is the Interface View. It consists of a consistent model of reusable entity views, which focus on business semantics.

Interface views are subdivided into two view types:

• the Basic interface views,
• the Composite interface views.

Form the low-redundancy model on top of the Suite database tables. They are defined as independent of their potential consumers. Core entity views contain the associations to other core entity views.

They are further categorized into Core Entity views, Text views, and Hierarchy views.

- The Core Entity views are often used for master data like Cost Center, Controlling Area.

- Text views contain language-dependent texts for a specific business entity.

- Hierarchy views contain hierarchy nodes (including parent/child assignments) for a specific business entity.

The following rules apply to Basic Interface views:

• They expose all relevant business data.
• They are free of redundancies.
• They can directly access database tables and other basic views.
• They can have associations with other basic views.

Composite Interface views can be recognized by the fact that they do not connect directly to the database tables. You have several Basic Interface views for the Virtual Data Model. These basic views now need to be combined in a Composite view, that will allow cube-like reporting, e. i. reporting of transaction data. They may project, calculate, join, filter, and aggregate data based on Basic views or other Interface views. Multiple analytical queries may be based on top of the same Interface view. It is therefore expected that an Interface View is rather broadly defined containing a lot of even redundant information.

The following rules apply to Composite Interface views:

• They can access Basic views and other Composite views.
• By nature they introduce data redundancy.
• They should be reusable.
• They can have associations with other basic views.

In the top layer, Consumption Views are defined.

Consumption views are created on top of Interface views, and they address specific application requirements. They add more semantics (such as filters) to provide a view that is optimal for consumption.

A Consumption View can be a (pure) Consumption View or an Analytical Query.

Pure Consumption Views have the same functionality like Analytical Queries but since the Analytical Query uses the Analytical Engine, additional complex calculations in the ABAP Analytical Engine are possible at runtime.

For example pivot tables, hierarchies, aggregations, formula calculations etc. are possible if you use the Analytical Query instead of the pure Consumption View.

The figure above describes by which Frontend tools consumption views can be used.

The figure above shows which four objects are created in parallel when you create and publish a Custom Analytical Query and explains the naming conventions of the four objects.

Annotations enrich the data model with additional (domain-specific) metadata.

Annotations describe how the view can be used (for example, for OLAP use only), restrictions (for example, for France only), and business context (for example, this account is a supplier, not a customer).

Important are two annotations that are automatically created when you publish the custom analytical query:

• If in the Consumption View the annotation @Analytics.query: true is set, the consumption view has an Analytical Query. The report is executed in the Analytical Engine.
• If in the Consumption View the annotation @OData.publish: true is set, then an OData Service was generated, which makes a consumption view out of the ABAP view. If you activate the service in the Fiori Gateway system for the combination of the backend system and client after the publication of the Analytical Query, you are allowed to use the data and functionality for web communication of the OData web protocol which also includes Mobile Devices and Desktop applications.