Wenn du Neptune SAP Edition Anwendungen pflegst, stehst du vor einer strukturellen Herausforderung: Die Laufzeitumgebung, der Designer und die gesamte Toolchain leben innerhalb von SAP NetWeaver. Die UI-Logik ist JavaScript, das in ABAP-Tabellen gespeichert ist, und der Lebenszyklus (Transporte, Änderungsanträge, ABAP-seitige Paketierung) ist vollständig an dein SAP-Basisteam gebunden.
Die Migration dieser Apps zu Simplifier verlagert die UI-Schicht aus SAP heraus in eine moderne Low-Code/Pro-Code-Plattform: OpenUI5 + TypeScript auf dem Client, JavaScript Business Objekte auf dem Simplifier Server und eine saubere Integrationsschicht zu SAP. SAP bleibt Eigentümer der Daten; Simplifier ist Eigentümer des Anwendungslebenszyklus. Da die Migration bewusst benutzerdefinierte ABAP-UI-Logik entfernt und sich ausschließlich auf Standard-SAP-Schnittstellen (BAPIs, SOAP-Services, OData V2/V4) verlässt, unterstützt sie aktiv die SAP Clean Core Strategie — dein S/4 HANA Core bleibt sauber und upgrade-sicher.
Dieser Artikel ist ein praktischer, technischer Leitfaden zur Neptune SAP Edition Migration. Er beschreibt die Voraussetzungen, die Daten, die du übergeben musst, wie eine KI-gestützte Migration in der Praxis funktioniert und wie die resultierende Architektur aussieht.
Bevor ein Migrationsprojekt beginnt, müssen auf Kundenseite folgende Punkte vorhanden sein:
Um die Migration effizient zu gestalten, sollte der Kunde pro Neptune-Anwendung einen vollständigen Datensatz vor dem Kick-off übergeben. Die fünf unten genannten Eingaben sind das Minimum.
Jede Neptune-App kann als einzelne XML-Datei exportiert werden. Diese Datei enthält den vollständigen Elementbaum (Steuerelemente, Eltern, Positionen, Ereignisse) und alle Attribute (Texte, Icons, Typen, Sichtbarkeit, Bindungen). Sie ist die maßgebliche Quelle für das UI-Layout und wird verwendet, um das Simplifier UI 1:1 zu rekonstruieren.
Neptune-Apps basieren in der Regel auf einer oder mehreren individuellen ABAP-Klassen, die SAP-Funktionalitäten kapseln (typisierte Eingabe-/Ausgabestrukturen, Fehlerbehandlung, Geschäftsvalidierungen). Der Quellcode der Klasse muss bereitgestellt werden, damit das Migrationsteam identifizieren kann, welche Standard-SAP-Funktionsbausteine, BAPIs, SOAP-Services oder OData-Services zugrunde liegen und welche Logik auf der Simplifier-Seite reproduziert werden muss. Wenn die App bereits einen SOAP-Endpunkt oder einen OData-Service aufruft, sollte auch das entsprechende WSDL- oder Service-Metadaten-Dokument bereitgestellt werden.
Der Kunde wählt einen oder mehrere Integrationspfade und stellt die entsprechenden Zugangsdaten bereit. Simplifier unterstützt alle vier, und ein einzelnes Business Objekt kann bei Bedarf mehrere Konnektoren kombinieren.
Jeder Pfad wird vom entsprechenden Simplifier Konnektor (RFC, SOAP, OData V2, OData V4) genutzt. Der Konnektor ist der einzige Pfad von Simplifier zu SAP.
Ein Screenshot pro Bildschirm (und pro relevantem Zustand: leer, geladen, Fehler). Screenshots sind entscheidend, da die Neptune-XML-Datei die Struktur, aber nicht das gerenderte Look-and-Feel enthält: Unternehmensfarben, Dichte, Beschriftungstexte, Anordnung der Fußzeilen-Buttons und bedingte Sichtbarkeit lassen sich anhand eines Bildes leichter überprüfen als anhand von XML.
Ein kleiner, realistischer Datensatz aus dem Quellsystem (z. B. offene Transportaufträge, eine Handvoll Stammsätze). Dieser wird während der Migration verwendet, um den Konnektor, das Business Objekt Mapping und den End-to-End UI-Flow anhand echter SAP-Antworten zu überprüfen – ohne ihn kann das Team nur mit Mock-Daten testen.
Die Migration wird von Simplifier-Beratern durchgeführt, die durch einen KI-Workflow unterstützt werden. Die KI ist kein Self-Service-Tool, das der Kunde bedient; sie ist ein Beschleuniger, der den Berater unterstützt und manuelle, repetitive Arbeit eliminiert.
Das Diagramm unten fasst die vier Phasen und die Aufteilung der Verantwortlichkeiten zwischen dem KI-Workflow und dem Simplifier-Berater zusammen.
Der Berater speist die Neptune-XML, die ABAP-Klasse (und alle SOAP/OData-Metadaten) und die Screenshots in den KI-Workflow ein. Die KI parst den UI-Baum, extrahiert jedes Label, Icon, jeden Button, Tab und jedes Sichtbarkeits-Flag und schlägt ein Mapping zu OpenUI5-Steuerelementen vor. Sie liest auch die ABAP-Klasse und Service-Definitionen, um die beteiligten SAP-Funktionsbausteine, BAPIs, SOAP-Operationen oder OData-Entitätssätze zu identifizieren und schlägt eine entsprechende Business Objekt Struktur auf der Simplifier-Seite vor. Der Berater überprüft und korrigiert das Mapping, bevor etwas generiert wird.
Der Berater verwendet die Simplifier-Plattform, um den entsprechenden Konnektor (RFC, SOAP, OData V2 oder V4) mit den vom Kunden bereitgestellten Zugangsdaten zu erstellen, generiert die Konnektor-Aufrufe für die relevanten Operationen oder Entitätssätze und erstellt Business Objekte, die diese Aufrufe orchestrieren. Die KI unterstützt dabei, indem sie BO-Funktionscode aus der ABAP-Logik entwirft, die Eingabe-/Ausgabeparameterdefinitionen generiert und eine erste Runde von Mock-Daten für Offline-Tests erstellt. Jede BO-Funktion wird gegen das echte SAP-Backend getestet, bevor UI-Arbeiten beginnen.
Die KI generiert die OpenUI5-XML-Views (die das Neptune-Layout pixelgenau mit den Screenshots abgleichen), TypeScript-Controller (Event-Handler, BO-Aufrufe, View-Model-Zustand) und i18n-Ressourcen-Bundles in den relevanten Sprachen. Eine Login-View wird hinzugefügt, um die Simplifier-Authentifizierung zu handhaben. Der Berater führt Lint, Type-Check und UI5-Linter aus, behebt verbleibende Probleme und überprüft das Ergebnis in einem Browser.
Automatisierte Browser-Tests durchlaufen die wichtigsten Benutzerabläufe gegen das Live-SAP-Backend. Offene Probleme werden verfolgt und gelöst. Der Berater stellt die Anwendung in der Simplifier Dev-Stage des Kunden bereit, führt eine Abnahme mit dem Business Owner durch und übergibt den Quellcode über Git. Die eigenen Entwickler des Kunden können ab diesem Zeitpunkt mit einer voll funktionsfähigen, modernen Codebasis übernehmen.
Typischer Aufwand: Ein einzelner Neptune-Bildschirm mittlerer Komplexität (1 Eingabe, 1–2 Backend-Aufrufe, 3–4 Detail-Tabs) wird in 1–2 Beratungstagen migriert – einschließlich SAP-Verbindungsaufbau, BO-Erstellung, UI-Rekonstruktion und End-to-End-Test. Ohne KI-Unterstützung würde derselbe Aufwand typischerweise 5–7 Tage betragen.
Die migrierte Anwendung ist eine eigenständige Simplifier-App: Sie existiert vollständig außerhalb von SAP NetWeaver, hat ihren eigenen Lebenszyklus und greift auf SAP nur als Datenquelle über einen klar definierten Connector zu. Das folgende Diagramm zeigt die Zielarchitektur – wobei alle vier Integrationspfade (RFC, SOAP, OData V2, OData V4) ausschließlich über Standard-SAP-Schnittstellen geleitet werden, ganz im Sinne der SAP Clean Core-Strategie.
Eine Neptune SAP Edition Migration zu Simplifier löst die Abhängigkeit von SAP NetWeaver als UI-Laufzeitumgebung. Der Kunde behält SAP als zuverlässige Datenquelle – erreichbar über RFC, SOAP oder OData V2/V4 – gewinnt aber eine moderne, IDE-freundliche, Git-verwaltete Anwendungsplattform mit einem deutlich kürzeren Entwicklungs- und Deployment-Zyklus – und bleibt dabei im Einklang mit der SAP Clean Core Strategie. Mit KI-gestützten Tools auf Beraterseite kann ein typischer Neptune-Bildschirm in 1–2 Tagen End-to-End migriert werden – einschließlich SAP-Konnektivität, Echtdaten-Tests und Übergabe.
Sprich mit deinem Simplifier-Ansprechpartner, um eine Migrationsbewertung für deine Neptune-Apps zu vereinbaren.