ADT - RAP Analyzer [MIA]
Die Einarbeitung und Übersicht in bestehende RAP Objekte kann nicht immer einfach sein, vor allem wenn es sich um komplexe Objekte handelt. Fragen wie das verwendete Pattern und wichtige Objekte müssen sich meist erarbeitet werden.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns die IDE Action für den RAP Analyzer als Prototypen an und wie du damit bestehende Objekte prüfen kannst.
Einleitung
IDE Actions sind eine einfache Möglichkeit die ABAP Development Tools zu erweitern und zusätzliche Funktionen für den Entwickler zur Verfügung zu stellen. Dabei besteht vor allem im ABAP Cloud Umfeld aktuell eine größere Herausforderung, da nicht immer die passenden APIs zur Verfügung stehen und damit alle Funktionen umgesetzt werden können.
Idee
Die Idee des RAP Analyzer ist die schnelle Analyse und Navigation innerhalb eines RAP Objekts. Dabei gehen wir davon aus, dass wir zwar durch die Anwendung den Service kennen, aber nicht alle Details. Die Navigation durch den kompletten Stack kann daher immer mit Problemen verbunden sein, vor allem wenn du vielleicht nur die Festwerte eines Objekts oder die Metadata Extension auf einer bestimmten Ebene anpassen willst. Daher analysieren wir über den Service den RAP Stack bis zur Datenbank und listen die Informationen als Ergebnis in einer Tabelle auf.
- Analyse und Visualisierung des RAP Stacks
- Schnelle Navigation durch ADT Links
Entwicklung
Schauen wir uns einmal ein paar Details zur Entwicklung der IDE Action an und gehen in die verschiedenen Bestandteile.
IDE Action
Die eigentliche IDE Action ist sehr einfach gehalten, wir wollen eigentlich nur Service Bindings analysieren und benötigen in diesem Fall kein UI. Damit haben wir die implementierende Klasse, eingeschränkt auf ein Service Binding.
Daher besteht die eigentliche Aktion aus nur wenigen Zeilen Code, da wir den Großteil in Hilfsklassen auslagern. Wir holen uns die aktuelle Ressource, lesen dazu den Typen und den Namen und übergeben die Objekte an den Analyzer. Dieser übernimmt nun die Analyse des RAP Stacks und gibt ein strukturiertes Ergebnis an den Aufrufer zurück. Das Ergebnis übergeben wir an die HTML Output, die uns eine entsprechende Tabelle, Links, usw. für die Ausgabe erstellt. Das Ergebnis übergeben wir dann an den HTML Output der IDE Action.
DATA(resource) = context->get_focused_resource( ).
DATA(analyzer) = zcl_mia_core_factory=>create_rap_analyzer( object_name = resource->get_name( )
object_type = resource->get_type( ) ).
DATA(rap_object) = analyzer->get_rap_object( ).
DATA(html_content) = zcl_mia_core_factory=>create_html_output( )->generate_rap_object( rap_object ).
DATA(html_output) = cl_aia_result_factory=>create_html_popup_result( ).
html_output->set_content( html_content ).
result = html_output.
Analyse
Die eigentliche "Magie" passiert bei der Analyse der Objekte. Wir analysieren den Stack vom Service Binding aus, da es hier einen direkten Weg nach unten zum RAP Objekte und den Tabellen gibt. Auch steigen die meisten Entwickler von der App im Service ein. Außerdem besteht die Chance, dass auf einem RAP Objekt mehrere andere Objekte und Apps erstellt werden, was die eigentliche Analyse schwerer macht. Dabei gehen wir durch die verschiedenen Objekte und Beziehungen und erstellen im ersten Schritt eine Liste der Objekte, die wir für die Analyse brauchen.
Im zweiten Schritt bauen wir das eigentliche RAP Objekt zusammen. Hier möchten wir pro Ebene (Interface, Projection) die Abhängigkeiten darstellen. Also beginnen wir mit der Root Entität, dann den Childs und Grandchilds, um eine Hierarchie zu erhalten, die wir später darstellen können. Allerdings gibt es aktuell auch einige Limitationen, die wir über die XCO APIs nicht zu 100% abdecken können. So können wir die Behavior Definition und die Metadata Extension nicht zum Core Data Service ermitteln, sondern gehen davon aus, dass diese den gleichen Namen wie der Core Data Service haben. Über XCO können wir das überprüfen, aber bei abweichenden Namen haben wir aktuell keine Chance es performant zu lesen. Nach dem ersten Durchlauf erhalten wir eine Liste von Objekten mit ihren Abhängigkeiten:
Nach der Restrukturierung der Objekte in Layer und Hierarchien, erhalten wir die finale Struktur, um die Ausgabe vorzubereiten. Wir haben den Service, die ROOT Ebene und die verschiedenen Unterobjekte.
Ausgabe
Für die Ausgabe bereiten wir die Objekte vor und erzeugen eine HTML Tabelle. Jedes Objekt erhält einen ADT Link, damit wir schneller zwischen den Objekten navigieren können. Da es aktuell keine API von SAP zur Erzeugung der ADT Links gibt, verwenden wir hier einfach eine eigene Klasse, um die Links zu erzeugen. Als Ergebnis erhalten wir einen String mit HTML, den wir an die Ausgabe übergeben können.
Test
Testen wir einmal die Aktion im System und an verschiedenen Services und schauen uns das Ergebnis und die Unterschiede an.
Standard
Schauen wir uns dazu den Service ZBS_UI_COMPANY_O4 an, diesen findest du bei den RAP Examples (REX) auf GitHub. Dieser Service ist relativ Standard, wurde mit dem "Generator from Scratch" erstellt und hat auch tiefe Strukturen. Es werden alle eigenen Domänen angezeigt die Festwerte enthalten, da diese meist auch erweitert werden und ein schneller Zugriff möglich sein soll.
Custom Entity
Als zweites Beispiel nehmen wir eine Custom Entity als Beispiel für die Analyse. Hier ist zum Beispiel kein Projection Layer möglich und keine Metadata Extension, daher erhalten wir hier auch weniger Objekte.
Pattern
Im oberen Teil wirst du auch die unterschiedlichen RAP Pattern finden, hier versuchen wir mit der Analyse zu erkennen, um welches Pattern es sich handelt. Mit einem Pattern sind automatisch unterschiedliche Eigenschaften des Objekts zu erkennen. Ein Standard Pattern hat die größte Anzahl an Objekten, die Metadaten liegen in eigenen Objekten und wir haben ein eigenes Datenmodell. Ein Custom Pattern hat keine Projektion und die Metadaten liegen immer in der Custom Entity, da keine eigenen Objkte möglich sind. Aktuell werden noch nicht alle Pattern unterstützt oder können zu 100% richtig definiert werden.
Performance
Die Analyse und Anzeige des Ergebnisses dauert einige Sekunden und ist nicht sofort verfügbar. Das liegt vor allem an der Laufzeit der XCO Klasse die bei der Massenanalyse leider nicht die performantesten Klassen sind. In Standard ABAP könnte sicherlich eine auf Performance zugeschnittene Selektion und Analyse erstellt werden, in ABAP Cloud sind wir aber an die öffentlichen APIs gebunden.
In Action
Möchtest du noch weitere Erklärungen zum RAP Analyzer oder zur Erstellung von IDE Actions, dann findest du noch eine Devtoberfest Session vom letzten Jahr, wo wir praktisch durch das Thema gehen.
Vollständiges Beispiel
In diesem Artikel haben wir verschiedene Referenzen aus unseren Projekten verwendet. Auf GitHub findest du weitere Informationen zu den Projekten. Wenn du die IDE Actions einmal auf eigene Faust testen willst, dann findest du das Repository ebenfalls da:
- RAP Examples (REX) - Einige Beispiel zu verschiedenen Entwicklungen und Pattern für die Analyse und zum Testen der RAP Aktionen.
- My IDE Actions (MIA) - Alle entwickelten IDE Actions im Framework.
Fazit
Der RAP Analyzer ist vor allem erst einmal ein Prototyp und funktioniert schon recht gut mit dem klassischen RAP Stack. Spezielle Pattern werden teilweise erkannt, es ist aber zum Beispiel keine volle Umfeldanalyse möglich, da die aktuellen XCO APIs nicht den kompletten Zugriff erlauben und wir somit nicht alle Informationen ableiten können.
