CDS InfoProvider - Die solide Basis für Embedded Analytics in S/4HANA

CDS InfoProvider - Die solide Basis für Embedded Analytics in S/4HANA

Veröffentlicht am 28. Dezember 2021 von

Jörg Brandeis

| ABAP | CDS | S/4HANA |

Die CDS InfoProvider Views bilden eine Modellierungschicht, die als Ausgangsbasis für Embedded Analytics im S/4HANA mit CDS Queries dient. Die CDS InfoProvider können aber auch direkt als Quelle für Queries im Query Builder der SAP BW Modelling Tools verwendet werden.

Zur Übersicht über die unterschiedlichen Begriffe und View Arten, insbesondere zur Abgrenzung gegeneinander, empfehle ich zunächst einen Blick in unseren Artikel über die unterschiedlichen CDS View Typen. Die Abbildung auf der rechten Seite gibt eine erste Übersicht über die Analytischen Views.

Der Name des CDS InfoProviders

Queries und InfoProvider benötigen eindeutige Namen. Damit es keine Namenskonflikte zwischen den BW-Objekten und den Pendants aus der CDS Welt gibt, bekommen letztere ein Präfix 2C zu dem Namen des SQL-Views.

Aus dem CDS View ZJB_DEMO_CUBE mit dem SQL-View ZSQL_DEMO_CUBE wird dann der InfoProvider Name 2CZSQL_DEMO_CUBE. Das ist nicht schön, aber es ist nur ein technischer Name. Nur bei der Suche im Query Builder und für Ad-Hoch Abfragen im Query Builder ist dieser relevant. Und mit der Transaktion RSRTS_ODP_DIS können Sie sich einen CDS InfoProvider unter diesem Namen anzeigen lassen.

Einordnung der CDS InfoProvider

Analytical CDS Views

Ad-Hoc Abfragen auf einen CDS InfoProvider

Mit der Transaktion RSRT und auch im Analysis for Office können aber auch direkt auf die CDS InfoProvider Adhoc-Abfragen erstellt werden. Das ist in beiden Fällen etwas versteckt.

Im Analysis for Office bekommt man die CDS InfoProvider erst dann in der Hierarchie der Bereiche angezeigt, wenn auch eine Query dafür existiert. Wenn das noch nicht der Fall ist, dann muss man über die Suche gehen. Dabei ist wichtig, dass man nach dem Namen der SQL-Views und nicht der CDS Entität sucht.

Im SAP Query Monitor (RSRT) kann man den CDS InfoProvider genauso wie andere BW InfoProvider auch direkt abfragen. Dazu wird in das Query Feld eingegeben: <InfoProvider>/!<InfoProvider>

Beispiel: 2CZSQL_DEMO_CUBE/!2CZSQL_DEMO_CUBE

Die Testumgebung für CDS InfoProvider

Mit der Transaktion RSRTS_ODP_DIS kann man die Testumgebung für einen CDS InfoProvider aufrufen. Dort wird dann die Definition des InfoProviders mit allen Details angezeigt.

Transaktion `RSRTS_ODP_DIS`

Aufruf der Transaktion `RSRTS_ODP_DIS` mit dem Namen des CDS-Views

Anzeige der Details

Anzeige der Details als InfoProvider

Die unterschiedlichen CDS InfoProvider

CDS Cube Views

Im SAP BW entsprechen die Cube Views am ehesten den BW Composite Providern (HCPR). Der Kern des Cube Views sind die Kennzahlen, die durch die Merkmale beschrieben werden.

Verknüpfung zu den Dimensionen

Diese Merkmale können analog der InfoObjekte selber wieder Attribute haben. Die Verknüpfung zu den Dimension Views erfolgt in zwei Schritten:

  1. Eine Assoziation zu dem entsprechenden Dimension View
  2. Die Annotation @ObjectModel.foreignKey.association: '<Assoziationsname>' bei dem entsprechenden Merkmal. Dieses muss dem Representative Key des Dimenion Views entsprechen. Gegebenenfalls ist auch noch ein CAST auf den richtigen Datentyp notwendig, wie im folgenden Beispiel.
    @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,
    ...
    } 

Wichtige Annotationen und Eigenschaften eines CDS Cube Views

  • Auf View Ebene: @Analytics.dataCategory: #CUBE
  • Assoziationen zu den Dimensionen müssen modelliert sein, siehe Beispiel oben.
  • Für Merkmale mit eigener Dimension ist die Annotation @ObjectModel.foreignKey.association: '<AssociationName>' erforderlich.
  • Alle semantischen Eigenschaften der Felder und Kennzahlen sollen festgelegt sein, z.B.
    • @Semantics.quantity.unitOfMeasure: '<Einheitsfeld>'
    • @Semantics.amount.currencyCode: '<Währungsfeld>'
    • @DefaultAggregation: #SUM // #MIN, #MAX, ...
    • @EndUserText.label: '<Feldbeschreibung>'

CDS Dimension Views

Die Dimension Views enthalten die Attribute und ggf. Texte einer Dimension. Falls die Daten zeitabhängig sind, müssen zwei Datumsfelder für Anfang und Ende annotiert werden:

  • Gültigkeit von: @Semantics.businessDate.from
  • Gültigkeit bis: @Semantics.businessDate.to

Durch diese Annotation erfolgt die Selektion der richtigen Zeitscheibe automatisch. Es ist wichtig, dass die Dimension Views für jeden Schlüsselwert genau eine Zeile liefern. Siehe auch SCN-Wiki zu diesem Thema.

Beispiel für ein CDS Dimension View

Das folgende Beispiel bezieht sich auf die aktiven Daten des InfoObjects 0MATERIAL des SAP BW. Die Text-Assoziation zum CDS Text View (siehe weiter unten) ist bereits modelliert.

@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,
...
}

Wichtige Annotationen und Eigenschaften eines CDS Dimension Views

  • Auf View Ebene: @Analytics.dataCategory: #DIMENSION
  • Das Feld mit dem repräsentativen Schlüssel muss mit der Annotation @ObjectModel.representativeKey: '<Feldname>' markiert sein.
  • Texte für ein Feld
    • Wenn ein Text zu einem Feld in dem Dimension View vorhanden ist, kann diese Abhängigkeit entsprechend annotiert werden:
      • An dem Feld: @ObjectModel.text.element: ['<Textfeld>']
      • An dem Textfeld: @Semantics.text: true
    • Falls kein Textfeld vorhanden ist, kann eine Assoziation zu einem Text View (siehe unten) angelegt werden. Diese Assoziation muss dem entsprechenden Feld mit der Annotation @ObjectModel.text.association: '<Assoziationsname>' zugeordnet werden.
  • Weitere Semantischen Eigenschaften der Felder, z.B. zu Adressen, Zeitwerten, Kontaktdaten usw. Die vollständigen semantische Annotationen finden sich in der CDS ABAP Referenzdokumentation.
  • Falls nötig Feldbeschreibungen mit @EndUserText.label: '<Feldbeschreibung>'

CDS Text Views

Ein CDS Text View liefert uns sprachabhängige Texte. Er selber ist genau genommen kein InfoProvider, d.h. wir können ihn weder als Basis für CDS Queries verwenden noch Ad-Hoc Abfragen darauf ausführen. Aber über Text-Assoziationen lässt er sich in einen CDS Cube View oder CDS Dimension View integrieren.

Beispiel für einen 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
}

Annotationen eines CDS Text Views

  • Auf View Ebene: @ObjectModel.dataCategory: #TEXT
  • Das Feld mit dem repräsentativen Schlüssel muss mit der Annotation @ObjectModel.representativeKey: '<Feldname>' markiert sein.
  • Für das Textfeld: @Semantics.text: true
  • Optional, falls ein Sprachfeld vorhanden ist, hierfür: @Semantics.language: true
  • Optional, falls eine Zeitabhängigkeit vorhanden ist:
    • Gültigkeit von: @Semantics.businessDate.from
    • Gültigkeit bis: @Semantics.businessDate.to

Übersicht über das Zusammenspiel der CDS InfoProvider

Zusammenspiel der einzelnen Views über Assoziationen

Fazit

Die Modellierung von InfoProvidern ist nicht schwer. Ich halte es für wichtig, dass man bei CDS Views sich jeweils auf einen Aspekt fokussiert. Also nicht die Eierlegende Wollmilchsau in einem einzigen CDS-View baut, die für Analytics, VDM und noch für 100 weitere Frameworks alle notwendigen Annotationen enthält. Eine saubere Trennung in Schichten erlaubt einerseits Wiederverwendbarkeit und andererseits Transparenz. Das Analytics Framework erzwingt eine Trennung in mindestens die beiden Schichten CDS InfoProvider und CDS Query. Mit der oben gezeigten Struktur ist das ganz einfach, hier eine solide Basis für die CDS Queries aufzubauen.