Einführung, Anwendungsfälle und Nutzen
In Teil 1 dieser Blogreihe möchte ich Ihnen einen Überblick und einige Ideen zum Einsatz von Core Data Services (CDS) im Umfeld der BW-Modellierung aufzeigen. Diese Blog-Reihe wird nicht Aufbau & Programmierung von CDS im Detail erläutern, hierzu sind bereits unzählige Blogs in der SAP Welt vorhanden.
Ich möchte mich auf die Anwendung von CDS im Umfeld BW konzentrieren und im Detail vier häufig anzutreffende Anwendungsfälle erläutern.
Die vier häufig anzutreffenden Anwendungsfälle:
- CDS als BW DataSource
- CDS als vorgefertigte und wiederverwendbare Datengrundlage in BW-Transformationen
- CDS als Grundlage des technischen Contents
- CDS als virtuelles Modell in der BW-Modellierung
Was sind ABAP Core Data Services?
CDS (Core Data Services) ist eine DDL-Sprache im SAP Umfeld. In dieser Reihe werden wir uns ausschließlich mit den CDS-Views beschäftigen. Diese ermöglichen die Erstellung von komplexen SQL-Views im ABAP-Umfeld, hierbei verwenden CDS eine erweiterte Syntax von OpenSQL inklusive z.B. Funktionsaufrufe, Berechnungen und Case-Anweisungen. Generell steht die Möglichkeit CDS-Views zu verwenden ab dem SAP Basis Release 7.40 zur Verfügung.
Grundlegender Aufbau von CDS-Views:
@AbapCatalog.sqlViewName: 'ZPHELLOWORLD' -- SQL-Viewname (SE11)
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: false
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Hello World' -- Anzeigename
define view ZP_HELLO_WORLD as
select from t000 -- Basistabelle
{
-- Deklaration der Felder
'Hello World' as spalte_1,
logsys,
left(logsys, 3) as sid -- Erste 3 Stellen des logischen Systems
}UseCase 1: CDS als BW DataSource
Die häufigste Anwendung von CDS-Views im BW-Umfeld ist das Erstellen von BW-DataSources per CDS. Dies bietet die Möglichkeit auf einfachem Weg kundeneigene Extraktoren mit umfangreicher Business Logik aufzubauen. Hierzu werden im Quellsystem CDS-Views wie oben beschrieben angelegt und mit der notwendigen Logik (Berechnungen & Filterung) versehen.
Um einen CDS für die Extraktion durch das BW freizuschalten, benötigt der CDS-View eine zusätzliche Annotation @Analytics.dataExtraction.enabled: true im Kopf des CDS-Views. Zu berücksichtigen hierbei ist allerdings, dass diese Annotation erst ab Basis-Release 7.50 SP5 verfügbar ist. Sollten Sie dieses Release noch nicht in Ihrem Quellsystem aufsetzen, müssen Sie einen „kleinen“ Umweg über einen zusätzlichen generischen Extraktor gehen (siehe weiter unten).
Weiterhin ist empfohlen auch die Datenkategorie (Stamm-/Bewegungsdaten oder Texte) zu definieren. Dies kann über die Annotationen @Analytics.dataCategory und @ObjectModel.dataCategory geschehen.
Im Beispiel definiere ich einen Bewegungsdaten CDS-View zur Extraktion von Auftragsrückmeldungen. Wie in vielen Tabellen im SAP System sind hier die Anlage- und Änderungsdatum getrennt gespeichert. Um einen einfachen Weg für die „Delta“-Extraktion zu bieten habe ich in diesem Beispiel beide Daten in ein „Delta-Datum“ überführt.
@AbapCatalog.sqlViewName: 'ZDBW_AFRU'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: false
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Extraktion AFRU'
@Analytics: {
dataCategory: #FACT,
dataExtraction: {
enabled: true,
delta: {
byElement: {
name: 'DeltaDate'
}
}
}
}
define view ZD_BW_AFRU as
select from AFRU
{
key MANDT,
key RUECK,
key RMZHL,
AUFNR,
VORNR,
CASE WHEN AFRU.LAEDA = '00000000' THEN AFRU.ERSDA
ELSE AFRU.LAEDA
END AS DeltaDate,
BUDAT,
…
}Das Zusammenführen der Daten in ein Datum hat nun einen sehr großen Vorteil im Beladungsprozess des BW-Systems da in diesem Fall ein Filtern oder generisches Delta ohne Probleme aufgebaut werden kann.
Um ein generisches Delta direkt über CDS der BW-Beladung anbieten zu können, bietet SAP eine weitere Annotation an. In diesem Beispiel habe ich die Annotation @Analytics.dataExtraction.delta.byElement verwendet, welche ein Delta über Timestamp- oder Datumsfeld ermöglicht. Das CDS-Framework bietet weitere Deltaverfahren und Möglichkeiten, auf welche ich in diesem Beitrag allerdings nicht weiter eingehen möchte.
Nachdem wir nun den Extraktor über CDS angelegt haben, kann dieser vom BW-System konsumiert werden. Hierfür ist im BW ein neues Quellsystem vom Typ „ODP – ABAP CDS Views“ zu definieren und anzubinden. Ist dieser Schritt geschehen können Sie den CDS-Extraktor wie gewohnt in das BW-System einbinden und in den Ladeprozess integrieren.
Ein weiterer möglicher Einsatz von CDS in Extraktionen ist die Verwendung von CDS als Datenbasis von „herkömmlichen“ generischen Extraktoren (Transaktion RSO2). Sollte beispielsweise das Quellsystem noch nicht das notwendige Basis-Release besitzen oder der Extraktor ist bereits in diverse Datenflüsse integriert, so kann dies einen sinnvollen Workaround für die Integration von CDS in die Integration bieten. Gerade wenn für einen bereits bestehenden Extraktor Performance-Probleme im Customer-Exit auftreten können CDS zur Optimierung sehr gut eingesetzt werden.
Auch in diesem Szenario bleiben wir bei der Extraktion von Auftragsrückmeldungen. Die Annahme hierbei ist, dass das Quellsystem noch auf einem 7.4 Basis-Release ist und noch keine Annotationen verwendet werden können, oder vielleicht auch BW-System kein neuer Quellsystemtyp angelegt werden kann.
Hierfür definieren wir analog dem CDS-View oben die Rückmeldedaten, allerdings ohne die BW-spezifische Annotationen zur Extraktion.
Im nächsten Schritt öffnen wir die Transaktion „Generische DataSource pflegen“ (RSO2) und legen einen neuen Extraktor ZBW_AFRU auf Basis des vom CDS bereitgestelltem Datenbankviews an.
Auch in diesem Fall ist es möglich ein generisches Delta über die berechnete Spalte DeltaDate zu erstellen.
UseCase 2: CDS in BW-Transformationen als Datenrundlage vorgefertigt und wiederverwendbar
Häufig werden in komplexen BW -Transformationen verschiedenste Berechnungen auf unterschiedlichen Aggregationsstufen schon während der Transformation benötigt, um Daten korrekt zu filtern oder in der Transformation mit weiteren Daten zu konsolidieren. Diese Logik vollständig über ABAP abzubilden, führt zu unübersichtlichen – trotz HANA – inperformanten Transformationen. Eine Abhilfe kann hierbei das Auslagern des Sammelns und Aggregierens von Grunddaten für die Business Logik in separate CDS-Views schaffen. Dieses Szenario kann gerade bei BW/4HANA Migrationen eingesetzt werden, um Transformationen mit minimalem Aufwand zu beschleunigen, ohne die gesamte Business Logik auf HANA-Script umstellen zu müssen.
Ein Umstieg auf HANA-Transformationen und AMDP-Routinen kann hierbei bereits die Performance deutlich verbessern, allerdings führt dies dennoch schnell zu „aufgeblähten“ Transformationen.
In diesen Fällen ist es anzuraten die für die Berechnung notwendigen Daten (Stammdaten und zusätzliche Bewegungsdaten außerhalb des aktuellen Datenflusses) in vorgefertigten CDS-Views bereits vorzubereiten, sodass in der Transformation „nur“ die Transformationslogik implementiert werden muss.
Diese Vorgehensweise bietet zusätzlich die Möglichkeit das bereits aufbereitete Daten in mehreren Transformationen wiederverwendet werden können.
Zum Schluss ein kleines Praxisbeispiel zur Verwendung vorgefertigter Daten aus CDS in ABAP Transformation
Im Folgenden möchte ich Ihnen exemplarisch ein vereinfachtes Beispiel für eine schnelle Integration von Vorberechnungen in bestehende Transformation aufzeigen. Hierfür nehmen wir als UseCase an, dass wir bereits eine bestehendes Datenmodell und Datenfluss für SD-Auftragspositionen besitzen. Das Datenmodell für die Positionen ist um das Datum der letzten Lieferung je Position zu erweitern.
Dazu legen wir im ersten Schritt einen kleinen CDS zum Ermitteln des letzten Lieferungsdatums je Position an.
@AbapCatalog.sqlViewName: 'ZCSDPOSCALC'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: false
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'BW: SD Position calculation'
define view ZC_SD_POS_CALC as
select from /b1h/ad_sd167 as allocations
inner join /bic/ayscd06d017 as deliveries
on deliveries.vbeln = allocations.doc_number
and deliveries.posnr = allocations.s_ord_item
{
allocations.doc_number,
allocations.s_ord_item,
max( deliveries.mcex_i_lfdat ) as lastActualDelivery
}
group by allocations.doc_number, allocations.s_ord_itemIm Anschluss erweitern wir nun die (bestehende) Endroutine in der Transformation zur Beladung der Positionen:
...
SELECT * FROM zc_sd_pos_calc
INTO TABLE @DATA(lt_sdposcalc)
FOR ALL ENTRIES IN @result_package
WHERE doc_number = @result_package-doc_number
AND s_ord_item = @result_package-s_ord_item.
LOOP AT result package ASSIGNING <result_fields>.
READ TABLE lt_sdposcalc ASSIGNING FIELD-SYMBOL(<ls_sdposcalc>)
WITH KEY doc_number = <result_fields>-doc_number
s_ord_item = <result_fields>-s_ord_item.
IF sy-subrc = 0.
<result_fields>-/bic/zsdllfdat = <ls_sdposcalc>-lastActualDelivery.
ENDIF.
ENDLOOP.
...Bleiben Sie dran, es bleibt weiterhin spannend!
Sie sollten aus dem Beitrag mitnehmen, dass CDS ein mächtiges Tool in der Hand eines jeden ABAP-Entwicklers sein kann, sowie einen ersten Einblick in den möglichen Einsatz im BW-Umfeld im Speziellen.
Im zweiten Beitrag dieser kleinen Reihe beleuchten wir die weiteren Anwendungsfälle anhand kleiner Beispiele näher. Somit steigen Sie tiefer in die Thematik der oben erwähnten Anwendungsfälle: CDS als Grundlage des technischen Contents und CDS als virtuelles Modell in der BW-Modellierung ein.
