Praxisnahe Antworten zu SAP Fiori, SAPUI5, OData Services und SAP BTP – aus der Erfahrung realer Projekte in Grossunternehmen.
SAP Fiori ist das Designkonzept und die Sammlung von Standard-Apps, die SAP fuer 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 fuer voellig eigene Apps nutzen, die nichts mit den Fiori-Standards zu tun haben.
Ja, SAP sieht dafuer Extension Points vor. Die gaengigsten Methoden:
Wichtig: Immer die offiziellen Extension Points nutzen, nie den Standard-Code direkt aendern – sonst bricht die App bei SAP-Updates.
Das Fiori Launchpad ist der zentrale Einstiegspunkt fuer alle SAP Fiori Apps. Es funktioniert wie ein App-Store: Benutzer sehen nur die Apps, fuer die sie autorisiert sind (gesteuert ueber 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 Sie im SAP-Oekosystem bleiben: native OData-Bindings, Fiori-Design-Guidelines, direkter Zugang zu SAP-Backend-Services und Support durch SAP. Fuer reine Web-Apps ausserhalb des SAP-Kontexts sind React oder Angular oft besser geeignet. In der Praxis kombiniere ich beides – SAPUI5 fuer SAP-nahe Prozesse, React fuer unabhaengige Frontends.
OData (Open Data Protocol) ist der Standard fuer 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 ueber ABAP Objects implementiert (Model Provider Class + Data Provider Class). SAPUI5 bindet die Daten direkt an UI-Elemente.
Standard-OData-Services werden ueber Redefinition der Data Provider Class erweitert. Sie erstellen eine Custom-Klasse, die von der Standard-Klasse erbt, und ueberschreiben gezielt Methoden wie GET_ENTITY, GET_ENTITYSET oder CREATE_ENTITY. Die Registrierung erfolgt ueber die SAP Gateway Transaktion /IWFND/MAINT_SERVICE. Dabei bleibt der Standard erhalten und wird bei SAP-Updates nicht ueberschrieben.
ABAP Objects ist die objektorientierte Erweiterung von ABAP. Fuer 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 fuer Integration, Erweiterung und Entwicklung. Relevante Services:
BTP ist besonders relevant fuer Integrationsszenarien (z.B. Salesforce ↔ SAP Marketing Cloud) und Extensions ausserhalb 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: Frueher Prototyp mit realen Daten beschleunigt die Anforderungsabstimmung enorm.
Viele Unternehmen nutzen beides: SAP fuer ERP/Backend-Prozesse, Salesforce fuer CRM/Frontend-Prozesse. Die Bruecke zwischen beiden Welten erfordert tiefes Verstaendnis beider Oekosysteme – Datenmodelle, APIs, Sicherheitskonzepte und Prozesslogik. Genau diese Kombination ist mein Alleinstellungsmerkmal: ueber 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 →