SAP Fiori UX | SAPUI5 vs ReactJS oder AngularJS mit KendoUI

(Last Updated On: 10. Dezember 2018)

SAP S/4HANA soll der neue digitale Kern des Unternehmens werden. Während in der Suite zentrale Geschäftsdaten verwaltet werden, ist der digitale Kern über Schnittstellen an die Außenwelt angebunden. Dadurch kann die Datenhaltung in einen externen Data Lake und die Abwicklung von kundeneigenen Geschäftslogiken beispielsweise in die SAP Cloud Plattform ausgelagert werden. Über den Konsum von Cloud Diensten ist man mit Kunden und Lieferanten verbunden und bezieht aktuelle Wirtschaftsdaten. Kurzum: Es macht Sinn, SAP S/4HANA als zentralen Einstiegspunkt für die Geschäftsprozesse und Daten eines Unternehmens anzusehen. S/4HANA ist in dieser Rolle eine Single Source of Truth. Ich kann über die Suite einsteigen und habe durch sie einen zentralen Ansprechpartner für alle Schichten meines Unternehmens.

Da macht es natürlich Sinn, dass man diesen zentralen Ansprechpartner auch möglichst einfach konsumieren kann. Das ist in der Geschäftswelt nichts neues. Wenn ich Daten brauche, will ich sie mir komfortabel auf unterschiedliche Art und Weise holen können. Zu diesem Zweck hat der Hersteller die neue SAP User Experience (SAP UX) definiert. Im Endeffekt handelt es sich dabei um einige Guidelines zur Gestaltung von Frontendelementen unter Einsatz von Webtechnologien. Die User Experience kann dabei jedoch auf unterschiedliche Art und Weise hergestellt werden.

Die offensichtlichste Variante ist die Erstellung einer Fiori App unter Verwendung von SAPUI5. Dabei bedienen Sie sich explizit den über 200 vordefinierten UI Controls aus dem SAPUI5 Framework. Da diese vom Hersteller SAP vordesignt sind, ist die Compliance zu den Design Guidelines der SAP User Experience entsprechend einfach. Der Nachteil dabei: Sie haben in der Regel auch entsprechend wenig Eingriffsmöglichkeit in diesen Standard. Grundsätzlich können Sie zwar unter SAPUI5 eigene Custom UI Controls entwickeln, dies ist jedoch im Vergleich zu den Templating Funktionalitäten von beispielsweise AngularJS alles andere als komfortabel.

Worum soll es jetzt in diesem Beitrag genau gehen? Wir durchleuchten zusammen, wann man in seinem Webtechnologieprojekt im SAP-Umfeld auf das klassische SAPUI5 setzen sollte und wann man ein mächtigeres Frontend SDK wie Angular verwendet. Die Begründungen hierzu leite ich über eine Zurschaustellung der einzelnen Vor- und Nachteile ab. Als Inhaber eines Webmasters Europe Diploma in Web-Engineering aus dem Jahre 2014 komme ich ursprünglich aus der von SAP losgelösten Webentwicklung.

Der SAPUI5 Bär im SAP Umfeld

Hierbei habe ich  damals mit Laravel mein erstes eigenes CMS mit den typischen Komponenten (User- und Berechtigungsverwaltung, Texteditor, Mediendatenbank, Social Media Integration) aufgebaut. Später, als ich in die SAP Beratung gewechselt bin, habe ich mir mit der SAP HANA Express Edition die einzelnen Möglichkeiten für einen Bring Your Own Language Ansatz zum Entwickeln von Webapplikationen auf Basis von SAP HANA angesehen. Das ganze ist im Endeffekt ganz einfach, weil die SAP alle nötigen Infos dazu bietet.

Ein Kunde hat nach einem Entwickler gefragt, der eine strategische Entscheidungshilfe zur Frage klassische Frontend SDKs gegenüber SAPUI5 bieten kann. Der Kunde wollte ein komplexes Shopsystem zum Verkauf von digitalen Dienstleistungen bauen, dessen Preise sich dynamisch auf Basis von Echtzeitanalysen berechnet werden. Viele der Daten kommen aus der SAP-Welt. Bei Workshops diverser SAP Beratungshäuser wurde dem Kunden immer wieder der SAPUI5 Bär aufgebunden, obwohl der Kunde traditionell klassische Webentwickler im Hause und dort sein größtes Know How hat. Dabei fiel auf, dass die Partner außerhalb von SAPUI5 häufig nicht auf Ebene des Kunden kommunizieren konnten, da Sie kein Know How in der klassischen Webentwicklung mitbringen. Das Drängen der Partner auf SAPUI5 wirkte „aus der Not heraus verargumentiert“, dementsprechend gering war auch das Vertrauen in die Technologie.

Dem Kunden wurde auch erzählt, dass er SAPUI5 einsetzen muss, wenn er seinen Code in der SAP Cloud Plattform ausführen möchte, weil man dort nur SAPUI5 Projekte erstellen könnte. Dem ist nicht so. Sogar von der SAP selbst kommt ein Tutorial zum Erstellen eines Angular Bootstraps in der WebIDE. Dabei erstellt man zunächst über das Menü ein neues SAPUI5 Projekt, löscht im Anschlus sämtliche Files, und befüllt seinen Projektordner wie in einem klassischen Angular Projekt.

Dabei bin ich persönlich zum Schluss gekommen, dass sich für große monolithische Webprojekte mächtige Frontend-Frameworks wie Angular2 besser eignen als das klassische SAPUI5. Warum das so ist, werde ich in den folgenden Kapiteln erläutern. Übrigens: Auch klassische Backend Sprachen wie PHP und Python und dort verbreitete Frameworks wie Laravel und Django haben unter SAP HANA ihre Daseinsberechtigung.  In Zukunft wird es für die verschiedenen Approaches auch Beiträge geben. Mit diesem Beitrag möchte ich insbesondere verhindern, dass sich Kunden beim Versuch, ein komplexes Firmenportal mit SAPUI5 aufzubauen, verrennen. Aber auch wo SAPUI5 seine Glanzmomente hat, will ich Ihnen nicht verschweigen.

Was spricht für Angular und React

Es gibt einige Argumente, die dafür sprechen, anstelle von SAPUI5 lieber die monolithischen Frameworks Angular2 und ReactJS zu verwenden. Ich werde Ihnen im Folgenden erläutern, warum ich diese Meinung vertrete und versuche immer konkrete Beispiele anzubringen. Keine Sorge, auch die Vorteile von SAPUI5 werden wir ansprechen. Diese bekommen einen extra Abschnitt, bevor wir am Ende zu einer Schlussfolgerung kommen.

Templating

Unter SAPUI5 generieren Sie UI Controls über programmeigene Methoden, was beispielsweise wie folgt aussieht. In folgendem Coding erzeugen wir ein div, fügen diesem eine CSS-Klasse hinzu und fügen innerhalb dieses divs einige vordefinierte Controls ein.

renderer : function (oRM, oControl) {
	oRM.write("<div");
	oRM.writeControlData(oControl);
	oRM.addClass("beitragsbewertung");
	oRM.writeClasses();
	oRM.write(">");
	oRM.renderControl(oControl.getAggregation("_rating"));
	oRM.renderControl(oControl.getAggregation("_label"));
	oRM.renderControl(oControl.getAggregation("_button"));
	oRM.write("</div>");
}

Wie Sie sehen, ist diese Form der UI-Erstellung nicht nur umständlich, sondern auch schlecht lesbar. Im Vergleich dazu ist ein Template unter Angular2 im Wesentlichen der pure HTML-Code mit einigen zusätzlichen Controls für das Einfügen von JavaScript-Actions. ReactJS ist hier wieder eine andere Geschichte, denn React nutzt für das Templating den XML-Jargon XSL. Sie können sich jedoch sehr einfach vorstellen, dass ein puristisches Template unter Angular2

  • schneller aufgebaut wird, da der Browser den direkten Code ohne Objektzugriff einliest
  • leichter lesbar und erweiterbar ist
  • einfacher innerhalb des Templates selbst auf Subtemplates durchgegriffen werden kann – so können Sie etwa innerhalb des divs ein weiteres Subtemplate aufrufen.
  • innerhalb des Templates sehr leicht Datenbankwerte einfügen können. So können Sie in einem Angular2 Template jederzeit eine beliebige von Ihnen erstellte Datenmanagementmethode aufrufen
  • in der Regel zu einer besseren Suchmaschinenoptimierung führt, weil individuelle Attribute (etwa rel nofollow Attribute) für die einzelnen zu rendernden Controls individueller definiert werden können

Verstehen Sie mich nicht falsch. SAPUI5 ist, genau wie Angular auch, lediglich ein Framework. Sie können jederzeit mit JavaScript Ihre eigenen Methoden definieren und diese verwenden. Natürlich sollte aber der Sinn des Frameworks sein, von Hause aus Best Practices anzubieten und eben dem Entwickler den Aufbau einer Templating Engine ersparen. Die besten Frameworks bieten einen optimierten Weg, etwas zu tun, ohne den Entwickler in seinen Freiheiten einzuschränken.

Isomorphie und Performance

Unter Isomorphie versteht man die Aufteilung des JavaScript-Codes in eine server- und eine client-seitige Ausführungsschicht. Allein schon aus Sicherheitsgründen müssen bestimmte Teile des Codings auf Serverebene ablaufen. Denn auf Clientseite hat der Browser und somit der Besucher Eingriffsmöglichkeit in das Coding – und kann somit die Geschäftslogik zu seinen Gunsten beeinflussen. Server seitiges Rendering hat des Weiteren Vorteile in der Performance und in der Suchmaschinenoptimierung. Zum einen müssen die auf den Server ausgelagerten Coding Teile nicht erst vom Client heruntergeladen werden. Zum Anderen kann der Server beispielsweise Caching Engines verwenden, um einen Objekt-Cache wie Redis oder einen Key-Value-Cache wie beispielsweise memcached aufzubauen.

Auf der anderen Seite müssen zwangsläufig einige Teile des JavaScript-Codings auf Clientseite erledigt werden. Dies sind in der Regel all jene Bestandteile, welche den DOM im Browser des Anwenders beeinflussen wollen, also in der Regel mit dem Design, der Animation, Usability und der allgemeinen Bedienung zu tun haben. Diese Bestandteile können selbstverständlich nur auf Clientseite beeinflusst werden.

Während beispielsweise unter Angular in Verbindungs mit Node.js die Aufteilung des Codings feingranular erfolgen kann, ist diese Aufteilung unter SAPUI5 vorgegeben. Große Teile des Codings laufen auf Clientseite. Die ist aber aus Sicherheitsgründen kein Problem, weil der Zugriff aufs Backend in der klassischen SAPUI5-Architektur aufgetrennt ist. Nicht umsonst gibt es bei einer Fiori App in der Regel eine Backend- und eine davon abgetrennte Frontend-Komponente. Aber die Entwicklung ist in ihrer Freiheit stark eingeschränkt. Es ist äußerst umständlich und teilweise auch unmöglich, gezielt einzelne Verarbeitungsschritte von der Clientseite auf die Serverseite zu holen. Dementsprechend schwer wird auch die Nutzung von Caching Engines. Dies macht sich aus meiner Erfahrung auch spürbar im Performance-Vergleich zwischen einer Angular- und einer SAPUI5-App bemerkbar.

Code Splitting und Hot Page Reloading

Auch beim Bundling macht sich dies bemerkbar. Unter Bundling versteht man die Zusammenführung von Coding in verschiedenen Dateien zu einem einzelnen File. Der Browser des Benutzers muss nur noch lediglich eine .js-Datei herunterladen anstatt mehrerer. Dadurch reduziert sich die Anzahl der HTTP Requests. Beispiel anhand eines konkreten Codings

// app.js
import { add } from './math.js';

console.log(add(16, 26)); // 42
// math.js
export function add(a, b) {
return a + b;
}

Das aus diesen beiden Dateien zusammengefügte Coding würde wie folgt aussehen.

function add(a, b) {
return a + b;
}

console.log(add(16, 26)); // 42

Sowohl Angular als auch React nutzen intelligente Code Splitting Engines wie Webpack oder Browserify. Diese bieten in der Regel eine State of the Art Experience. Dazu gehört beispielsweise die Möglichkeit zum Hot Page Reloading. Während beim Live Reloading beim Abändern einer .js-Datei die ganze Seite neu geladen werden muss und der Status der App mit den aktuell gespeicherten Variablen verloren geht, wird beim Hot Page Reloading nur der Code der geänderten Files neu reingeladen und der Status der App geht nicht verloren. Dies erlaubt auch in der Produktion durchdachte Live Deployments von neuem Coding und ist ein wichtiger Bestandteil moderner DevOps Strategien. Diese Technologie wird deshalb nicht umsonst von vielen großen Technologie-Unternehmen verwendet. Unter SAPUI5 schauen Sie hier ins Leere. Sie verändern etwas in Ihrem Projekt? Die ganze App bitte einmal neu laden.

Meiner Erfahrung nach bietet SAPUI5 an dieser Stelle bei weitem nicht die selben Möglichkeiten. Dies stellt aus meiner Sicht ein wichtiges Argument dar, warum Sie große monolithische Webanwendungen nicht mit SAPUI5 realisieren sollten.

Transpiler Support und ES6

Wie Sie vielleicht wissen, wird standardisiertes JavaScript als ECMAScript bezeichnet. 2015 und 2016 gab es hier die letzte große Veränderung mit der Einführung von ECMAScript 6 (ES6) und ECMAScript 7 (ES7). ECMAScript ist ein Standard, JavasScript ist ein Dialekt basierend auf diesem Standard. Von JavaScript selbst gibt es wiederum weitere Dialekte, beispielsweise CoffeeScript oder TypeScript. Mit der Einführung von ES6 haben diese Dialekte jedoch an Bedeutung verloren. Zum Vergleich zwischen ES6- und ES5-konformem JavaScript ein Beispiel, welches den Aufbau einer Klasse erläutert.

// ES6
class Shape {
constructor() {}
draw() {}
}
class Circle extends Shape {
draw() {
super.draw();
...
}
}
// ES5
var Shape = function() {...};
Shape.prototype.draw = function() {...};
...

Sie sehen also, ES6 führt beispielsweise das sogenannte class Keyword ein und ermöglicht somit einen State of the Art Klassenaufbau im Vergleich zum älteren ES5-Standard. Wenn Ihr Business Erfahrungen bzw. Bedarfe hat, ES6-konformen Code zu schreiben, müssen Sie sich unter SAPUI5 erstmal ins Zeug legen. SAPUI5 nutzt die ES6 Best Practices bis heute nicht zur Genüge. Teilweise muss SAPUI5 mit Hilfe externer Bibliotheken erst „enabled“ werden. Ein Kommentar von einem Github User zu diesem Thema:

Hey guys, I really think support for modern build frameworks should be built right into the OpenUI5 framework. As it is, it looks quite „old-fashioned“ to an experienced JS developer. You would push adoption in the broader community much further if you adopted the latest toolsets more quickly. Just a suggestion. – derwaldgeist, Github

Unter react und Angular2 können Sie Ihren Code sowohl ES6-konform als auch in anderen Javascript-Dialekten wie beispielsweise CoffeeScript oder TypeScript verfassen. Der integrierte Transpiler kümmert sich um die Übersetzung des Codes in Plain JavaScript und abstrahiert daher diese Ebene vom Entwickler. Klarer Punkt für react und Angular.

Native Mobile Entwicklung

Unter Native Mobile Entwicklung versteht man die Entwicklung einer klassischen Smartdevice App, die auf einem der großen Smart Device Betriebssysteme wie Android oder iOS läuft. Eine native Mobile App ist hierbei in der Regel in einer höheren Programmiersprache wie Objective-C, Java oder im Falle von iOS in Swift geschrieben. Wie einfach ist es für einen Entwickler unter SAPUI5, reactJS und Angular2, auch eine solche Native Mobile App zu entwickeln? Wir reden hier nicht über eine sogenannte Hybrid App, in welcher die eigentliche Webanwendung innerhalb einer minimalistischen Wrapper App geladen wird. Aufgrund der besseren User Experience und der höheren Mächtigkeit einer Native App – insbesondere im Zugriff auf Hardware-Funktionalitäten – haben viele Projekte die Anforderungen nach einer Native Mobile App.

Grundsätzlich muss man sagen: In allen drei Sprachen ist es möglich, die gleiche User Experience wie in der Webanwendung auch in eine Native Mobile App zu gießen. Die SAP liefert hierzu das SAP iOS SDK  sowie eine Referenz-App aus. Der Aufbau geht relativ leicht von der Hand, jedoch gelten bei diesem SDK beinahe die selben Einschränkungen wie beim eigentlichen SAPUI5. Und damit wären wir wieder beim Problem.

Unter reactJS können Sie mit React Native auf Ihrer bestehenden Webanwendung aufbauen und somit beinahe der selben Mächtigkeit und Flexibilität eine Native Mobile App erzeugen. Unter Angular2 können Sie neben React Native auch Ionic oder NativeScript verwenden. Sie haben also den Vorteil einer Hybrid App in dem Sinne, dass Sie sehr einfach auf Ihrer bestehenden Webanwendung aufbauen können. Gleichzeitig hat Ihre App aber die volle Mächtigkeit einer Native Mobile App.

Was spricht für SAPUI5

Nun gibt es aber auch Argumente für SAPUI5. Die Technologie ist nicht umsonst genau für eine einheitliche Web User Experience im SAP-Umfeld geschaffen worden. Es gibt einige Argumente für SAPUI5, die ich an dieser Stelle natürlich nicht verschweigen möchte.

Security

Eins steht einmal fest: Sowohl unter SAPUI5 als auch unter react und Angular fahren Sie aus Security Sicht immer besser, als wenn Sie komplett von der Pike auf selber in puristischem JavaScript programmieren. Alle drei Frameworks bringen bereits eine ins Framework eingebaute Verteidigungslinie gegen Cross Site Scripting (XSS) Angriffe mit. Diese Schicht müssten Sie ansonsten selbst implementieren und pflegen.

SAPUI5 bietet an dieser Stelle etwas mehr als die Konkurrenz. Zum einen bringt das Framework eine integrierte Schutzkomponente gegen Clickjacking mit. Clickjacking ist eine beinahe schon lächerlich einfache Angriffsform, bei welcher der Benutzer denkt, auf eine Schaltfläche auf der Seite zu klicken, in Wahrheit aber auf ein iframe-Element einer fremden Seite (z. B. Paypal) klickt. SAPUI5 bietet eine integrierte Möglichkeit, Trusted Domains zu pflegen, um eingebettete Seiten zu filtern. Diese Filterfunktion muss in den anderen Frameworks erst manuell im Code oder auf Webserverebene implementiert werden.

Des Weiteren bietet SAPUI5 ein integriertes URL Whitelisting für Eingabeelemente. Alle Eingabeelemente unterhalb von sap.ui.richttexteditor.RichTextEditor und the sap.ui.core.HTML sind demnach dazu in der Lage, die Eingabe von nicht erlaubten URLs zu verhindern. Das eignet sich beispielsweise um zu verhindern, dass Anwender einer SAPUI5 Anwendung Links zu schadhaften Domains setzen oder Eigenwerbung betreiben. In den anderen Frameworks muss eine solche Funktionalität erst implementiert werden.

SAPUI5 bietet außerdem über das SAP NetWeaver Gateway einen integrierten Schutzmechanismus gegenüber Cross Site Request Forgery (CSRF) Attacken. Auf der anderen Seite bietet Angular2 bereits ebenfalls einen integrierten Support gegenüber XSSI und CSRF-Angriffe. Die HTTPClient Bibliothek von Angular entfernt sämtliche )]}‘,\n Zeichen aus Antworten beim Aufruf einer externen HTTP Schnittstelle und sendet zufällig generierte Authentication Cookies an den Client.

Theming

Im Gegensatz zu react und Angular bietet SAPUI5 eine integrierte Theming-Option. Theming ist nicht zu verwechseln mit Templating. Beim Theming geht es darum, einem geladenen Template abhängig vom ausgewählten „Thema“ ein anderes aussehen zu verleihen, beispielsweise die Farben oder Logos zu wechseln – oder der UI einen weihnachtlichen Look zu verleihen. Unter SAPUI5 können die einzelnen UI Controls je nach ausgewähltem Theme anders gerendert werden. Das Theme wird dabei über den UI Theme Designer bearbeitet und entworfen. In den anderen Frameworks sind Sie über den Einbau einer Theming-Bibliothek oder das Implementieren eigner Methoden selbst in der Pflicht, dem User eine Theming Option anzubieten.

SAP Fiori Design Guidelines

Das aller stärkste Argument für die Nutzung von SAPUI5 ist die simple Tatsache, dass jede der vordefinierten UI Controls die Anforderungen der SAP Fiori Design Guidelines erfüllt. Das betrifft nicht nur das Aussehen, sondern auch das Verhalten und die Interaktionsfähigkeit der Controls. Allein aus dieser Tatsache heraus empfiehlt es sich schon, bei allen Applikationen, die innerhalb von SAP bzw. mit dem Fiori Launchpad verwendet werden sollen, SAPUI5 zu verwenden. Nur so gewährleisten Sie ein einheitliches Look & Feel beim Arbeiten im SAP Frontend.

Umso umständlicher wird es hingegen jedoch, wenn Sie unter SAPUI5 ein von den Fiori Design Guidelines abweichendes Design herstellen wollen. Hierbei müssen Sie entweder die bestehenden UI Controls kopieren und abändern oder direkt in den Cascading Style Sheet eingreifen. Da geht das Design von eigenen UI Controls mit React und Angular natürlich schon wesentlich einfacher.

Vordefinierte UI Controls

In diesem Zuge muss ich natürlich auch erwähnen, dass SAPUI5 mehr als 200 vordefinierte UI Controls mitbringt, die sich out of the box in der eigenen App verwenden lassen. Diese Vielzahl an UI Controls manuell von einem Frontend Design Team entwickeln zu lassen, kostet natürlich einiges an Mannstunden. Unter der SAP Fiori Elements Bibliothek können Sie sich die Vielzahl der verfügbaren Conrols ansehen. Besonders beeindruckend finde ich die 3D Viewports sowie die Visualisierungswerkzeuge im Analytics Bereich. Hier scheint SAP Fiori und bringt seine Stärken so richtig zum Vorschein.

Dieser enorme Vorteil von SAPUI5 lässt sich ein wenig abschwächen in dem Sinne, dass natürlich auch unter Angular und React externe JavaScript Bibliotheken mit vorgefertigten UI Controls importiert werden können. Eine Bibliothek, deren UI Controls ein sehr ähnliches Aussehen wie die SAP Fiori Elements aufweisen, ist die Kendo UI. Der Link liefert Ihnen eine Liste aller UI Controls unter Kendo, die Sie sich bei Gelegenheit zu Gemüte führen und mit den SAP Fiori Elements vergleichen können. Obwohl Kendo UI ursprünglich als eigenständiges SDK gedacht war, lässt es sich mittlerweile auch zum Großteil in Angular einhaken und verwenden. Neben Kendo UI gibt es natürlich noch andere Bibliotheken, die sich in Angular integrieren lassen und vordefinierte UI Controls mitliefern.

Personalisierung von Apps

Ein großer Vorteil von SAPUI5 ist die bereits integrierte Möglichkeit zur Personalisierung von Apps. Benutzer können Datenfelder von Apps ausblenden oder in anderen Gruppen einordnen und gruppieren. Hier ist der Link zur SAP Fiori UI adaption at Runtime in der SAP Library. Das Video zeigt die Prozedur im Detail.

Eine solche Funktionalität vorimplementiert zu haben, ist natürlich sehr durchdacht und würde bei Eigenentwicklung einige Mannstunden verschlingen. Unter SAPUI5 bekommt man die Funktionalität out of the box. Das ist ein großer Pluspunkt für SAPUI5, wenn es um die wiederkehrende, bestenfalls tägliche Nutzung von kleinen Appliaktionen geht.

Fazit

Kommen wir nun zum Schluss. Wann sollten Sie nun SAPUI5 verwenden, und wann ein dediziertes Javascript SDK wie Angular? In aller letzter Instanz entscheiden das natürlich Sie als Kunde. Es kommt schließlich auch darauf an, wo Ihre Stärken liegen und wo Sie Know How im Hause haben. Grundsätzlich können Sie jedes Projekt mit beiden Technologien realisieren. Der Aufwand unterscheidet sich nur. Es gibt aus meiner Sicht einige Indikatoren dafür, wann Sie SAPUI5 verwenden sollten und wann nicht. Die Grafik zeigt meine Schlussfolgerung in einer Übersicht.

Vergleich SAPUI5 vs Angular2 vs React NodeJS

Das ganze jetzt noch einmal textlich aufbereitet in Tabellenform

ThemaSAPUI5Angular
AnwendungskomplexitätWählen Sie SAPUI5, wenn Sie eine kleine Applikation bauen wollen, die einen einzigen vordefinierten Zweck erfüllt. Beispiel wäre etwa eine Analytical App, die einen bereits bestehenden Datenpool in einem Graphen visualisieren und dabei eine Filterfunktion anbieten soll.Wählen Sie Angular, wenn Sie wie mein Kunde eine monolithische Webanwendung aus mehreren Komponenten aufbauen wollen und hohe Ansprüche an die Schnittstellen haben.
CodingWählen Sie SAPUI5, wenn Sie geringe Anforderungen an die ECMAScript Konformität Ihres Codings haben.Wählen Sie Angular, wenn Sie ES6- bzw. ES7-konformes JavaScript schreiben und Ihren Code möglichst sauber und refakturierbar halten wollen. Verwenden Sie Angular, wenn Sie bisher mit einem alternativen JavaScript Dialekt wie CoffeeScript gearbeitet haben und daher auf eine Transpiler Funktionalität angewiesen sind.
Polyglot PersistenceWählen Sie SAPUI5, wenn Sie lediglich SAP HANA als Datenquelle benötigen.Wählen Sie Angular, wenn Sie eine heterogene Persistenzschicht planen und Ihre Daten in unterschiedlichen Quellen persistieren und abrufen möchten.
Ort der Ausführung und PerformanceWählen Sie SAPUI5, wenn die Anwendung Bestandteil des Fiori Launchpad sein sollte.Wählen Sie Angular, wenn Sie hohe Anforderungen an eine geringe Ladezeit des DOM Baumes und an eine Reduzierung der HTTP Requests haben.
TemplatingWählen Sie SAPUI5, wenn Sie weitestgehend auf die Erstellung von eigenem HTML/CSS Markup verzichten wollen.Wählen Sie Angular, wenn Sie  eigene HTML/CSS Templates und den vollen Umfang von HTML5 / CSS3 nutzen wollen.

Wählen Sie Angular, wenn Sie wiederkehrende Frontend-Abschnitte über Subtemplates einlesen wollen.

DevOpsWählen Sie SAPUI5, wenn Sie keine hohen Anforderungen an das Live-Deployment von Änderungen haben.Wählen Sie Angular, wenn Sie Hot Page Reloading nutzen wollen und einen kurzen Deployment Zyklus haben.
Mobile DevelopmentWählen Sie SAPUI5, wenn Sie die Entwicklung einer Smart Devices App weitestgehend auslagern möchten. In diesem Fall können Sie den SAP Fiori Client von SAP verwenden.Wählen Sie Angular, wenn Mobile ein wichtiger Teil Ihrer Strategie ist und Ihre Anforderungen an eine Native Mobile App hoch sind.
ThemingWählen Sie SAPUI5, wenn Sie auf einfache Art und Weise mehrere Themen für Ihr Frontend anbieten wollenWählen Sie Angular, wenn Sie keine hohen Ansprüche an eine Theming Option haben.
SecurityWählen Sie SAPUI5, wenn Sie Ihren Aufwand für Security Tests und Code Reviews weitestgehend reduzieren wollen.Wählen Sie Angular, wenn Sie eine hohe Security Fachexpertise im Haus haben und die Coding Awareness für Sicherheitslücken in Ihrem Hause hoch ist.
UI ControlsWählen Sie SAPUI5, wenn Sie kaum Frontend Designer Expertise im Haus haben oder die Gestaltung von Frontend Elementen einen Großteil des Projekt Workloads ausmacht.Wählen Sie Angular, wenn Sie gute Frontend Expertise im Haus haben und lieber volle Flexibilität und Mächtigkeit bei der Gestaltung Ihrer UI Controls haben möchten.
Design GuidelinesWählen Sie SAPUI5, wenn Ihre Webanwendung in das Look & Feel des Fiori Launchpads passen soll und im SAP Umfeld eingesetzt wird.Wählen Sie Angular, wenn Ihre Anwnedung ein möglichst individuelles Aussehen passend zu Ihrer Corporate Identity haben soll und Sie größtenteils eigene Frontend Designs einsetzen wollen.
ErweiterbarkeitWählen Sie SAPUI5, wenn Sie die Anwendung möglichst wenig anfassen wollen, um eine bestimmte Logik zum Endtermin zu erzielen.Wählen Sie Angular, wenn Sie die Anwendung über einen langen Zeithorizont immer weiter ausbauen und wissen wollen, wo Sie anfassen müssen, um dies zu erreichen.

Wählen Sie Angular, wenn Sie sich in „Ihrem Code“ auskennen wollen.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

2 Antworten

  1. SAP Freund sagt:

    Besten Dank für die vielen Informationen. Haben Sie vielleicht ein paar nützliche Quellen, mit denen man Anwendungen rund um SAP oder Mobility SAP kennenlernen kann? Als ältere Person in so einem Arbeitsumfeld möchte ich mich gerne passend vorberieten, da ich sowas nicht mehr on-the-fly lernen kann. Würde mich sehr freuen. Vielen Dank im Voraus!

    • DaFRK sagt:

      eine gute Quelle ist definitiv developers.sap.com. Dort gibt es mittlerweile über 800 Tutorials in diesem Umfeld, nicht nur für SAPUI5, sondern auch für andere Frameworks.

      Wenn Sie auf der Suche nach einer relativ „günstigen“ Möglichkeit sind, SAP Zertifizierungen in dem Bereich zu erwerben, kann ich Ihnen exitcertified empfehlen. Das ist eine amerikanische Plattform, die SAP-Weiterbildungen online im virtuellen Klassenzimmer anbietet.

      Wenn es darum geht, Frameworks wie Angular besser kennen zu lernen, kann ich youtube tutorials bzw. Bücher nahe legen. Angular bietet zwar kostenlose Tutorials auf der Seite, aber ein Tutorial bzw. Buch macht den Einstieg aus meiner Sicht noch einmal etwas leichter. Ich persönlich würde an Ihrer Stelle beides miteinander kombinieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.