CDS - Migration der Views
Du hast noch viele alte Core Data Services in deinem ABAP System? Zeit für die Migration zur neuen Entität.
Inhaltsverzeichnis
In diesem Artikel werden wir uns die Migration On-Premise und in der Cloud anschauen. Dabei werden wir an zwei Beispielen zeigen, wie du die Migration deiner Core Data Services auf die neuen Views hinbekommst.
Einleitung
Die neuen Views gibt es nun schon eine ganze Weile und mit dem Release 7.57 (S/4HANA 2022) sind nun auch die alten Core Data Services obsolet. Bist du auf einem aktuellen S/4 HANA Release, dann solltest du dir langsam Gedanken machen, die Views zu migrieren. Dazu stellt SAP verschiedene Hilfsmittel zur Verfügung, die wir in diesem Artikel einmal näher beleuchten wollen.
Migration (Report)
In diesem Abschnitt werden wir unseren alten Core Data Services mit den zur Verfügung gestellten Reports migrieren. Bist du noch nicht auf einem S/4 HANA 2023, dann ist das der bevorzugte Weg. Die Migrationsreports stehen ab einem S/4HANA 2021 zur Verfügung.
Vorbereitung
Bevor wir mit der Migration starten, legen wir uns im ersten Schritt einen alten Core Data Service im System an, um an diesem die Migration durchführen zu können. Dazu definieren wir einen einfachen Core Data Service basierend auf der Tabelle BSEG (alte Finanz Positionen).
@AbapCatalog.sqlViewName: 'ZBSIMIGPOS'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Migration Example (Position)'
@Metadata.ignorePropagatedAnnotations: true
define view ZBS_I_MigrationPosition
as select from bseg
{
key bukrs as CompanyCode,
key belnr as DocumentNumber,
key gjahr as FiscalYear,
key buzei as AccountingDocumentItem,
buzid as AccountingDocumentItemType,
augdt as ClearingDate,
augcp as ClearingCreationDate,
@Semantics.amount.currencyCode : 't001.waers'
dmbtr as AmountInCompanyCodeCurrency,
@Semantics.amount.currencyCode : 'bkpf.waers'
wrbtr as AmountInTransactionCurrency
}
Auf diesem View definieren wir einen Consumption View der die Daten als Summe nach außen zur Verfügung gestellt.
@AbapCatalog.sqlViewName: 'ZBSCMIGPOS'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Migration Example (Consumption)'
define view ZBS_C_MigrationPosition
as select from ZBS_I_MigrationPosition
{
key CompanyCode,
key DocumentNumber,
key FiscalYear,
sum( AmountInCompanyCodeCurrency ) as SumForCompany,
sum( AmountInTransactionCurrency ) as SumForTransaction
}
group by
CompanyCode,
DocumentNumber,
FiscalYear
Analyse
In dieser Phase benötigen wir den Report RUTDDLS_MIGRATION_CANDIDATES zur Analyse der Core Data Services im System, die wir migrieren möchten. Führen wir den Report für die beiden Views aus, erhalten wir eine Einschätzung zur Migrationsmöglichkeit der Views.
In diesem Fall können wir die beiden Views migrieren und damit mit der Umsetzung beginnen.
Umsetzung
Für die Umsetzung starten wir mit dem Report RUTDDLSV2MIGRATION und starten zuerst einen Simulationslauf für die beiden Objekte.
Allerdings erhalten wir nun Fehler bei der Umsetzung der Objekte. Schauen wir uns das Protokoll etwas näher an, finden wir die Fehlermeldung, dass die Referenzfelder nicht in der Entität enthalten sind.
In den alten Views war es möglich, auf das Referenzfeld in der Annotation zu verweisen und wir mussten dieses nicht explizit im View mitgeben. In diesem Fall müssen wir die beiden Felder per Assoziation in den Core Data Service aufnehmen. Nach der Anpassung des Basis Views sieht dieser nun wie folgt aus.
@AbapCatalog.sqlViewName: 'ZBSIMIGPOS'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Migration Example (Position)'
@Metadata.ignorePropagatedAnnotations: true
define view ZBS_I_MigrationPosition
as select from bseg
association [1..1] to t001 as _Company on _Company.bukrs = $projection.CompanyCode
association [1..1] to bkpf as _Head on _Head.bukrs = $projection.CompanyCode
and _Head.belnr = $projection.DocumentNumber
and _Head.gjahr = $projection.FiscalYear
{
key bukrs as CompanyCode,
key belnr as DocumentNumber,
key gjahr as FiscalYear,
key buzei as AccountingDocumentItem,
buzid as AccountingDocumentItemType,
augdt as ClearingDate,
augcp as ClearingCreationDate,
@Semantics.amount.currencyCode : 'CompanyCurrency'
dmbtr as AmountInCompanyCodeCurrency,
_Company.waers as CompanyCurrency,
@Semantics.amount.currencyCode : 'DocumentCurrency'
wrbtr as AmountInTransactionCurrency,
_Head.waers as DocumentCurrency
}
Den Consumption View müssen wir ebenfalls anpassen und die Felder aus dem View darunter aufnehmen.
@AbapCatalog.sqlViewName: 'ZBSCMIGPOS'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Migration Example (Consumption)'
define view ZBS_C_MigrationPosition
as select from ZBS_I_MigrationPosition
{
key CompanyCode,
key DocumentNumber,
key FiscalYear,
CompanyCurrency,
DocumentCurrency,
@Semantics.amount.currencyCode : 'CompanyCurrency'
sum( AmountInCompanyCodeCurrency ) as SumForCompany,
@Semantics.amount.currencyCode : 'DocumentCurrency'
sum( AmountInTransactionCurrency ) as SumForTransaction
}
group by
CompanyCode,
DocumentNumber,
FiscalYear,
CompanyCurrency,
DocumentCurrency
Nun können wir einen zweiten Simulationslauf starten und das Ergebnis prüfen. So weit wurden alle Prüfungen erfolgreich abgeschlossen und wir können im nächsten Schritt die Umsetzung anstoßen.
Dazu setzen wir im Report von "Simulation generation" auf "Generate inactive version". Damit werden die beiden Views angepasst, die SQL Views von der Datenbank gelöscht und eine inaktive Version generiert. Da wir im $TMP Paket arbeiten, müssen wir keinen Transport für die Umsetzung angeben. Zum Abschluss können wir nun die beiden Views aktivieren. Schauen wir uns die Basis an, hat sich hier nur im Kopfbereich etwas verändert.
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Migration Example (Position)'
@Metadata.ignorePropagatedAnnotations: true
define view entity ZBS_I_MigrationPosition
Auch im Consumption View sind die Annotationen weniger geworden, nicht mehr benötigte Annotationen werden durch die Anpassung entfernt.
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Migration Example (Consumption)'
define view entity ZBS_C_MigrationPosition
Migration (Wizard ADT)
Im nächsten Schritt verwenden wir den Wizard in den ABAP Development Tools, um unser Datenmodell aus der Core Data Service Schulung auf den aktuellen Stand zu überführen. In der Cloud (ABAP Environment, Public Cloud) steht dir nur dieser Weg für die Migration zur Verfügung, On-Premise kannst du mit einem S/4HANA 2023 Release auch diesen Weg nutzen.
Analyse
Um die Analyse zu starten, markieren wir die Core Data Services, die wir im nächsten Schritt prüfen lassen wollen. Am einfachsten geht das über den Project Explorer und per Rechts-Klick im Kontextmenü.
Dort siehst du alle Views die den Kriterien entsprechen. Bereits umgestellt Entitäten werden aus der Liste entfernt. Die Meldung findest du im oberen linken Bereich des Popups.
Im nächsten Schritt kannst du den Lauf einstellen, ob du zuerst eine Analyse durchführen möchtest oder direkt mit der Migration starten willst.
Je nach Anzahl der Objekte dauert der Lauf dann entsprechend lang.
Als Ergebnis erhalten wir ein Popup mit den entsprechenden Laufinformationen. Über die Checkbox können wir uns die fehlerhaften Objekte anzeigen lassen, um die Fehler zu analysieren. Wenn du einen View markierst, siehst du im unteren Teil einen Vergleich der beiden Ressourcen (Aktuell -> Neu) und kannst dir möglichen Änderungen anschauen.
Anpassung
Da wir noch Views mit Fehlern haben, müssen wir zunächst alle Fehler korrigieren. Die Meldungen weisen in den meisten Fällen auf fehlende Mengen- und Währungseinheiten hin. Hier ergänzen wir wieder die entsprechenden Felder im View mit zusätzlichen Assoziationen, der Aufnahme des Feldes in den View oder mit der Ergänzung einer Annotation.
In einem speziellen Fall werden wir auf den Datentyp in unserem Union Beispiel hingewiesen. Da wir vorher keinen spezifischen Typen gecastet haben, sondern das Element Inline per Wert (0) angelegt haben, casten wir nun auf einen entsprechend passenden Typen.
define view ZBS_I_DmoUnion
as select from ZBS_C_DmoPositionError
{
key DocumentNumber,
key PositionNumber,
'Normal' as PositionType,
PositionPrice,
PositionCurrency
}
where
ErrorInConversion = ' '
union select from ZBS_C_DmoPositionError
{
key DocumentNumber,
key PositionNumber,
'Error' as PositionType,
cast( 0 as abap.curr(15,2) ) as PositionPrice,
PositionCurrency
}
where
ErrorInConversion = 'X'
Alle durchgeführten Anpassungen findest du in diesem Commit im GitHub Repository, damit du die Änderungen nachvollziehen kannst.
Migration
Im letzten Schritt führen wir nun die Änderungen an allen Views durch. Dazu markieren wir wieder alle Views und führen dieses Mal die Migration im Echtlauf durch, um inaktive Views im System zu erzeugen. Das System fragt uns in diesem Fall auch nach einem Transport. Über den "Assign" Button kannst du einen Transport allen Objekten zuweisen und musst dies nicht einzeln machen.
Wenn du dann alle Views markierst, kannst du eine Massenaktivierung durchführen und die Views sollten sich ohne Probleme aktivieren lassen. Über das Kontextmenü findest du ebenfalls die Option zum Aktivieren.
Über den Commit im GitHub Repository findest du die finalen Views und die gemachten Umstellungen durch die Migration.
Zusammenfassung
Die Migration der alten Views auf die neuen Entitäten macht auf jeden Fall Sinn, da ein zweites Objekt, der SQL View nicht mehr nötig ist. Ebenfalls werden sich die Aktivierungszeiten der Views stark erhöhen, was unsere Arbeitszeit beschleunigt.
Mehr zu den geprüften Regeln und den gemachten Umsetzungen findest du im unten verlinkten Artikel, wenn du mehr im Detail wissen möchtest. Dort kannst du noch tiefer in das Thema Migration und Anforderungen eintauchen.
Hinweis: In manchen Use-Cases, wie zum Beispiel bei der BW-Extraktion oder der Einbindung in Customizing, werden gern die SQL-Views der Core Data Services verwendet. Du solltest daher mit der Migration "aller" Views vorsichtig sein.
Fazit
In dem Artikel wollten wir dir zeigen, wie einfach die Migration der Core Data Services funktioniert und welche Hilfsmittel zur Verfügung stehen, um die Migration durchzuführen. Mit dem passenden Release sollte dir daher nichts mehr im Weg stehen, da es mehr Vorteile als Nachteile damit gibt.
