SAP Fiori Elements in der Praxis: Chancen, Grenzen und Best Practices

Wenn die Geschäftsanforderungen zum Framework passen, bietet Fiori Elements massive Vorteile gegenüber der Freestyle-Entwicklung:

1. Bessere Time-to-Value: Dank der Floorplans und des Guided Development ist es möglich, Fiori-Apps innerhalb weniger Stunden bereitzustellen, deren Entwicklung sonst deutlich länger dauern würde.
2. Garantierte UX-Konsistenz: Die mitgelieferten Inhalte entsprechen den Fiori Design Guidelines, wodurch eine einheitliche User Experience sichergestellt wird. Selbst bei codebasierten Erweiterungen kann immer noch auf „Building Blocks“-Makros zugegriffen werden, die dem SAP-Standard entsprechen.
3. Fiori Elements als Sprungbrett: Fiori Elements senkt die Eintrittshürde beim Umstieg auf Fiori-Apps. Für viele Entwickler, die klassischerweise noch aus der ABAP- oder (Web) Dynpro-basierten Welt kommen, stellt die SAPUI5-Entwicklung einen radikalen Umstieg dar. Fiori Elements führt Entwickler langsam in diese Technologie ein und hilft enorm beim Verständnis des Zusammenspiels vieler Fiori-Komponenten.
4. Überschaubarer Wartungsaufwand: Die Apps bestehen größtenteils aus Framework-Artefakten, die seitens SAP gewartet und weiterentwickelt werden statt aus eigenem Code. So entfällt weitestgehend das Risiko, dass bei neuen UI5-Versionen ein zusätzlicher Wartungsaufwand für bestehende Apps entsteht.

Trotz der mächtigen, umfassenden Modellierungsmöglichkeiten stößt auch Fiori Elements an seine Grenzen. Die folgenden Punkte sollten beim Einsatz von Fiori Elements unbedingt bedacht werden:

1. OData-Zwang: Apps, die mit Fiori Elements angelegt werden, müssen zwingend auf einen OData-Service als Datenquelle zurückgreifen. In der Freestyle-Entwicklung existiert diese Beschränkung nicht, so dass dort auch REST-APIs, die vom OData-Standard abweichen und gänzlich andere Schnittstellen, wie beispielsweise GraphQL-basierte Quellen, die eine moderne Alternative zu REST-APIs darstellen, angebunden werden können.
2. Ein Service pro App: Darüber hinaus erlaubt Fiori Elements grundsätzlich nur einen OData-Service pro App. Über Umwege ist es zwar möglich, mehrere OData-Services in Custom Pages und Extension Points anzubinden, in dem für Fiori Elements typischen Workflow via Guided Development tauchen diese OData-Services allerdings auch dann nicht auf.
3. Abkehr vom Standard: Fiori Elements ist für Standard-Geschäftsprozesse und operative Analysen ausgelegt. Bei hochkomplexen und hochdynamischen Anwendungen stoßen die Modellierungsmöglichkeiten sowie das vorgefertigte Routing an ihre Grenzen. In diesen Szenarien ist die Freestyle-Entwicklung klar überlegen.
4. Blackbox-Debugging: Der Großteil des App-Codes wird zur Laufzeit aus den Framework-Artefakten und Annotationen generiert, was die Fehlersuche gegenüber der Freestyle-Entwicklung erschwert. Insbesondere wenn man sich aufgrund mangelnder UI5-Kenntnisse für die geführte Entwicklung mittels Fiori Elements entschieden hat, kann das frustrierend sein.

Fiori Elements hat klare Stärken, stößt je nach Szenario aber an seine Grenzen. Bei der Entscheidung, ob Fiori Elements im eigenen Unternehmen zur Entwicklung von Fiori-Apps eingesetzt werden soll, müssen diese Vor- und Nachteile dringend abgewogen werden. Unabhängig davon hängt der Projekterfolg zusätzlich davon ab, Fallstricke zu vermeiden und die verfügbaren Tools so effektiv wie möglich einzusetzen. Hier sind zusätzliche Best Practices, die eine erfolgreiche App-Entwicklung mit Fiori Elements fördern:

• Frühzeitiger Anforderungs-Check: 

  Wie in allen Projekten, ist auch bei der Entwicklung von Fiori-Apps das Anforderungsmanagement nicht zu vernachlässigen. Erst wenn die Anforderungen bekannt sind, kann eingeschätzt werden, ob die Entwicklung mittels Fiori Elements zielführend oder ob der Modellierungsumfang von Fiori Elements für den konkreten Anwendungsfall zu einschränkend ist.

• Wenn möglich, ausschließlich auf OData V4 Services zugreifen: 

  Auch wenn die älteren V2-Services noch unterstützt werden, sollte immer ein V4-Service genutzt werden, da nur so der Zugriff auf die Vorteile des Flexible Programming Model gegeben ist. Komplexere Erweiterungen unter V2-Services sind um ein Vielfaches aufwendiger zu implementieren.

• „Backend-First“ bei Annotationen: 

  Um Wiederverwendbarkeit und Übersichtlichkeit sicherzustellen, sollten Annotationen immer so tief wie möglich, also in den CDS-Views der OData-Services, angelegt werden. Viele Annotationen können zwar auch im Frontend angelegt werden und die Backend-Annotationen übersteuern, dennoch sollte man im Frontend nur für app-spezifische Einstellungen davon Gebrauch machen.