S/4HANA Architektur

Entwicklung von OData Services in ABAP

von SEGW über OData und BOPF bis RAP

(C) Brandeis Consulting📁

Einleitung: OData im SAP Kontext

  • OData als Standard-API für Datenzugriff über HTTP
  • In SAP für Fiori, UI5 und Integration mit externen Systemen essentiell
  • Entwicklung von OData-Services über verschiedene Generationen möglich

Quellen:

(C) Brandeis Consulting📁

Evolution of the ABAP programming model

Evolution of the ABAP programming model

(C) Brandeis Consulting📁

Historischer Ansatz: SAP Gateway und SEGW

  • SAP Gateway (seit ca. 2012), zentrale Technologie zur OData-Erstellung
  • Transaktion SEGW (Service Builder): Modellierung von Datenmodellen, Entitäten und Services
  • Generierung von ABAP-Klassen und Implementierung der Business-Logik

Quellen:

(C) Brandeis Consulting📁

SEGW: Lebenszyklus eines OData Service

  • Data Model anlegen (Entitäten, Beziehungen)
  • Methoden zur Datenbereitstellung implementieren (CRUD)
  • Service registrieren und veröffentlichen
  • Metadaten und URLs automatisch generiert

Quellen:

(C) Brandeis Consulting📁

OData.publish: Direkte OData-Services aus ABAP

  • Seit SAP NetWeaver 7.50, Funktion [OData.publish] verfügbar
  • Aktivierung direkt auf CDS-Views für einfache, lesende Services
  • Minimaler Entwicklungsaufwand – automatische Generation von OData-Service
  • ABAP CDS-View mit Annotation „@OData.publish: true“
  • Service sofort konsumierbar, Metadaten werden automatisch bereitgestellt
  • Typisch für einfache Reporting-Szenarien und Fiori Apps

Quellen:

(C) Brandeis Consulting📁

CDS + BOPF (Business Object Processing Framework)

  • Erweiterung von CDS mit BOPF für transaktionale OData-Services
  • BOPF-Objekte steuern komplexe Logik (Validierung, Actions)
  • OData-Service kann automatisch aus CDS + BOPF-BO erzeugt werden
  • ABAP Programming Model for SAP Fiori

Quellen:

(C) Brandeis Consulting📁

ABAP RESTful Application Programming Model (RAP)

  • Modernste Methode für OData-Serviceentwicklung (ab 2019, S/4HANA Cloud & OnPrem)
  • Deklaratives Datenmodell mit CDS, Transaktionen und Metadaten
  • Service Bindings (OData V2/V4) steuern Endpunkt-Generierung
  • Hoher Automatisierungsgrad, Testbarkeit und Erweiterbarkeit

Quellen:

(C) Brandeis Consulting📁

RAP: Service Binding und Endpunktverwaltung

  • Service Binding verbindet Datenmodelle/Behaviour mit OData-Ressourcen
  • Kontrolle über zugängliche Operationen (Read/Write, Actions)
  • Integration mit Fiori Elements, UI5 und externen APIs

Quellen:

(C) Brandeis Consulting📁

Architekturvergleich: SEGW vs. CDS/BOPF vs. RAP

Ansatz Typ Stärken Grenzen
SEGW/Gateway generisch Flexibel, individuell Aufwändig, viel Coding
OData.publish einfach Schnell, für Reporting Nur lesend
CDS+BOPF BO-zentriert Transaktionen, Workflow Komplex, Standardisiert
RAP BO-zentriert Modern, erweiterbar, nativ Cloud- und OnPrem
(C) Brandeis Consulting📁

Beispiel: RAP OData Service

  • CDS Data Definition mit Behaviour und Annotationen
  • Service Binding im ABAP Environment
  • Fiori-App konsumiert RAP-OData-Service, mit voller CRUD-Unterstützung

Demo im nächsten Kapitel

(C) Brandeis Consulting📁

Best Practices bei OData-Serviceentwicklung in SAP

  • Wahl des Ansatzes nach Anforderung und Systemversion
  • Nutzung von OData.publish in einzelnen Fällen besser für analytische Use-Cases
  • RAP bevorzugt für neue Apps, Cloud-ready und Erweiterungen
  • Backend-Logik und Berechtigungen sorgfältig gestalten
  • Monitoring und LifeCycle-Management beachten
(C) Brandeis Consulting📁

Zusammenfassung

  • SAP bietet heute verschiedene Ansätze zur OData-Serviceerstellung
  • Entwicklung hat sich vom SEGW Gateway zum ABAP RESTful Model gewandelt
  • Moderne Projekte sollten auf RAP setzen, Legacy gibt es z. B. mit SEGW
  • Fiori nutzt OData als universellen Integrationsstandard
(C) Brandeis Consulting📁