CCM - Ermittlung Level A Objekte
Wie kommen wir eigentlich an alle Level A Kundenobjekte heran und können sie zu anderen ABAP Cloud Objekten abgrenzen? In diesem Artikel schauen wir auf die verschiedenen Objekte und Prozesse.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns an, wie wir alle ABAP-Cloud-Objekte in einem System ermitteln können, woher die Informationen kommen und was wir dabei beachten sollten.
Einleitung
Um später einmal eine Quote für Cloud-Ready und Upgrade-Stable ermitteln zu können, benötigen wir auch die Anzahl der ABAP-Cloud-Objekte. Hierbei handelt es sich um Level A und alle Objekte, die damit zusammenhängen. Hierbei sollten wir beachten, dass es nicht nur um Objekte geht, die in einer bestimmten Software-Komponente (SWC) liegen, sondern auch um alle Objekte, die mit der Sprachversion „ABAP for Cloud Development“ gekennzeichnet sind. Diese können ebenfalls in Classic-ABAP-Paketen liegen. Schauen wir daher auf die verschiedenen Informationsquellen, die uns zur Verfügung stehen, und wie wir daraus die passenden Informationen ableiten können.
Agent
Etwas blauäugig sind wir deshalb erst einmal gestartet und haben dafür AI befragt. Dabei klang die Frage im ersten Schritt erst einmal ziemlich einfach. Wir wollten alle Objekte aus einem System haben, die die Sprachversion „ABAP for Cloud Development“ haben. Dabei wussten wir im Grunde nicht, um welche Tabellen es sich handelt und wo überall die Sprachversion vorhanden ist. Entsprechend lief AI bzw. der Agent in VS Code los und hat versucht, über die TADIR zum Beispiel die Einträge zu lesen, konnte dort aber zum Beispiel die Sprachversion nicht finden. Nach einigen Minuten mussten wir dann den Lauf abbrechen, da uns eigentlich selbst nicht klar war, woher die Elemente und Informationen stammen.
Herausforderung
Die größte Herausforderung liegt daher in der großen Anzahl der Objekte, die im System existieren, die entsprechende Sprachversion haben und in komplett unterschiedlichen Tabellen liegen. Dies wird erst klar, wenn man sich den Grad und die Masse der Objekte anschaut, die relevant sind. Normalerweise würde man sagen: Ich habe doch hier eine Klasse, die Klasse hat eine Sprachversion und diese Klasse kann ich dann als ABAP-Cloud-Objekt zählen. Doch was ist zum Beispiel mit Core-Data-Services, einer Metadata Extension oder dem entsprechenden Service-Binding? Diese Objekte werde ich nicht bei den anderen Code-Objekten finden, sondern diese sind in separaten Objekten abgelegt. Da stellt sich als Nächstes die Frage: Welche Objekte sind für ABAP Cloud überhaupt relevant? Wo liegen diese Objekte, in welchen Tabellen, und was sollte ich davon zählen?
Extraktion
Schauen wir uns in diesem Kapitel an, wie wir die verschiedenen Schritte durchgegangen sind, um die Datenquellen zu ermitteln, die Extraktion vorzubereiten und die richtigen Objekte aus dem System zu ziehen.
Cloud Objekte
Erst einmal beginnt alles mit einem sehr guten Tipp, um eine Übersicht über das System und dessen Verhalten zu bekommen. Dabei hilft zum Beispiel ein Blick in die XCO-Klassen, welche die Sprachversion verwenden, um Objekte auch klassifizieren zu können. Schaut man dann einmal etwas tiefer in das System, wird man zum Beispiel die Klasse für die Language-Version finden – hier in dem Fall eine Factory-Klasse CL_ARS_LANG_VRS_OBJTYP_FACTORY. Über die Factory haben wir dann die Möglichkeit zu sehen, was die SAP als Standard heranzieht, um die verschiedenen Objekte zu instanziieren und abgleichen zu können. Dabei wird intern die Tabelle ARS_LANG_OBJTYPE verwendet, welche ein Grund-Customizing für jeden Objekttypen und die entsprechenden Sprachversionen enthält. So finden wir zum Beispiel auch die Key-User-Objekte und die Cloud-Objekte, die unterstützt werden, die entsprechenden Klassen, Tabellen und Filter dazu. Hier ist es wichtig, dass nicht immer das ABAP-Language-Feld die Sprachversion enthält, sondern teilweise auch in klassischen Tabellen bestehende Felder wiederverwendet wurden.
Gruppierung
Gehen wir dann einmal durch die Daten durch, werden wir feststellen, dass zum Beispiel für unterschiedliche Typen die gleiche Tabelle verwendet wird. So liegen eine Klasse, eine Behavior-Implementation und ein Interface in der gleichen Tabelle. Damit wir diese Objekte jetzt nicht doppelt zählen, müssen wir zuerst einmal eine Gruppe für die Konfiguration bilden. Dabei nehmen wir die gleiche Data Source und erzeugen damit eine Konfigurationstabelle, wo alle Typen gruppiert werden, die auf die gleiche Tabelle zeigen. Bei der Selektion auf die Tabelle schränken wir direkt auf die ABAP-Cloud unterstützten Objekte ein, um dann nur relevante Artefakte zu lesen.
SELECT FROM ars_lang_objtype
FIELDS *
WHERE supports_sap_cloud_platform = @abap_true
AND does_not_have_language_version = @abap_false
INTO TABLE @DATA(ac_objects).
LOOP AT ac_objects INTO DATA(object).
TRY.
DATA(config) = REF #( configurations[ table = object-table_name ] ).
config->types &&= |, { object-object_type }|.
CONTINUE.
CATCH cx_sy_itab_line_not_found.
INSERT VALUE #( table = object-table_name
types = object-object_type
handler_class = object-handler_class_name
field = object-column_name )
INTO TABLE configurations REFERENCE INTO config.
ENDTRY.
ENDLOOP.
Als Ergebnis erhalten wir dann eine Tabelle, über die wir später loopen können, um dann nur einmal die eigentliche Zieltabelle zu lesen und schon das entsprechende Zielfeld mit der Sprachversion für die Eingrenzung zu haben. Über die Konfiguration haben wir dann später auch die Möglichkeit, weitere Einschränkungskriterien mitzugeben, um so die Daten einzuschränken. Mehr dazu im nächsten Abschnitt.
Abgrenzung
Nun müssen wir die Anzahl der ABAP-Cloud-Objekte in der eigentlichen Tabelle ermitteln. Dazu verwenden wir ein dynamisches Statement, in dem wir die Tabelle angeben und einen Count über die Gesamtmenge ermitteln. Dabei müssen wir allerdings noch eine Einschränkung mitgeben, denn wir würden sonst auch Objekte zählen, die von SAP ausgeliefert werden, zum Beispiel Demo-Objekte. Daher haben wir noch eine Vorkonfiguration, in der wir pro Tabelle definieren, welches das Schlüsselfeld ist, das zum Beispiel den Objektnamen enthält. So können wir dieses Feld dann auf Z* und Y* einschränken, um kundeneigene Objekte abzugrenzen.
LOOP AT configurations INTO DATA(configuration).
DATA(condition) = |{ configuration-field } = '{ language_version }'|.
IF configuration-z_filter IS NOT INITIAL.
condition &&= | AND ( { configuration-z_filter } LIKE 'Z%' OR { configuration-z_filter } LIKE 'Y%' )|.
ENDIF.
SELECT
FROM (configuration-table)
FIELDS COUNT( * )
WHERE (condition)
INTO @DATA(number_of_entries).
INSERT VALUE #( types = configuration-types
number = number_of_entries ) INTO TABLE counters.
ENDLOOP.
Für einige Tabellen gibt es noch Sonderfilter über zum Beispiel angelegte User oder andere Typen. Diese findest du in dem finalen Beispiel in der Vorkonfiguration zu den entsprechenden Tabellen. Als Ergebnis erhalten wir eine Tabelle mit Anzahl und Objekttypen. Diese speichern wir als Zwischentabelle, um dann später noch einmal nachvollziehen zu können, woher die eigentlichen Werte kommen. Das hat eher einen prüfenden Charakter als die direkte Ermittlung der Anzahl.
S/4HANA 2025
Sind wir bereits auf einem aktuellen Release, finden wir in unserer Tabelle auch noch zusätzlich zwei Konfigurationsspalten mit angelegten Core-Data-Services. Diese Services sind bereits auf die verschiedenen Szenarien zugeschnitten, sodass wir zum Beispiel auch für Klassen oder Interfaces ein eigenes Szenario haben.
Schauen wir uns dafür einen Beispiel-View an. Dieser ist für die Ermittlung der Behavior-Definitions im System. Grundsätzlich geht der View ebenfalls auf die REPOSRC Tabelle, hat hier aber zum Beispiel auch schon die Standardeingrenzungen im Bauch, um aktive Objekte zu lesen und solche, die vom Typ Behavior sind. Jeder View hat die typischen Standardfelder: Objekttyp, der meistens fix vorgegeben wird, den Objektnamen, um das eigentliche Objekt abzugrenzen, und die ABAP-Language-Version, um dann zum Beispiel Key-User-Objekte oder ABAP-Cloud-Objekte abgrenzen zu können.
define view entity SEDT_LANG_VRS_OBJ_ACTIVE_BDEF
as select distinct from reposrc
{
key 'BDEF' as object_type,
key cast((rtrim(left(progname, 30), '=')) as sobj_name) as object_name,
uccheck as abap_language_version
}
where
subc = 'B'
and r3state = 'A'
Als Ergebnis erhalten wir dann einfache Views, die immer gleich aufgebaut sind. Somit könnten wir in Zukunft standardisiert und einfacher die Objekte abgrenzen, zumindest, wenn wir uns die Abgrenzung über den Namen anschauen. Allerdings werden wir zum Beispiel bei generierten Namen noch Probleme haben, wenn zum Beispiel nur eine GUID vorhanden ist und wir dann auf Daten wie den erstellenden User gehen müssten. Dies macht es grundsätzlich einfacher, aber es gibt auch noch ungelöste Herausforderungen.
GitHub
Hier findest du das Open Source Projekt und weitere Informationen auf GitHub. Weitere Informationen zur Installation und zur Verwendung des Projekts findest du im Projekt und den verlinkten Ressourcen. Der Extraktionsbaustein befindet sich in einem eigenen Verzeichnis in der aktuellen Version 1.1.0.
Fazit
Die Ermittlung aller ABAP-Cloud-Objekte kann eine ziemliche Herausforderung sein, da es hier um exakte Zahlen und Ergebnisse geht. Erst einmal wurden wir in eine unklare Aufgabe hineingeworfen und mussten daraus selbst Schlüsse ziehen, wie wir Objekte aus den Tabellen herausbekommen, wie wir diese abgrenzen können, ob sie auch dem Kunden gehören und am Ende auch eine passende Lösung entwickeln, die uns ganz einfach eine Zahl zurückgibt. Einen Überblick über alle Objekte zu erhalten ist gar nicht so einfach, dank SAP gibt es hier aber eine zentrale Konfiguration.
