SAP NetWeaver Business Warehouse
Page tree
Skip to end of metadata
Go to start of metadata

CDS views provide a very flexible way to create a transient query to run on Analytic Engine (see also Analytic CDS Queries). There are some basic rules to follow in data modeling.

Analytics on ABAP CDS View Data Models

The picture below helps to understand the idea behind it:

As analytic CDS queries are run by the Analytic Engine (in BW also called OLAP Engine), the data model should still align with traditional BW assumptions. CDS views just provide a faster, easier, more flexible way to build up such a data model.

The upper part of this picture shows the traditional objects in a typical BW system: first InfoProviders are built by using Modeling Tool for BW on HANA, or RSA1 for BW on other DBs. Then BW queries are built on these InfoProviders by using a Query Designer, either Bex Query Designer or the Query Designer part of the Modeling Tool.

It is similar for a 'transient' query to run (on the Analytic Engine) in a non-BW system such as S/4HANA. The lower part of the picture shows this: InfoProviders should be built by using CDS views, then CDS queries are built on top of it by defning CDS views with different annotations. (Note: planning are not supported in customer defined CDS. See Note 2874534)

CDS views are just a new tool to build the data model for Analytic Engine. The only difference is: with traditional tools like RSA1, Query Designer or Modeling Tool, the boundary of different objects are well defined in the tools. The tools guide end users to build a valid model. However, CDS views is much 'lighter' tool with strong capability, by reducing the ETL (Extraction, Transformation, Loading) effort, a data model can be built very conveniently by typing some CDS scripts. But the boundary of the objects are blurred. The explicit restrictions defined in traditional BW tools become implicit rules for users to follow in order to build a valid model. Although there is no terms like 'InfoProvider' or 'Query' in the CDS transient objects world, nevertheless users still need to bear this picture in mind while modeling a business scenario. The information provided by this page should help you to better understand technical details and to know 'where to define what' .

Basic Rules

Here are some implicit rules in data modeling, you may get various error when activate the CDS view if they are broken:

  1. Analytics on ABAP CDS is only supported on HANA system.
  2. A detailed discussion of the basic concept on Analytic Queries can be found in  Embedded Reporting on ABAP CDS views, the usage of a certain annotations is documented with the help of corresponding examples in CDS views: HowTo use in BW contexts.
  3. Unions and Joins (including associations, value help) can only be defined in CDS views of InfoProvider layer (with annotation @Analytics.dataCategory:#CUBE,...). With only one exception: valueHelp association for a CDS query parameter ( which could be unavailable in the provider view) can be defined in CDS query view (using annotation @Analytics.query: true).
  4. CDS queries (with annotation @Analytics.query:true) can be extended, but only query elements can be added into the extended view. Additional unions and joins need to be defined on InfoProvider level.
  5. Some BEX query features are not supported in CDS query yet. In this case, instead of define a CDS query, you can define a BW query on the CDS InfoProvider in Modeling Tool to use these OLAP features.  See 'Classic' BW Queries based on CDS Cubes for details (and more).
  6. CDS parameter only supports single value. It is input mandatory. The supported max length of a parameter name is 29.
  7. Filters should be defined in a query CDS view. An InfoProvider CDS view should not contain parameters except for currency conversion. Parameters on InfoProvider level don't support semantics. Cube CDS views with parameters are mapped to HANA-table functions instead of HANA views. This might lead to significant performance impact .
  8. Don't use a BW InfoObject generated data element in a CDS view, always use the basic data element which is directly defined in DDIC (SE11). Generated data element will cause problems in life cycle management. Because generated data element is created when activating the InfoObject. If you use the data element in a CDS view and transport the CDS-view and the newly created InfoObject at the same time, an error is raised in the target system. DDIC objects (that is CDS) are activated before the BW Objects activation. So the generated data element will not be available.
  9. If a join (or an association) is defined on fields with domain using alpha conversion or data type NUMC, you have to assure that:
    a) both fields in two tables have exactly the same length
    b) the data in both fields follows the alpha conversion rule: for example, for a char(2) field, there is no '1' stored in this field, it should be stored as '01'.
    Otherwise the data model will run into various issues and get unexpected query results. See Note 2789339.
  10. Association to a Dimension view or text view with parameters is not supported.
  11. Don't define 'group by' clause in a CDS cube, dimension or query view. Analytic Engine will automatically generate 'group by' clause in the open SQL during query runtime according to the query navigation status.

Notes:

  • 2551243 CDS modeling considerations in BW
  • 2874534 Planning on ABAP CDS View 

Examples:  

Modeling

Getting Start

CDS reporting needs to define at least 2 CDS views as below:

For data stored in cluster tables or other encrypted data, a tool is needed to extract data into a transparent table for embedded reporting.  

Examples:

InfoProvider CDS Modeling

Here are more details about modeling considerations in different situations:  

  • InfoObject (@Analytics.dataCategory: #DIMENSION and measures/key figures)
  • InfoProvider (@Analytics.dataCategory: #CUBE)

 CDS Query

CDS views: HowTo use in BW contexts#BWQuery:%40Analytics.query:true

  • No labels