Kontext
In fast jedem SAP-Umfeld gibt es die gleiche Routine: Der Fachbereich braucht Daten in einem System, und die Entwicklung schreibt dafür ein Skript. Beim nächsten Datenobjekt das nächste Skript, bei jeder Änderung ein Ticket. Die Beladung selbst ist selten schwierig. Aufwendig ist, dass sie jedes Mal neu gebaut wird.
Genau dieses Muster wollten wir aus dem Weg räumen: eine Oberfläche, in der Quelle und Ziel gewählt werden, und die Beladung dahinter läuft ohne eigenen Code.
Warum die SAP BTP
Die Zielsysteme sind SAP-Systeme, die Nutzer arbeiten im SAP-Umfeld. Eine Plattform außerhalb hätte für jede Verbindung Anmeldung, Zertifikate und Netzwerkzugang selbst gebaut. Auf der BTP ist das schon da:
- Destinations. Jede Verbindung zu einem Quell- oder Zielsystem wird einmal als Destination angelegt. Anmeldeverfahren, Token und Zertifikate verwaltet die Plattform, der Code kennt nur den Namen der Verbindung. Für die meisten Systeme war die Authentifizierung damit erledigt, bevor eine Zeile geschrieben war.
- Cloud Connector. On-Premise-Systeme hinter der Firewall werden über den Cloud Connector erreichbar, ohne dass der Kunde Ports öffnet.
- Identity Service. Anmeldung und Benutzerverwaltung kommen vom SAP Cloud Identity Service, oft schon mit dem Firmen-Login des Kunden verbunden.
- Subaccounts. Jeder Kunde bekommt seinen eigenen Subaccount. Die Mandantentrennung ist damit eine Eigenschaft der Plattform, kein Konzept in unserem Code.
Wie wir es gelöst haben
Der Kern ist ein generisches Mapping statt eines Skripts pro Entität. Die Anwendung liest die Struktur des Ziels, legt die Felder der Quelle daneben, und der Fachbereich ordnet zu. Was früher Entwicklungsarbeit war, ist damit Konfiguration.
Angefangen haben wir mit Flatfiles nach SAP BW, S/4HANA und AWS. Der zweite Schritt war die Anbindung über REST und OData, damit Daten direkt aus einem System kommen können und nicht erst als Datei exportiert werden müssen. Seitdem sind Quelle und Ziel frei kombinierbar: Datei nach BW, S/4HANA nach AWS, ein REST-Dienst nach S/4HANA, alles über dasselbe Mapping. Ein angebundenes System ist dabei nicht auf eine Rolle festgelegt: Dasselbe S/4HANA kann in einem Lauf Quelle sein und im nächsten Ziel.
Eine Beladung startet der Fachbereich sofort von Hand oder plant sie ein, etwa nächtlich oder zum Monatswechsel. Beides läuft über denselben Lauf, nur der Auslöser unterscheidet sich.
| Baustein | Technik | Entscheidung |
|---|---|---|
| Oberfläche | SAPUI5 | Ein Bildschirm für Quelle, Ziel und Mapping, kein Assistent mit zehn Schritten |
| Backend | SAP CAP | Mapping, Zeitplan, Läufe und Protokoll an einem Ort, unabhängig von Quelle und Ziel |
| Anbindung | Destinations, REST, OData | Quellen werden als Destination registriert, nicht im Code hinterlegt |
Bereitgestellt wird das Ganze als SaaS: Ein Kunde bucht, bekommt seinen Subaccount, seine Anmeldung und seine Destinations. Das dauert Tage, nicht Wochen, weil nichts davon projektspezifisch gebaut wird.
Erkenntnisse
- Das Mapping ist das Produkt. Alles andere, Upload, Protokoll, Rechte, ist Standard. Die Zeit gehört in die Zuordnungslogik und ihre Fehlermeldungen.
- Die Plattform trägt mehr, als man am Anfang glaubt. Anmeldung, Verbindungen und Mandantentrennung haben wir nicht gebaut, sondern konfiguriert. Der eigene Code ist dadurch klein geblieben.
- Fehler müssen für den Fachbereich lesbar sein. Sobald Nicht-Entwickler laden, reicht ein Log nicht. Die App muss sagen, welche Zeile warum nicht angekommen ist.