Im ersten Blogbeitrag habe ich Ihnen zwei Usecases vorgestellt, die Ihnen bei der Anwendung von Core Data Services (CDS) im SAP Business Warehouse (BW) Umfeld öfter begegnen: CDS als BW DataSource (Usecase 1) und CDS als vorgefertigte und wiederverwendbare Datengrundlage in der BW-Transformation (Usecase 2).
In diesem Beitrag möchte ich nun auf zwei weitere Anwendungsfälle im Detail eingehen: CDS als Grundlage des Technischen Content (UseCase 3) und CDS als virtuelles Modell in der BW-Modellierung (UseCase 4). Aufbau & Programmierung von CDS werde ich in diesem Beitrag nicht mehr im Detail erläutern.
UseCase 3: CDS als Grundlage des Technischen Content
Wer sich schon einmal im SAP BW/4HANA den Business Content angeschaut hat, wird sehr schnell stutzig geworden sein, dass ein großer Teil des Technischen Content nicht mehr vorhanden ist. Hier fehlen alle Objekte zum Reporting der Nutzung und Performance des Systems. Dies hat allerdings nicht den Hintergrund, dass SAP kein Reporting zu diesem Aspekt mehr unterstützt, sondern, dass der Teil des Technischen Contents und Nutzung des Systems integral zusammengewachsen sind. Dabei verfolgt die SAP im BW/4HANA den gleichen Ansatz wie im S/4HANA und baut auf Basis von CDS-Views eigene Datenmodelle sowie oData-Services auf. Diese CDS werden anschließend als Basis-Provider für die Informationen des BW/4-Fiori Cockpits oder wie im folgenden Beispiel als Reporting Modell für Queries verwendet.
Folgend exemplarisch das Beispiel des Reporting-„Cubes“ für die BW OLAP (Online Analytical Processing) -Statistik im BW/4HANA:
@AbapCatalog.sqlViewName: 'RVCOLAPSTATAC' // 13
@Analytics.dataCategory: #CUBE
@Analytics.dataExtraction.enabled: true
@ObjectModel.representativeKey: 'objName'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@AbapCatalog.compiler.compareFilter: true
@EndUserText.label: 'Query Statistics (OLAP)'
define view Rv_C_OlapStatACube
as select from Rv_I_OlapStatAggr2
association [0..1] to Rv_I_InfoArea as _area on _area.infoArea = $projection.infoArea
association [0..1] to RV_P_OLAPCOUNTERALL as _all on _all.sessionUid = $projection.sessionUid
{
key sessionUid,
key stepUid,
@ObjectModel.foreignKey.association: '_infoProv'
key infoProv,
key objName,
…
Auf Basis dieses Cubes ist nun im Standard bereits eine CDS-Query vorhanden. Allerdings können auf dem Cube mit den gewohnten BW-Query-Tools weitere Queries aufgebaut werden.
Dazu kann im BW-Eclipse auf dem Projekt eine neue Query angelegt werden. Wichtig hierbei ist nun, dass das Häkchen „Search for TransientProvider“ aktiviert ist, der Providername setzt sich bei Cubes auf Basis CDS immer mit „2C“ + SQL-Name zusammen:
Anschließend kann wie gewohnt der Query-Designer für die Erstellung & Modellierung der Query verwendet werden.
Beispiel einer Query-Definition & Ergebnis:
Sind hierbei zusätzliche Felder notwendig, muss auf die gewohnten Funktionalitäten zur Erweiterung von Content im Zusammenhang mit CDS wie bei S/4HANA Embedded Analytics zurückgegriffen werden.
Alternativ kann für die Anbindung der Informationen allerdings auch dasSzenario aus dem folgenden Use Case verwendet werden, um die Informationen des Basis-Cubes im BW verwertbar zu machen.
UseCase 4: CDS als virtuelles Modell in der BW-Modellierung
Generell bietet das SAP BW/4HANA unter anderem seine größten Stärken im Vergleich zum klassischen Data Warehouse durch die Möglichkeit performante virtuelle Datenmodelle aufzubauen und betreiben. Hierbei ergänzen sich die Funktionalitäten der HANA-Datenbank sowie das Meta-Datenmodell des SAP BW auf hervorragende Weise.
Virtuelle Modellierung im BW-Umfeld ist ein etabliertes Konzept und bietet u.a. folgende vier Vorteile:
Vorteil 1: Effizienz
Durch virtuelle Modellierung wird der Bedarf an physischer Datenspeicherung und -replikation verringert. Dies führt zu einer effizienteren Nutzung von Ressourcen und einer schlankeren Dateninfrastruktur, aber auch im Hinblick auf Lizenzierung im BW/4HANA eine Kosteneinsparung.
Vorteil 2: Datenqualität und Konsistenz
Da Daten virtuell abgerufen und transformiert werden, besteht weniger Gefahr von Inkonsistenzen zwischen verschiedenen Versionen von Daten, was wiederum die Genauigkeit von Analysen und Berichten erhöht.
Vorteil 3: Agilität und Flexibilität
Virtuelle Modellierung ermöglicht es, Daten aus verschiedenen Quellen ohne physische Duplizierung zu berechnen und integrieren, dabei können die Datenquellen innerhalb des Systems auf unterschiedlichen Ebenen bereits existieren (LSA++) aber auch (realtime) virtuell aus externen Quellen hinzugelesen werden. Dies erhöht die Flexibilität, da Änderungen an den Datenquellen einfacher durchzuführen sind, ohne dass das Datenmodell neu erstellt werden muss.
Vorteil 4: Entwicklungsaufwand
Wenn DataMarts (vorberechnete Inhalte für das Reporting) zum großen Anteil über virtuelle Modelle erstellt werden, dann kann durch das „Entfernen“ der Notwendigkeit von DataLoads der Entwicklungszyklus spürbar beschleunigt werden.
Die Vorteile der CDS-Views gegenüber CalculationViews
Im Zusammenhang mit SAP BW/4HANA werden „standardmäßig“ primär HANA CalculationViews für die virtuelle Modellierung verwendet. Allerdings hat sich in vielen Projekten gezeigt, dass auch die Anwendung von ABAP-CDS Views ein sehr gutes Mittel sind, um virtuelle Modell innerhalb des BWs aufzubauen.
Dabei bieten CDS-Views die folgenden Vorteile gegenüber CalculationViews:
Vorteil 1: Berechtigungen
Es sind keine zusätzlichen Berechtigungen direkt auf Ebene HANA notwendig, wodurch Inkonsistenzen in den Berechtigungen sowie Datensicherheitsaspekte minimiert werden können.
Vorteil 2: Know-How und Investitionsschutz
ABAP CDS-Views sind mit SAP S/4HANA ein beherrschendes Thema in der Entwicklung. Wenn CDS auch im BW-Umfeld eingesetzt wird, kann KnowHow innerhalb der Teams übergreifend aufgebaut und verwendet werden.
Vorteil 3: Transportwesen
Die ABAP-CDS Views sind direkt in das Transportwesen innerhalb des BWs integriert, wodurch fehlerhafte Transporte/Inkonsistenzen minimiert werden können.
Wie kann CDS in BW-Datenmodelle konzeptionell integriert werden?
Im Folgenden möchte ich Ihnen an einem kleinen vereinfachten Beispiel skizzieren, wie konzeptionell ein CDS in BW-Datenmodelle integriert werden kann.
Wie ist die prinzipielle Vorgehensweise, um eine Backlog-DataMarts praktisch darzustellen?
In den folgenden Schritten möchte ich anhand eines sehr stark vereinfachten Beispiels die prinzipielle Vorgehensweise einer Backlog-DataMarts praktisch darstellen. Ziel ist, einen DataMart zu erstellen, welcher nur noch SD-Belege mit offenen Mengen besitzt.
Schritt 1
Im ersten Schritt bauen wir die entsprechenden CDS-Views auf, welche die Kalkulationslogik & Einschränkungen beinhalten. Dazu werden im Schritt 1 (siehe CDS View ZP_D07_SD_DELIVERIES_POSITION) alle Lieferungen auf im BW auf Ebene SD-Position aggregiert und die bereits gelieferten Mengen aggregiert:
@AbapCatalog.sqlViewName: 'ZP_D07SDDELPOS'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Demo 07: belieferte Mengen (Ebene Position)'
define view ZP_D07_SD_DELIVERIES_POSITION as
select from /bic/ayscd06d017
{
vbeln,
posnr,
vrkme,
sum(wmeng) as wmeng,
sum(vsmng) as vsmng
}
group by vbeln, posnr, vrkme
Schritt 2
Im zweiten Schritt werden nun die vorhandenen SD-Positionen mit den gelieferten Mengen abgeglichen und alle Positionen ausgeschlossen, welche bereits vollständig beliefert sind. Dabei werden aber bereits alle Felder/Merkmale zurückgeliefert, welche im finalen DataMart zur Verfügung stehen sollen:
@AbapCatalog.sqlViewName: 'ZCD07SD_OPEN_POS'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: false
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Demo 07: Offene Positionen'
@Analytics: { dataCategory: #FACT, dataExtraction.enabled: true }
define view ZC_D07_SD_OPEN_POS
as select from /b1h/ad_sd117 as sdPos
left outer join /bi0/pmaterial as material
on material.material = sdPos.material
and material.objvers = 'A'
left outer join ZP_D07_SD_DELIVERIES_POSITION as deliv
on deliv.vbeln = sdPos.doc_number
and deliv.posnr = sdPos.s_ord_item
{
doc_number,
s_ord_item,
calday,
sold_to,
… weitere DataMart Felder
// Quantities Deliveries
deliv.wmeng,
deliv.vrkme,
quant_b – coalesce(deliv.wmeng, 0) as OpenQuantity
}
where
deliv.wmeng is null
or deliv.wmeng < sdPos.quant_b
Schritt 3
Nachdem die Daten/Informationen nun inhaltlich aufgebaut sind, sollen diese wieder in BW-Datenmodellen zurück integriert werden. Dies hat den Vorteil, dass alle Meta-Information (Konvertierungs-exit, Attribute, Texte etc.) aus den BW-Modellen wiederverwendet werden, aber auch das die BW-Reporting Berechtigungen weiterhin eingesetzt werden.
Um diesen Schritt „zurück“ ins BW auszuführen, wird der obige DataMart-CDS als OpenODS View in die Modellierung integriert. Wichtig hierbei ist, dass die Felder wieder zurück auf InfoObjekte gemappt werden, falls vorhanden und gewünscht:
Schritt 4
Nachdem die Informationen nun in einem BW-Modell angebunden sind, kann nun wie gewohnt der OpenODS View in einem Composite Provider angebunden werden, ggf. auch weitere Provider hinzugefügt werden (usw.):
Fazit: ABAP CDS bieten viele Mehrwerte im BW/4HANA
Ich hoffe, ich konnte Ihnen in diesem zweiten Blogbeitrag aufzeigen, dass ABAP CDS im Hinblick auf Agilität, Flexibilität und Effizienz einige Mehrwerte im BW/4HANA schaffen kann. Darüber hinaus besitzen sie aber auch die Möglichkeit für Synergien zum KnowHow-Aufbau im Hinblick S/4HANA.
