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 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 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 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 ist stillgelegt.
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.
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. 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.