SAP Datasphere and SAP S/4HANA’s Virtual Data Model (VDM)

SAP S/4HANA’s Virtual Data Model (VDM) provides a semantically rich layer on top of raw HANA tables, enabling analytics and integrations without exposing underlying schemas. By organizing business logic into reusable CDS views, the VDM ensures consistency, stability across upgrades, and out-of-the-box compatibility with tools like SAP Datasphere. 

In this article, we’ll explore what the VDM is, how it works and why the VDM connects so well with SAP Datasphere

What is SAP S/4HANA’s Virtual Data Model?

At its core, the VDM is SAP’s “semantic layer” in S/4HANA, an abstraction built entirely with ABAP Core Data Services (CDS) views. Instead of writing queries against raw tables (for example, VBAK or VBAP), you consume meaningful business entities such as SalesOrder or BillingDocument for example. 

These CDS views define which columns and associations are exposed, how fields are renamed or calculated, and what filters apply.

All views adhere to strict naming conventions and layering rules. SAP also guarantees upgrade stability with the extensibility framework built around “stability contracts”. Other applications (e.g. Datasphere) can access specified views to consume S/4 HANA data in a performant and future proof manner.

A bit of theory on CDS Views

The VDM funds its modeling best practice on a layered approach, separating concerns and boosting reuse. There are many types of CDS Views that serve a different purpose, but let’s see the most basic in more detail.

• Basic Views : Those are views close to the table structure, which rename fields for clarity and adding business context. Those views are mainly used to expose the table data for further use. SAP uses ‘I’ as a prefix in the view name according to their naming convention. Annotations like (@VDM.viewType: #BASIC) are used to denote a basic view.
• Composite Views : Those views join and aggregate basic views to form broader business entities. The annotation used for these are (@VDM.viewType: #COMPOSITE).
•  Consumption Views: Consumption Views are built strictly on top of other views (never on tables), and they tailor data to specific scenarios (embedded analytics in Fiori apps, custom reporting, or OData services). Naming convention for a standard consumption CDS view starts with: C_*.

The image shown below shows how the VDM operates for Sales Orders as an example.

Customization & Extensibility

For cases in which customization is required, the VDM allows for CDS view extensions. These are separate technical objects that define only the extra fields to be added to a particular CDS view. The original view stays intact and unaltered, which ensures easier reuse and stability with S/4HANA upgrades. Additionally a new view can be built from scratch on top of other released CDS Views to make larger customizations possible, e.g. joining two models.

For this purpose stability contracts play a crucial role, as they describe what kind of upgrade stability SAP guarantees for the views in their VDM.
There are 3 types of contracts:

• C0 (Key-User Extensibility)
  This type of contract allows basic field additions via key-user tools.
  
  
• C1 (System-Internal Use)
  This type is common for custom development; SAP ensures most interface elements remain stable across releases.
  
  
• C2 (Remote API Use)
  This type of contract has the highest stability guarantee as they are intended for external integrations and published APIs.
  
  

We recommend following these contracts as closely as possible, however sometimes it cannot be avoided to violate them. Just be aware of the risk that this poses:
Imagine you build a custom CDS view on top of a VDM CDS view. Your organization then updates their S/4 HANA version to a new release. With this new release, SAP has changed their VDM and removed or renamed a field (according to the maintained stability contract C0) that you use in one of your custom CDS views. Now the S/4 upgrade process will be halted until this broken definition in your custom CDS view gets resolved.

So, why does SAP Datasphere and the Virtual Data Model align so well together?

Keeping Metadata Intact with Semantic Onboarding

SAP Datasphere and the S/4HANA Virtual Data Model (VDM) align so seamlessly because Datasphere can leverage the ABAP CDS-based metadata and semantic definitions, ensuring that the S/4 business context stays intact after importing the model to Datasphere.

By using Replication Flows to replicate from S/4HANA, target local tables can automatically be created with the field definition being derived from the CDS views, retaining some of their semantics like business names and data types as well as saving development time.

For a quick creation of models, the Semantic Onboarding feature can be utilized, which makes it easy to bring SAP S/4HANA’s CDS-based Virtual Data Model directly into SAP Datasphere, ensuring that the same semantically rich entities defined in S/4 appear in Datasphere without manual rework.

In practice, Datasphere reads each view’s metadata (measure definitions, unit and currency annotations, field labels, texts and associations) and automatically generates equivalent objects in the Datasphere space, which retain all the business logic embedded in the VDM. This is a huge timesaver and accelerator for the development of data models. It also serves as a perfect data foundation for AI applications, which thrive on interconnected systems and rich metadata.

Watch the recording of our webinar! 

Simplify Data Integration with Change Data Capture

Furthermore, CDS views, enabled for Change Data Capture via annotations, automatically provide deltas. Datasphere’s replication flows consume only those deltas, minimizing data movement and latency.

Mandatory consideration for the CDS views to be consumed is that they have to have the annotation @dataExtraction.enabled: true, so that they can be extracted.

To support near-real-time replication of data, CDS views can be enabled for Change Data Capture in the following ways:

• Automatic CDC Annotation
  Automatic CDC works well when having CDS views directly on top of tables that do not have any join conditions. 

Adding @ChangeDataCapture.automatic: true to a CDS view tells the mechanism to track inserts, updates, and deletes at.

• Mapping and Join Considerations
  For views that rename keys or include joins, you use @ChangeDataCapture.mapping annotations to link each exposed field back to its base-table key. 
  
  

SAP Business Content

Additionally, SAP Datasphere is equipped with pre-built business content packages that include predefined models and KPIs, such as Sales Analysis and Finance Foundation for SAP S/4HANA, which are based on the VDM for these areas. By utilizing these packages, organizations can quickly derive insights without extensive efforts.

One recommendation, coming from our experience, is that while the business content provides a good starting point for modeling, an out of the box use is not ideal, since it is in many ways overcomplicated with lots of layers and in other ways lacking in detail.

For this reason, the standard models provided by the content should rather be used as a basis for custom modeling. By studying the content, data modelers can get an idea of how data and tables from S/4 HANA correlate with each other in order to produce common KPIs and rebuild this logic in a more consolidated form. Thereby they can adhere to the governance standards set by their organization as well as the specific business requirements guiding their efforts rather than using the generic business content.

Limitations

While SAP Datasphere and SAP S/4HANA are clearly designed to be a match, there still are some limitations that make things a bit difficult to handle.

To begin with, one factor that poses a limitation, is the fact that replication between S/4 and datasphere will require an extensive number of sap notes to be implemented, especially on older S/4 releases. These range from absolutely required notes to quality of life changes that enhance the monitoring capabilities

Additionally the monitoring of Replication Flows through the Data Integration Monitor, can be a bit limiting, since many of the errors that are displayed are a bit generic and do not provide many details. Further troubleshooting of such runtime errors can be done via the S/4HANA T-Code SLG1, which is used to check the application log for more detailed messages.

T-Codes DHRDBMON (for both load types) and DHCDCMON (for “Initial and Delta” load type) can be used to check the buffer table status of the source objects, as well as the CDC monitor in the S/4 system, allowing to monitor and troubleshoot Datasphere replication flow subscriptions.The possibilities for troubleshooting out-of-the-box however are still limited and often deep technical knowledge and extensive privileges in the source system will be required.

Summary & Outlook

To summarize, the alignment of SAP Datasphere with S/4HANA VDMs is achieved through the consistent application of metadata and semantic definitions across both environments, speed to value features like semantic onboarding, aligned business content between S/4HANA, Datasphere and SAC, good extensibility concept with the pre-delivered VDM and C0/1/2 contracts and, finally, powerful and low effort CDC Framework for data integration.

However, when older S/4HANA versions are used, extensive manual configuration remains necessary, although ongoing improvements are being introduced in recent releases, while in general, built-in monitoring and troubleshooting capabilities do pose some limitations.

Looking into the future, the combination of S/4HANA and Datasphere (and Business Data Cloud by extension) will become increasingly important to enable a solid data foundation for AI (Joule) Applications and Use-Cases.

Do you have questions about SAP Datasphere? Are you trying to build up the necessary know-how in your department or do you need support with a specific issue? Please do not hesitate to contact us. We look forward to exchanging ideas with you!