HTML5 vs. SAPUI5

Il a fallu attendre longtemps avant que SAP ne mette lui aussi en place des technologies UI modernes. Ce qui est difficile, c'est surtout l'adaptabilité aux exigences individuelles et l'utilisation peu intuitive.

Dans le cadre d'une phase d'évaluation des technologies HTML5 UI, l'idée d'écrire un article sur les technologies d'interface utilisateur est née. En particulier sur celles qui sont typiquement utilisées dans l'environnement SAP.

Le framework WebDynpro a désormais fait ses preuves et offre également des possibilités intéressantes pour les développements personnels. Il est ainsi possible d'utiliser des modèles prédéfinis pour les interfaces utilisateur et un environnement de développement confortable avec un éditeur WYSIWYG.

Comme pour tous les frameworks fermés, c'est SAP, en tant que fabricant, qui fournit le cadre et fixe donc strictement les limites. Ainsi, tout le contrôle de la communication avec le système de gestion est défini sur le serveur.

Il n'y a pas de possibilité de codage individuel côté client, comme cela serait par exemple nécessaire pour l'intégration de certains contenus multimédias (par ex. vidéo).

D'un autre côté, ces limites offrent également des avantages, notamment en ce qui concerne la planification des versions, le support, la sécurité des données et la stabilité. En raison des limites décrites ci-dessus, SAP explore de nouvelles voies et met à disposition un framework UI encore relativement nouveau : SAPUI5 !

Jusqu'à présent, SAPUI5 est surtout connu pour les applications Fiori, mais il s'agit d'un concept plus ouvert avec plus de possibilités d'intervention par rapport au WebDynpro.

SAPUI5

SAPUI5 est également un framework et offre un ensemble d'éléments de conception et de contrôle basés sur HTML5. En outre, SAP met à disposition avec SAPUI5 un concept de Data Binding, déjà connu sous une forme similaire dans WebDynpro.

L'échange de données entre l'interface et les systèmes backend (SAPUI5 permet également de connecter des systèmes non SAP) est ainsi garanti. Pour ce faire, la structure SAPUI5 propose une forme de contrôleur de vue de modèle (MVC) qui règle la manière dont les données passent de l'interface à la logique de gestion ou de la logique de gestion à l'interface.

Grâce à ce principe, il est possible de produire rapidement et facilement des interfaces pour réaliser les premiers projets et donner une impression de la solution. Le framework ne se compose pas uniquement de bibliothèques propres à SAP, mais utilise également d'autres bibliothèques open source comme jQuery, Bootstrap, Cordova/Phonegap.

Actuellement, il existe deux versions (également appelées variantes combinées) : l'une pour les applications mobiles et l'autre pour le domaine des ordinateurs de bureau.

Une différence entre les deux variantes réside dans le fait que la variante mobile comprend une bibliothèque plus petite et optimisée pour les applications mobiles, pour des raisons de performance.

Grâce aux terminaux mobiles puissants, à la couverture réseau de plus en plus performante et aux débits de données mobiles plus élevés, la différence entre ces variations devient négligeable. Seule l'adaptation aux différentes tailles d'écran à l'aide du Responsive Design est vraiment pertinente.

Cadres

Comme nous l'avons dit, SAPUI5 est un framework. C'est pourquoi nous souhaitons aborder brièvement les avantages et les inconvénients de tels frameworks afin de les situer.

Lors d'un développement en interne, on est toujours confronté à la question de savoir si l'on utilise des frameworks déjà existants ou si l'on développe tout soi-même. En tant que développeur, on entend souvent dire

"Utilise plutôt un framework existant et ne réinvente pas toujours la roue".

De notre point de vue, deux indicateurs peuvent nous renseigner sur l'utilisation d'un framework : premièrement, la période d'utilisation de la solution, deuxièmement, la flexibilité en termes d'adaptabilité à de nouvelles exigences.

Si l'on veut créer rapidement quelque chose de présentable, les frameworks peuvent certainement être le moyen de choix. Si l'on souhaite utiliser la solution à plus long terme ou même la garder ouverte aux changements, l'utilisation de frameworks nécessite d'autres mesures pour en atténuer les inconvénients.

En principe, il faut toujours intégrer les frameworks ou les composants utilisés de manière à ce qu'ils ne constituent pas une partie élémentaire de la solution, afin d'éviter les dépendances fonctionnelles.

Cela peut être réalisé par une architecture logicielle qui s'abstrait le mieux possible des composants étrangers afin qu'ils restent interchangeables. Par exemple, les possibilités de saisie offertes par l'interface utilisateur graphique ne devraient pas jouer de rôle dans la logique d'exécution.

Tout cela nous amène à la conclusion que nous aimons regarder comment fonctionne un framework pour ensuite, le cas échéant, en reprendre certains concepts. Bien sûr, cette procédure est à première vue coûteuse, mais les possibilités correspondantes sont alors connues pour les demandes d'extension et les adaptations peuvent être effectuées de manière beaucoup plus contrôlée et donc plus sûre.

Les frameworks, comme leur nom l'indique, fixent un cadre pour créer des solutions. Ces contraintes peuvent aider à produire des résultats rapides, car un framework nous décharge de nombreuses décisions (conscientes ou inconscientes).

Mais au final, qui se décide pour ou contre un framework ? Le chef de projet ? Le développeur ? La solution optimale serait : les deux ensemble. Mais les opinions et les intérêts sont souvent très divergents :

Minimisation des risques contre flexibilité, résultats à court terme contre diversité des options à long terme.

Ce n'est que si tout le monde en est conscient de manière suffisamment approfondie qu'une décision consciente et correcte peut être prise dans ce domaine également.

HTML5

Contrairement aux frameworks (WebDynpro, SAPUI5), HTML5 n'est qu'un langage de balisage et représente la version actuelle (selon la spécification W3C) de HTML (Hypertext Markup Language).

Le langage HTML sert en soi à décrire et à lier/associer des contenus web (tels que des textes, des images, des vidéos) sous forme de documents électroniques. Il s'agit notamment des pages web et autres solutions basées sur le web avec une interface graphique affichée à l'aide de navigateurs web ou d'autres moteurs de navigation.

Lors du développement d'une solution HTML, on a généralement recours aux CSS (Cascading Style Sheets) pour la mise en forme des documents HTML. C'était déjà le cas dans les versions précédentes de HTML et cela se poursuit avec la version actuelle de HTML.

HTML et CSS ne suffisent toutefois pas encore à reproduire l'étendue des performances des solutions HTML5 dynamiques et plus complexes. Pour cela, un autre composant, JS (JavaScript), est nécessaire.

JavaScript est un langage de script qui permet de réaliser des dynamiques dans les documents HTML. Étant donné que les objectifs déterminants d'une solution découlent des exigences professionnelles, HTML5 est particulièrement adapté aux interfaces nécessitant un haut degré de flexibilité et de personnalisation.

Scénarios d'utilisation

Les scénarios d'application typiques de Pikon prévoient un échange de données avec un système backend (par exemple SAP ERP). Dans SAP, une solution HTML5 peut être mise en œuvre à cet effet à l'aide d'une Business Server Page (BSP) ou également en combinaison avec une application WebDynpro.

Une telle application ne s'exécute pas exclusivement sur le serveur SAP, mais avant tout sur un client mobile, et il faut trouver un moyen de communiquer avec SAP.

La voie classique dans l'environnement web est l'Internet Communication Framework (ICF) dans SAP NetWeaver. Dans ce cas, un client peut par exemple envoyer des données au serveur SAP à l'aide d'un service ICF et le serveur SAP peut renvoyer les données correspondantes. SAPUI5 nous épargne ce chemin avec SAP NetWeaver Gateway et oData Services.

Conclusion

En résumé, on peut dire qu'un développement HTML5 pur avec un mélange de composants créés par nos soins et de composants tiers utilisés sciemment est pour nous le moyen de choix, même si la mise en œuvre nécessite ici un certain nombre de connaissances, de discipline et d'efforts.

Mais c'est justement lorsqu'une équipe entière de développeurs travaille sur un sujet qu'il est judicieux de travailler à la structuration ainsi qu'à l'intelligibilité d'une solution, et l'effort en vaut la peine à chaque demande de modification qui suit et qui est mise en œuvre par la suite.

Pour ceux qui ne peuvent pas vivre avec les restrictions d'un framework, HTML5 est une solution tout à fait viable, même dans l'environnement SAP.

Dans l'ensemble, la question de savoir si un framework doit être utilisé et lequel doit l'être ne peut être tranchée qu'en fonction des exigences concrètes, notamment en termes d'individualité et d'adaptabilité du logiciel.