CDS InfoProvider - The solid basis for Embedded Analytics in S/4HANA

Veröffentlicht am 18. Januar 2022 von

Jörg Brandeis

The CDS InfoProvider Views form a modeling layer that serves as the starting point for Embedded Analytics in S/4HANA with CDS queries. However, the CDS InfoProviders can also be used directly as a source for queries in the Query Builder of the SAP BW Modeling Tools.

To get an overview of the different terms and view types, especially to distinguish them from each other, I recommend to first have a look at our article about the different CDS view types. The figure on the right gives a first overview of the Analytical Views.

The name of the CDS InfoProvider

Queries and InfoProviders require unique names. To avoid naming conflicts between the BW objects and their counterparts from the CDS world, the latter get a prefix 2C to the name of the SQL view.

The InfoProvider name 2CZSQL_DEMO_CUBE is then created from the CDS view ZJB_DEMO_CUBE having the SQL view ZSQL_DEMO_CUBE . It's not pretty, but it's just a technical name. This is only relevant for searches in the Query Builder and for ad-hoc queries in the Query Builder. And you can use transaction RSRTS_ODP_DIS to display a CDS InfoProvider under this name.

Analytical CDS Views

Ad-Hoc Queries to a CDS InfoProvider

However, using the transaction RSRT or the Analysis for Office, ad hoc queries can also be created directly on the CDS InfoProviders. This is somewhat hidden in both cases.

In Analysis for Office, the CDS InfoProviders are only displayed in the hierarchy of areas if a query exists for them. If this is not yet the case, then you have to go through the search. It is important to search for the name of the SQL view and NOT the CDS entity.

In the SAP Query Monitor (RSRT) , you can query the CDS InfoProvider directly in the same way as other BW InfoProviders. To do this, enter in the query field: <InfoProvider>/!<InfoProvider>

Example: 2CZSQL_DEMO_CUBE/!2CZSQL_DEMO_CUBE

The different CDS InfoProviders

CDS Cube Views

In SAP BW, Cube Views correspond most closely to BW Composite Providers (HCPR). The core of the Cube View are the key figures described by the characteristics.

Link to the dimensions

These characteristics can have attributes themselves, just like the InfoObjects . The link to the dimension views is done in two steps:

1. An association to the corresponding Dimension View.
2. The annotation @ObjectModel.foreignKey.association: '<Assoziationsname>' at the corresponding characteristics. This must correspond to the Representative Key of the Dimenion View. Sometimes, it is also necessary to make a CAST to the correct data type, as in the following example.

@AbapCatalog.sqlViewName: 'ZSQL_DEMO_CUBE'
@EndUserText.label: 'Demo Cube'

@Analytics.dataCategory: #CUBE
define view zjb_demo_cube
  as select from /bic/adtsa0062

  association to zjb_material_dim as _material 
           on $projection.material = _material.material
{

  key doc_number,
  key s_ord_item,
  key calday,
  key measure,

      @ObjectModel.foreignKey.association: '_material'
      cast(material as /bi0/oimaterial preserving type ) as material,

      @DefaultAggregation: #SUM
      @EndUserText.label: 'Menge'
      @Semantics.quantity.unitOfMeasure: 'base_uom'
      quant_b,
...
}

Important annotations and properties of a CDS Cube View

• At view level: @Analytics.dataCategory: #CUBE
• Associations to the dimensions must be modeled, see example above.
• For features with their own dimension, the annotation @ObjectModel.foreignKey.association: '<AssociationName>' is required.
• All semantic properties of the fields and key figures should be defined exactly, e.g.
  • @Semantics.quantity.unitOfMeasure: '<Unit Field>'
  • @Semantics.amount.currencyCode: '<Currency Field>'
  • @DefaultAggregation: #SUM // #MIN, #MAX, ...
  • @EndUserText.label: '<Field Description>'

CDS Dimension Views

The Dimension Views contain the attributes and, if necessary, texts of a dimension. If the data is time-dependent, two date fields must be annotated for start and end:

• Valid from: @Semantics.businessDate.from
• Valid until: @Semantics.businessDate.to

This annotation automatically selects the correct time slice. It is important for the Dimension Views to provide exactly one row for each key value. See also SCN Wiki((https://wiki.scn.sap.com/wiki/display/BI/Cube+View+in+CDS)) on this topic.

Example of a CDS Dimension View

The following example refers to the active data of the SAP BW InfoObject 0MATERIAL . The text association to the CDS Text View (see below) is already modeled.

@AbapCatalog.sqlViewName: 'SQL_VIEW_NAME'
@EndUserText.label: 'Material'

@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'material'
define view zjb_material_dim
  as select from /bi0/pmaterial as dim 
  
  association [0..*] to zjb_material_txt as _material_text
           on dim.material = _material_text.material
{

  @ObjectModel.text.association: '_material_text'
  key material,  
      changed,      
  @Semantics.systemDate.createdAt: true
      createdon,
      division,
...
}

Important annotations and properties of a CDS Dimension View

• At View Level: @Analytics.dataCategory: #DIMENSION
• The field with the representative key must be marked with the annotation @ObjectModel.representativeKey: '<Fieldname>'
• Texts for a field
  • If a text exists for a field in the Dimension View, this dependency can be annotated accordingly:
    • At the field: @ObjectModel.text.element: ['<Textfield>']
    • At the text field: @Semantics.text: true
  • If no text field is available, an association to a text view (see below) can be created. This association must be assigned to the corresponding field with the annotation @ObjectModel.text.association: '<Association Name>'.
• Further semantic properties of the fields regarding e.g. addresses, time values, contact data, etc. The complete semantic annotations can be found in the CDS ABAP reference documentation.
• If necessary, use field descriptions with @EndUserText.label: '<Field Description>'

CDS Text Views

A CDS Text View provides us with language-dependent texts. Strictly speaking, it is not an InfoProvider, i.e. we can neither use it as a basis for CDS queries nor execute ad-hoc queries on it. But via Text Associations it can be integrated into a CDS Cube View or CDS Dimension View.

Example of a Text View

@AbapCatalog.sqlViewName: 'ZSQL_MAT_TXT'
@EndUserText.label: 'Material text'

@ObjectModel.dataCategory: #TEXT
@ObjectModel.representativeKey: 'material'
define view zjb_material_txt
  as select from /bi0/tmaterial
{
  key material,
  
  @Semantics.language: true
  key langu,
  
  @Semantics.text: true
      txtmd
}

Annotations of a CDS Text View

• At view level: @ObjectModel.dataCategory: #TEXT
• The field with the representative key must be marked with the annotation @ObjectModel.representativeKey: '<Fieldname>' .
• For the text field: @Semantics.text: true
• Optional, for a language field, if available: @Semantics.language: true
• Optional, if a time dependency is existing:
  • Valid from: @Semantics.businessDate.from
  • Valid until: @Semantics.businessDate.to

Structure of the interaction of the CDS InfoProviders

Conclusion

Modeling InfoProviders is not difficult. I think it's important to focus only on one aspect at a time regarding CDS Views. In other words, we don't want to build just one single CDS View that contains all the necessary annotations for Analytics, VDM and 100 other frameworks. A clean differetiation of the layers allows reusability on the one hand and transparency on the other. The Analytics Framework enforces a differentiation into at least two layers - CDS InfoProvider and CDS Query. With the structure shown above, it's quite easy to build a solid base for the CDS queries here.