Zwölf SAP-GUI-Transaktionen, drei je Stammobjekt, geschrieben in den späten Neunzigern. Ein Agent, zwei MCP-Server, keine Zeile Code von Hand. Herausgekommen ist nicht dieselbe Anwendung in neuem Rahmen, sondern eine bessere, weil die Entscheidungen aus dem Gesamtbild des Systems getroffen wurden und nicht aus einem Programm nach dem anderen. Hier der Ablauf, mit Belegen.
Der Ausgangspunkt
Die Legacy-Anwendung verwaltet Flüge, Buchungen, Kunden und Reisebüros. Zwölf Modulpools tragen sie: je Stammobjekt eine Transaktion zum Anzeigen, eine zum Ändern, eine zum Anlegen. Jede hat eigene Dynpros, eigene Feldprüfungen und eine eigene Kopie der Regeln. Ein nächtlicher Prüflauf repariert, was die Dialoge tagsüber nicht validiert haben.
Eine Migration, die diese Programme eins nach dem anderen liest und eins nach dem anderen neu baut, endet mit zwölf Fiori-Apps, die dieselben Fehler in einem neuen Framework wiederholen. Das Interessante passiert, bevor irgendetwas gebaut wird.
Was das Gesamtbild gezeigt hat
Bevor der Agent etwas geschrieben hat, hat er den Wissensgraphen des Systems über Sysparency-MCP-Server gelesen: welche Programme es gibt, welche Tabellen sie schreiben, wer wen aufruft, wie oft jede Transaktion läuft und welche Geschäftsregeln gelten. Drei Befunde haben das Design verändert.
Die Dialoge sind nicht die einzigen Schreiber der Buchungstabelle. Der Graph listet elf Anwendungen, die auf SBOOK zugreifen. Neben den drei Dialogprogrammen fügt die Funktionsgruppe SAPBC_GLOBAL_FIS ein und ändert, die BAPI-Gruppe SAPBC_BAPI_SBOOK ändert, und der ALE-Generator SAPBC_DATA_GENERATOR_ALE löscht. 35 RFC-fähige Funktionsbausteine sitzen auf denselben Tabellen. Eine neue App, die nur die Dialoge ersetzt, wäre ein weiterer Schreiber unter vielen.
Ein nächtlicher Prüflauf repariert, was der Eingang nicht validiert. Im Graph steht ein Prüfprogramm mit Nutzung 0, das die drei Stammtabellen liest, und ein ATC-Befund der Priorität 1, eine fehlende Berechtigungsprüfung, auf dem Änderungsdialog. Die Regeln selbst leben im Funktionsbaustein SAPBC_GLOBAL_BOOK: ungültiger Kunde, ungültiges Reisebüro, ungültige Klasse, Flug ausgebucht.
73 Prozent aller Aufrufe sind reine Anzeige. Die Nutzungszähler je Transaktion zeigen 4 870 Anzeigeaufrufe gegenüber 158 Änderungen durch Reisebüros. Die Anwendung wird weit öfter gelesen als geschrieben.
Wie der Agent gearbeitet hat
Der Agent hatte zwei Werkzeuge. Sysparency-MCP-Server beantwortet Fragen zum bestehenden System mit belegten Fakten: Graphabfragen, semantische Suche über die fachlichen Beschreibungen, der Quelltext eines Programms, die Felder eines Dynpros. SAP-ADT-MCP-Server legt Objekte im Zielsystem an, ändert und aktiviert sie. Die Schleife ist immer dieselbe: den Graphen fragen, entscheiden, bauen, prüfen.
Für das neue System hat er vier RAP-Business-Objekte mit CDS-Views, Behavior Definitions und Behavior Implementations angelegt, einen OData-V4-Service, drei Fiori-Elements-Apps für Flüge und Buchungen, Kunden und Reisebüros, ein Analytics-Dashboard und das Launchpad, das alles zusammenhält. Jedes Objekt wurde über ADT generiert und aktiviert. Die Beteiligten haben geprüft und entschieden; niemand hat ABAP getippt.
Was anders gebaut wurde
Regeln einmal, im Datenmodell. Die sieben Prüfungen, die vorher über zwölf Programme und einen Nachtlauf verstreut waren, greifen jetzt beim Speichern, innerhalb der Business-Objekte: Verbindung existiert, Flugdatum gültig, Kapazität nicht überschritten, Kunde existiert, Reisebüro existiert, Klasse gültig, Plätze verfügbar. Der Prüflauf, den der Graph mit Nutzung 0 zeigt, wird zum Kontrollreport, bis auch die verbleibenden direkten Schreiber über die Business-Objekte laufen.
Ein Klickpfad statt drei Transaktionen. Eine Buchung wird auf einer Object Page angelegt, geändert und angezeigt. Der Lesemodus ist Standard, weil 73 Prozent der Aufrufe genau das tun; Bearbeiten ist ein bewusster Schritt.
Ein Feld weniger. Das überholte Raucherkennzeichen, das die alten Dynpros noch mitführen, ist aus der neuen Oberfläche verschwunden. Die Datenbankspalte bleibt bis zum nächsten Schritt.
Vier Auswertungen, die es nie gab. Flüge, Sitze und Umsatz je Airline, Buchungen nach Klasse und Storno, ein Ranking der Reisebüros und ein Buchungstrend, alles als CDS-Analytik auf denselben Tabellen.
Von Dynpro zu Fiori: Muster, nicht Bildschirme
Die Frage lautet meist „wie migriere ich ein Dynpro nach Fiori“ oder „wie wird ein Selektionsbild zu UI5". Die ehrliche Antwort: Eine Umstellung Bildschirm für Bildschirm ist die falsche Arbeitseinheit. SAPs Fiori-Design-Richtlinien setzen bei Aufgabe und Rolle des Nutzers an, nicht beim vorhandenen Bildschirm, und Fiori Elements erzeugen die Oberfläche aus Annotationen am Datenmodell. Übersetzt wird das Muster hinter einem Dynpro-Mechanismus, nicht das Feld auf dem Bildschirm. Das ist aus den zwölf Transaktionen geworden:
| Dynpro-Muster | Wurde zu | Warum das kein 1:1 ist |
|---|---|---|
| Drei Transaktionen je Objekt: anzeigen, ändern, anlegen | Eine Object Page mit RAP-Draft | Ein Modus statt eines Programms; Lesen ist Standard |
| Selektionsbild mit SELECT-OPTIONS | Filterleiste des List Report, aus CDS-Annotationen | Keine Ablauflogik mehr zu pflegen |
| ALV-Liste | Tabelle des List Report | Sortieren, Filtern und Export gibt es umsonst |
| PAI-Prüfungen in Modulpools | RAP-Validierungen beim Speichern | Einmal im Datenmodell statt einmal je Dynpro |
| PBO-Feldattribute: Pflicht, gesperrt | Feature Control und Annotationen | Zentral statt je Bildschirm |
| Suchhilfen, F4 | Wertehilfe-Annotationen auf CDS-Views | Wiederverwendbar über Apps hinweg |
| AUTHORITY-CHECK im Programm | RAP-Berechtigungen, global und je Instanz | Sichtbar und prüfbar statt versteckt |
| Nachtlauf, der fehlerhafte Eingaben repariert | Validierungen am Eingang | Die Regel wandert dorthin, wo die Daten hereinkommen |
| Ein Transaktionscode je Objekt | Launchpad-Kachel je Rolle | Zugang nach Aufgabe, nicht nach Programm |
Die drei Modi der alten Anwendung, anzeigen, ändern, anlegen, fallen in eine Object Page zusammen, weil das RAP-Draft-Handling ungespeicherte Änderungen für den Nutzer hält; diesen Code schreibt niemand mehr.
Wann ein Dynpro bleiben darf
Nicht jede Transaktion gehört nach Fiori. Geübte Nutzer, die täglich hunderte Datensätze erfassen, sind auf einem gut gebauten Dynpro schneller als auf einer Object Page mit Draft; Custom-Transaktionen laufen unter S/4HANA weiter, und SAP GUI for HTML bringt sie auf dasselbe Launchpad. Das Kriterium ist nicht das Alter, sondern die Nutzung: wie oft eine Transaktion läuft, wer sie aufruft und wie viel dort getippt wird. In dieser Anwendung hat keines der vier Objekte dieses Profil, 4 870 Anzeigeaufrufe gegen 158 Änderungen, also gingen alle zwölf. In einem anderen System würden die Nutzungszähler zwei davon am Leben lassen, und der Graph würde sagen, welche zwei.
Die Zahlen
- 12 zu 4: Zwölf Programme wurden vier Business-Objekte hinter einem OData-Service.
- 3 zu 1: Drei Transaktionen je Buchung wurden ein Klickpfad.
- 0 zu 7: Sieben Regeln beim Speichern statt eines nächtlichen Prüflaufs.
- 0 zu 4: Vier Auswertungen: KPIs, Charts, Ranking, Trend.
Was es nicht ist
Die Anwendung läuft auf SAP-Referenzdaten in einem Trial-System, nicht in einem Kundensystem. RFC, ALE und IDoc schreiben weiterhin direkt in die Tabellen; sie über die Business-Objekte zu führen, ist der dokumentierte nächste Schritt, und die Liste dessen, was zu führen ist, existiert bereits, weil der Graph sie geliefert hat. Die zwölf GUI-Transaktionen bleiben während der Umstellung aufrufbar; die Nutzungszähler entscheiden, wann jede einzelne abgeschaltet wird. Der Neubau hat einen Nachmittag Agentenzeit und ein paar Stunden menschliche Prüfung gekostet.
Was das für Ihr System heißt
Die Lehre ist nicht, dass ein Agent ABAP erzeugen kann. Das kann er, und das können mehrere Werkzeuge. Die Lehre ist, woher die Designentscheidungen kamen: aus dem Gesamtbild des Systems, mit jeder Abhängigkeit, jedem Schreiber, jedem Nutzungszähler und jeder Regel, belegt bis zur Quellzeile. Ohne dieses Bild hätte der Agent zwölf Programme nachgebaut. Mit ihm hat er eine Anwendung gebaut und das System im selben Zug verbessert.
Jedes Custom-System trägt dieselben Fragen. Wer schreibt sonst noch in diese Tabelle? Was repariert der Nachtjob? Welche dieser Transaktionen benutzt überhaupt noch jemand? Sysparency beantwortet sie aus dem Code, für Menschen und für Agenten, bevor die erste Zeile des neuen Systems erzeugt wird.