Praxisnahe Antworten zu SAP Fiori, SAPUI5, OData Services und SAP BTP, aus der Erfahrung realer Projekte in Großunternehmen.
SAP Fiori ist das Designkonzept und die Sammlung von Standard-Apps, die SAP für eine moderne Benutzererfahrung bereitstellt. SAPUI5 ist das JavaScript-UI-Framework, mit dem diese Apps (und eigene) entwickelt werden. Fiori = Design + Standard-Apps, SAPUI5 = Technologie dahinter. Man kann SAPUI5 auch für völlig eigene Apps nutzen, die nichts mit den Fiori-Standards zu tun haben.
Ja, SAP sieht dafür Extension Points vor. Die gängigsten Methoden:
Wichtig: Immer die offiziellen Extension Points nutzen, nie den Standard-Code direkt ändern. Sonst bricht die App bei SAP-Updates.
Das Fiori Launchpad ist der zentrale Einstiegspunkt für alle SAP Fiori Apps. Es funktioniert wie ein App-Store: Benutzer sehen nur die Apps, für die sie autorisiert sind (gesteuert über PFCG-Rollen, Kataloge und Gruppen). Die Konfiguration umfasst: Target Mappings, Tile-Konfiguration, Rollen-Zuweisung und ggf. Cross-Navigation zwischen Apps.
SAPUI5 ist die richtige Wahl, wenn du im SAP-Ökosystem bleibst: native OData-Bindings, Fiori-Design-Guidelines, direkter Zugang zu SAP-Backend-Services und Support durch SAP. Für reine Web-Apps außerhalb des SAP-Kontexts sind React oder Angular oft besser geeignet. In der Praxis kombiniere ich beides: SAPUI5 für SAP-nahe Prozesse, React für unabhängige Frontends.
OData (Open Data Protocol) ist der Standard für die Kommunikation zwischen SAP-Frontend und -Backend. Ein OData Service definiert Entities (z.B. Accounts, Products) mit CRUD-Operationen (Create, Read, Update, Delete). In SAP wird der Service im SAP Gateway registriert und über ABAP Objects implementiert (Model Provider Class + Data Provider Class). SAPUI5 bindet die Daten direkt an UI-Elemente.
Standard-OData-Services werden über Redefinition der Data Provider Class erweitert. Du erstellst eine Custom-Klasse, die von der Standard-Klasse erbt, und überschreibst gezielt Methoden wie GET_ENTITY, GET_ENTITYSET oder CREATE_ENTITY. Die Registrierung erfolgt über die SAP Gateway Transaktion /IWFND/MAINT_SERVICE. Dabei bleibt der Standard erhalten und wird bei SAP-Updates nicht überschrieben.
ABAP Objects ist die objektorientierte Erweiterung von ABAP. Für OData-Services ist es Pflicht: Die Model Provider Class und Data Provider Class sind ABAP-OO-Klassen mit Vererbung und Methoden-Redefinition. Wer custom OData Services entwickelt, muss ABAP OO beherrschen, insbesondere Klassenvererbung, Interfaces, Exception Handling und das BOL/GENIL-Framework bei SAP CRM.
SAP BTP ist SAPs Cloud-Plattform für Integration, Erweiterung und Entwicklung. Relevante Services:
BTP ist besonders relevant für Integrationsszenarien (z.B. Salesforce ↔ SAP Marketing Cloud) und Extensions außerhalb des SAP-Kerns.
Requirement Engineering mit Fachabteilung → Prototyping (z.B. SAP Build) → OData-Service-Entwicklung (ABAP OO) → SAPUI5 App-Entwicklung → Fiori Launchpad Konfiguration (Rollen, Kataloge) → Testing (Unit + User Testing) → Transport & Go-Live. Pro-Tipp: Früher Prototyp mit realen Daten beschleunigt die Anforderungsabstimmung enorm.
Viele Unternehmen nutzen beides: SAP für ERP/Backend-Prozesse, Salesforce für CRM/Frontend-Prozesse. Die Brücke zwischen beiden Welten erfordert tiefes Verständnis beider Ökosysteme: Datenmodelle, APIs, Sicherheitskonzepte und Prozesslogik. Genau diese Kombination ist mein Alleinstellungsmerkmal: über 10 Jahre Erfahrung in Salesforce und SAP, mit erfolgreichen Integrationen in Enterprise-Projekten.
Fragen zu SAP Fiori, SAPUI5 oder SAP-Salesforce-Integration?
Jetzt Kontakt aufnehmen →