Content
Introduction: What is SAP S/4HANA Embedded Analytics?
Embedded Analytics in SAP S/4HANA refers to the direct integration of analytical functions into the operational ERP system. Unlike traditional BI architectures, analysis is performed on live data without data replication or a separate data warehouse such as SAP Business Warehouse.
The technical foundation is the Virtual Data Model (VDM), which is based on Core Data Services (CDS) and their views. These CDS views structure data across multiple layers and define both semantic logic and analytical properties. Annotations are used to describe functions such as key figures, filters and aggregations directly in the data model. This creates a consistent and reusable data foundation.
The data can be consumed, for example, in the FIORI Launchpad as Smart Business KPIs, multidimensional reports or Analytical List Pages.
Proven Best Practices in Embedded Analytics
Modelling Recommendations for CDS Views
Best practices in Embedded Analytics can be brought together into a consistent approach if all levels – modelling, annotations and governance – are viewed as an interconnected system rather than as isolated individual rules.
The starting point is consistent adherence to the VDM layering:
Basic Views are the only views that access database tables directly. They select data without filters or joins.
Composite Views are built exclusively on Basic Views and other Composite Views. Consumption Views consume only the reuse layer.
Breaking this separation, for example by accessing tables directly from higher layers or by placing business logic in Composite Views that should actually serve purely as reusable building blocks, may provide short term convenience but comes at the cost of release instability, performance issues and poor reusability.
The general rule for linking views is:
Associations rather than joins, because associations are only resolved when a field is actually queried, whereas joins are always executed. This is the most effective way to minimise unnecessary runtime overhead in embedded analytics scenarios with many consuming front-ends, and represents a technically very significant advantage over traditional SQL/BI data models. This allows a broad range of use cases to be covered directly at the data foundation level, i.e. in Composite Views, with different queries being generated as required.
When working with annotations, it pays to deliberately separate them by category. Content related and semantic annotations – such as currency references, units of measurement and field labels – belong at their respective definition points and are automatically propagated through the view stack. Repeating them in every layer only creates a risk of divergence, for example when a definition is assigned in both the Basic View and the Consumption View and subsequent changes are not applied consistently everywhere.
An adjustment at the definition point (Basic View) would therefore only be reflected up to the Consumption View, because the same field is defined again (and redundantly) there. In this case, a change would not be reflected consistently in reporting and would only become apparent when front end users report an inconsistent label.
Structural and role defining annotations, as well as exposure annotations, on the other hand, must be set explicitly for each view. They describe the specific role of that view within the model and therefore cannot be meaningfully inherited.
Important:
As soon as a field is renamed, aggregated or transformed, the inheritance chain is broken and the semantics must be set again at the new point. This is a frequently overlooked source of errors when activating views.
Governance should be anchored as deeply in the stack as possible:
Access checks should take place at Basic View level, close to the data source, rather than being reinvented for every Consumption View. At the same time, it is advisable to explicitly declare the authorisation check annotation at every level. Not because inheritance is missing, but for reasons of transparency.
This means that when looking at an individual view, it is immediately apparent whether and how an access check is performed.
The following applies to the extension of standard content:
Do not modify the original views. Instead, use metadata extensions for additional annotations and custom extension views for additional fields. This preserves updateability when moving between releases.
Finally, it is worth looking at the tooling rather than relying on memory:
The “Active Annotations” view in the ABAP Development Tools (ADT) shows the annotations that are actually effective for each view and field, including their origin. This replaces manual documentation with traceability directly within the system and is therefore the most practical way to keep the model and its governance consistent even as complexity increases.
Design Recommendations for Reports in the Fiori Launchpad
In Embedded Analytics, every customisable report is based on a floorplan. This defines fundamental design elements, such as the position of filters and charts.
The way a chart is presented, for example as a bar or line chart, can be freely selected. It therefore makes sense to use the same chart types for the same purposes and, for example, not to switch between line and column charts for time series unless a comparison is also intended.
In addition to readability, the choice of chart type also affects report performance. In particular, the “Other” category in pie and donut charts can be problematic. This category combines all values that do not have their own segment in the chart. If users specifically filter for “Other”, the individual values contained within this category have to be resolved again. This can result in comparatively high computational effort and negatively affect report performance.
In addition to selecting the appropriate chart type, consistent colours, naming conventions and key figure definitions are also important.
The following applies: the same colour should always represent the same purpose, for example grey for the previous year and hatching for the forecast. Key figures should likewise be defined and used consistently.
Design guidelines are among the most important Embedded Analytics best practices. They establish consistent standards, increase user acceptance and ensure that, particularly, new reports can be understood and read quickly.
Whitepaper "Comparing SAP BW, Datasphere & Embedded Analytics"
Which SAP BI tool is really the right fit for your reporting strategy?
This whitepaper shows you how to future-proof your SAP reporting landscape using a range of approaches.
Download
Avoiding Pitfalls in Embedded Analytics
Clear Assignment of Annotations
As briefly described in the Embedded Analytics best practices above, the purpose of a CDS View is not always immediately apparent. What a view “can do” partly depends on what the underlying construct provides. Whether a view is authorised for use, for example for reporting or data consumption, or not, can only be determined if one is aware of its annotations.
It therefore makes sense to always assign the structural and role defining annotations required later when modelling a CDS View, regardless of whether the view has already inherited these properties from its source. Not all annotations can be cleanly inherited anyway. This not only saves time when researching the VDM, but also makes it possible to include a standardised header, similar to what is already common in programming.
This approach consequently carries the risk of creating a long list of annotations. It is therefore necessary to assess on a case by case basis which annotations are uncritical and do not interfere with use across multiple layers, and which provide added value by making the view easier to interpret. The former can therefore be omitted.
This does not apply to semantic annotations that describe specific fields and their contents, such as key figure, currency or other definitions. As a rule, these properties do not change. Once they have been defined, annotations do not need to be repeated.
Maintainable Access Control with DCL
Roles and permissions also exist in the context of embedded analytics, where access control to data is defined using Data Control Language (DCL). Essentially, three components work together to achieve this:
- The CDS View must be annotated so that an authorisation check is performed.
- An Access Control object (AC object) must be available. This links the CDS View to the technical authorisations from the PFCG object. An AC object can be used in multiple CDS Views.
- A PFCG role must be available in which users are assigned the values they are authorised to access.
The initial setup can therefore take some time, but the reusability of AC objects makes the approach scalable.
Important:
When a join is performed on multiple CDS views that have been checked for authorisation, the AC objects are also processed. The resulting dataset corresponds to the intersection of the data from the individual CDS Views to which the user has access.
The aspect of inheritance should also not be overlooked when it comes to authorisations. Since authorisations are inherited, they should be modelled as deeply in the stack as possible – where possible, directly after the database layer in the CDS Basic Interface View layer.
Conclusion
SAP Embedded Analytics makes possible what traditional BI architectures often achieve only with considerable effort:
Analysis takes place in real time and directly within the operational system, without the detour via data replication or a separate data warehouse. This is made possible by the VDM. Through CDS Views, it provides a multi layer and semantically enriched data foundation. This can be used in the FIORI Launchpad, for example, as Smart Business KPIs, multidimensional reports or Analytical List Pages.
To ensure that this potential is not wasted, one thing matters above all: discipline from the outset.
The VDM layering, Basic Views close to the database, Composite Views as the reuse layer, Consumption Views for the front end. This structure is not a bureaucratic constraint, but the real success factor. Anyone who breaks it gains a few minutes today but pays for it tomorrow with release instability and performance problems.
Just as important is to consistently use associations instead of joins. The difference may seem insignificant, but it has a major impact exactly where it matters: in scenarios with many front ends accessing the system simultaneously, where unnecessary runtime load immediately translates into noticeable sluggishness. This should be avoided as far as possible, particularly in the operational system, where users also perform their day to day work. Two aspects deserve particular attention.
First: set annotations deliberately and comprehensively from the outset, rather than only when they are needed. Because the inheritance chain is broken whenever a field is renamed, aggregated or transformed, carelessness here can have particularly painful consequences, often only becoming apparent later when users report inconsistent labels. Those who model cleanly from the beginning can avoid time consuming troubleshooting when activating views.
Second: anchor governance as deeply as possible in the stack. Access checks belong at Basic View level and should not be remodelled repeatedly in every Consumption View. This is not only cleaner, but also the only way to keep authorisation concepts genuinely scalable.
The same principle applies to reporting: consistency beats arbitrariness. The same chart types for the same purposes, no switching between line and column charts for time series, well thought out use of colours and consistent key figure definitions – all of these factors determine whether a report can be understood immediately or generates additional questions. And if you are unsure what a CDS View actually does, a look at the “Active Annotations” view in the ABAP Development Tools reliably replaces any guesswork based on memory.
Ultimately, it is precisely this mindset that makes the difference: Embedded Analytics rewards those who remain consistent from the first modelling decision to the final chart colour, and penalises every compromise made for the sake of convenience.
Contact us!
Do you have any questions about SAP BW or SAP Embedded Analytics? Our experts are happy to help. Schedule a web meeting with us or leave your question in the comments section below.
You are currently viewing a placeholder content from Active Campaign. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More Information
