Zum Inhalt springen

SAP-Daten für Anwendungen und KI nutzbar machen

Ich bin der Entwickler zwischen Ihrem SAP-Team und der Web-, Cloud- und KI-Welt: Ich baue die OData-Services und CDS-Views selbst und hänge daran das, was damit arbeiten soll – eine Anwendung, ein Portal oder ein Sprachmodell. Als Freelancer, remote in der DACH-Region und vor Ort in NRW.

  • OData- und REST-Schnittstellen zu SAP
  • CDS-Views und ABAP-Grundlagen
  • KI und LLMs auf SAP-Daten – ohne Umgehung von Berechtigungen
  • Mitgründer von compliu (Security für SAP-Landschaften)

Die Brücke zwischen SAP und dem Rest Ihrer IT

In vielen Unternehmen liegen die wichtigen Daten im SAP-System, während die Anwendungen, mit denen täglich gearbeitet wird, daneben stehen: ein Kundenportal, eine interne Fachanwendung, eine mobile App, ein Reporting-Dienst. Dazwischen entstehen Excel-Exporte, nächtliche Dateiablagen und manuelle Übertragungen. Genau diese Lücke schließe ich – mit Schnittstellen, die dokumentiert, überwacht und wartbar sind.

Mein Schwerpunkt liegt auf der Integrationsseite. Ich lese und schreibe SAP-Daten über OData- und REST-Services, modelliere die CDS-Views dafür selbst, verstehe ABAP so weit, dass ich Coding lesen, kleinere Erweiterungen umsetzen und mit Ihren SAP-Entwicklern auf Augenhöhe sprechen kann. Dazu kommt die Seite, auf der ich seit über zehn Jahren zu Hause bin: Java, .NET, TypeScript, PHP, Python, Microservices, Cloud und Deployment.

Seit einiger Zeit ist die häufigste Frage: „Kann unsere KI auch auf die SAP-Daten zugreifen?“ Genau dort treffen sich meine beiden Schwerpunkte. Wer ein Sprachmodell an SAP anbindet, braucht beides – jemanden, der die Sicht auf die Daten im SAP-System baut, und jemanden, der weiß, wie ein LLM damit umgeht, ohne Berechtigungen zu umgehen oder Daten unkontrolliert abfließen zu lassen.

Mit compliu, meiner eigenen Plattform für Compliance und IT-Security in SAP-Landschaften, arbeite ich täglich an genau diesen Themen: SAP-Ereignisse auslesen, verarbeiten und in moderne Systeme überführen. Was ich dort über Datenmodelle, Schnittstellen und Betrieb lerne, fließt direkt in Kundenprojekte ein – nachzulesen unter compliu.de.

Was ich im SAP-Umfeld übernehme

Vier Bausteine rund um Schnittstellen und Datenflüsse – einzeln oder als durchgehende Anbindung.

KI und LLMs an SAP-Daten anbinden

Der Anwendungsfall, nach dem zurzeit am häufigsten gefragt wird: ein Assistent, der Aufträge, Stammdaten oder Belege aus SAP beantwortet. Ich baue dafür die CDS-View oder den OData-Service als saubere Grundlage – statt Rohtabellen in eine Vektordatenbank zu kippen – und binde das Modell über Werkzeugaufrufe oder MCP an. Entscheidend ist dabei, dass die Berechtigungen des fragenden Nutzers erhalten bleiben und niemand über den Umweg KI Daten sieht, die er in SAP nicht sehen dürfte.

  • OData
  • CDS Views
  • RAG
  • MCP

OData- & REST-Schnittstellen

Anbindung Ihrer Anwendungen an SAP über OData-Services oder vorgelagerte REST-APIs: Filter und Paging sinnvoll gesetzt, Authentifizierung geklärt, Fehler- und Wiederholungslogik definiert. Ergebnis ist eine Schnittstelle, die auch unter Last und bei Wartungsfenstern berechenbar bleibt.

  • OData
  • REST
  • SAP Gateway
  • OAuth

CDS-Views & Datenmodellierung

Auswertungsfähige Sichten auf die Daten, die Ihre Anwendung wirklich braucht – statt Rohtabellen über die Leitung zu schieben. Ich modelliere CDS-Views mit dem SAP-Team, lege die Freigabe als Service fest und prüfe, welche Felder fachlich und datenschutzrechtlich überhaupt nach außen gehören.

  • CDS Views
  • S/4HANA
  • SAP HANA
  • RAP

ABAP-Unterstützung

Ich lese ABAP-Coding, arbeite mich in bestehende Programme und Erweiterungen ein und setze überschaubare Anpassungen selbst um – objektorientiert, mit den ABAP Development Tools in Eclipse. Für größere ABAP-Entwicklungen bleibt Ihr SAP-Team federführend, ich liefere Schnittstellen und Zuarbeit.

  • OO-ABAP
  • ABAP Development Tools
  • Erweiterungen
  • SAP IS-U

Middleware & Datenflüsse

Zwischen SAP und Zielsystem liegt meist mehr als ein Aufruf: Mapping, Validierung, Zwischenspeicherung, Wiederaufsetzen nach Fehlern. Ich baue diese Schicht als eigenen Service – mit Message-Queues, Idempotenz, Monitoring und einem Protokoll, das im Fehlerfall zeigt, welcher Satz wo hängen geblieben ist.

  • RabbitMQ
  • ETL
  • Idempotenz
  • Monitoring

Typische Einsatzfelder

Situationen, in denen ein Integrationsentwickler neben dem SAP-Team den Unterschied macht.

Assistent, der SAP-Daten beantwortet

Mitarbeitende fragen in natürlicher Sprache nach Aufträgen, Lieferungen oder Stammdaten, statt sich durch Transaktionen zu klicken. Die Antwort stammt aus einer definierten Sicht auf das SAP-System, nennt ihre Quelle und zeigt nur das, was die fragende Person ohnehin sehen darf.

Portal oder Fachanwendung auf SAP-Daten

Kunden, Partner oder Mitarbeitende sollen Stammdaten, Aufträge oder Belege sehen und bearbeiten, ohne SAP-Zugang zu bekommen. Die Anwendung entsteht als moderne Weboberfläche, SAP bleibt führendes System – verbunden über eine schlanke, dokumentierte Schnittstelle.

Mobile App mit SAP-Anbindung

Außendienst, Technik oder Lager arbeiten mobil und brauchen Daten aus SAP auch dann, wenn das Netz schwach ist. Ich baue die App samt Offline-Puffer und die Synchronisation, die Änderungen zuverlässig und nachvollziehbar zurückschreibt.

Reporting und Datenexport

Auswertungen, Dashboards oder Übergaben an ein Data Warehouse, die heute per Hand entstehen, werden zu einem automatisierten Datenfluss: CDS-View als Quelle, definierter Zeitplan, Protokoll über jeden Lauf und eine Meldung, wenn etwas ausbleibt.

Drittsysteme an SAP anschließen

Shop, CRM, Zeiterfassung oder ein Branchensystem sollen Daten mit SAP austauschen. Ich kläre die fachlichen Regeln, baue das Mapping und sorge dafür, dass doppelte oder verspätete Nachrichten keinen Schaden anrichten.

So gehe ich vor

SAP-Projekte scheitern selten an der Technik, sondern an unklaren Zuständigkeiten zwischen SAP-Team und Anwendungsentwicklung. Deshalb dieser Ablauf.

  1. 01

    Datenbedarf klären

    Gemeinsam mit Ihrem Fachbereich und Ihrem SAP-Team legen wir fest, welche Objekte und Felder tatsächlich gebraucht werden, in welcher Richtung sie fließen und wie aktuell sie sein müssen. Das entscheidet über Aufwand und Architektur.

  2. 02

    Schnittstelle abstimmen

    Wir prüfen, was bereits an Services vorhanden ist, und ergänzen nur das Nötige – CDS-View, OData-Service oder eine vorgelagerte API. Berechtigungen, technische Nutzer und Testsystem klären wir hier, nicht kurz vor dem Go-live.

  3. 03

    Anbindung & Härtung

    Implementierung der Integrationsschicht mit Tests gegen das SAP-Testsystem, Fehlerbehandlung, Wiederaufsetzpunkten und Monitoring. Danach ist sichtbar, ob ein Lauf gelaufen ist – und nicht erst, wenn der Fachbereich sich meldet.

  4. 04

    Betrieb & Übergabe

    Deployment über CI/CD, dokumentierte Schnittstellenbeschreibung und eine Übergabe an Ihr Team. Auf Wunsch bleibe ich für Weiterentwicklung und Wartung ansprechbar.

Technologien

Was konkret zum Einsatz kommt, hängt von Ihrem SAP-Release, den vorhandenen Services und dem Zielsystem ab.

SAP

  • OData
  • CDS Views
  • OO-ABAP
  • RAP
  • S/4HANA
  • SAP IS-U

Integration

  • REST
  • SAP Gateway
  • RabbitMQ
  • JSON / XML
  • ETL-Pipelines
  • OAuth

Anwendung

  • TypeScript
  • React
  • Angular
  • Java / Spring Boot
  • C# / .NET
  • Flutter

Betrieb

  • Docker
  • Kubernetes
  • Terraform
  • Azure
  • AWS
  • CI/CD

Lassen Sie uns über Ihre SAP-Schnittstelle sprechen

Beschreiben Sie kurz, welche Daten aus SAP heraus oder hinein sollen und welches System daran hängt. Ich melde mich mit einer ehrlichen Einschätzung des Wegs dorthin.

patrick.teiting@gmx.de