Alternatives à Fiori

Ce sera tout de suite un peu technique, car nous voulons examiner d'un œil critique la technologie Fiori et la comparer à l'architecture de notre propre produit "CIS mobile".

Il est donc utile pour la compréhension d'essayer quelques applications Fiori et notre CIS mobile avant. Voici les liens à ce sujet :

• http://sapfioritrial.com pour les applications Fiori
• http://s10mobile.com pour CIS mobile

Chaque application Fiori représente une petite fonction d'application standard isolée, implémentée comme une application web avec HTML5 comme front-end. Elle peut être exécutée sur n'importe quel appareil compatible avec le web (ordinateur de bureau, tablette, smartphone).

Au niveau de l'interface utilisateur, toutes les applications Fiori se ressemblent, car elles suivent des normes strictes, notamment l'"interface utilisateur Fiori 1-1-3" : un rôle d'utilisateur, un scénario, trois clics. Chaque application Fiori entre dans l'une des catégories "Transactional app", "Fact sheet" ou "Analytical app", seule "Transactional" se passe de base de données Hana.

Sur le plan technologique, les applications Fiori utilisent plusieurs frameworks complexes : l'application fonctionne comme un code JavaScript dans le navigateur. Elle génère l'interface HTML5 de manière dynamique avec SAP UI5, nécessite le framework JQuery et communique avec le FES (Fiori Frontend Server) via le protocole OData, SAP Web Dispatcher et SAP Gateway.

Le FES contacte finalement SAP Business Suite, qui fournit l'accès aux données et les fonctions de mise à jour sous forme de services sans état dans Abap. Pour notre produit CIS mobile, une application web mobile complète pour les commerciaux basée sur SAP SD, Fiori n'est pas suffisant, tant en ce qui concerne l'interface utilisateur 1-1-3 que l'infrastructure technologique.

Cela est dû en premier lieu aux exigences légitimes des utilisateurs : un commercial souhaite une vue intégrée de tous les aspects des clients dont il s'occupe, par exemple les offres, les commandes, les livraisons, la planification des rendez-vous, les rapports de visite, les contrats, les accords de bonus, les documents relatifs au client.

Il attend des diagrammes et des chiffres clés et souhaite renvoyer les informations clients au système SAP central de manière mobile. Les trois types d'applications, "transactionnelle", "fact sheet" et "analytical app", sont donc nécessaires, ainsi qu'une transition transparente de tous les composants.

Les efforts de vente peuvent être d'autant plus fructueux que l'on connaît bien la situation du client. Cela comprend non seulement les offres et les commandes, mais aussi les réclamations des clients et les factures impayées, par exemple. Avec une telle quantité d'informations, Fiori serait dépassé par son interface utilisateur 1-1-3.

Même si l'on parvenait à faire entrer l'application dans le schéma Fiori, l'utilisation deviendrait très laborieuse, car le schéma maître-détaillé utilisé dans Fiori impose des changements de contexte constants avec des vues à chaque fois uniquement particulières.

En revanche, l'interface utilisateur de CIS mobile est généralement conçue de manière à ce que vous puissiez consulter successivement des informations détaillées qui sont ensuite insérées de manière dynamique dans la page affichée. Par exemple, pour une commande, vous pouvez afficher les postes de la commande, puis les conditions pour le poste.

Faites de même pour un autre poste de commande. Il suffit maintenant de faire défiler la page pour comparer les deux positions en détail, ce qui est plus confortable et moins pénible qu'une navigation continue en avant/arrière avec la mémorisation des informations affichées.

IU et technologie

Mais la technologie Fiori ne pourrait-elle pas être utilisée pour implémenter des modèles d'interface utilisateur très différents et plus complexes ? C'est apparemment ce que prévoit SAP, puisque Fiori doit progressivement remplacer SAP GUI comme frontal pour S/4 Hana.

Cela va-t-il fonctionner ? Si l'on regarde de plus près l'implémentation des applications Fiori, il faut beaucoup de JavaScript malgré la petite taille des applications. Si l'on réalise une fonction d'application comparable à l'application Fiori de manière classique avec Abap-Dynpro, il suffit d'un effort de codage beaucoup moins important. Cela ne rend pas très optimiste quant aux futures applications complexes.

Technologie CIS-mobile

Il y a quelques points communs entre notre technologie CIS-mobile et Fiori, mais des différences très importantes. Comme Fiori, nous utilisons HTML5 comme frontal afin de prendre en charge tous les terminaux compatibles avec le web.

Dans le navigateur, le CIS mobile n'exécute pas l'ensemble de l'application, mais uniquement la partie UI sous la forme de masques HTML5 prédéfinis et d'un JavaScript utilisé avec parcimonie pour des fonctions UI spécifiques.

Le HTML statique a l'avantage de permettre l'utilisation de n'importe quel éditeur HTML normal pour développer et personnaliser en WYSIWYG l'interface, ce qui n'est pas le cas avec UI5.

L'application CIS-mobile elle-même se trouve sur un serveur Windows central avec Microsoft IIS (Internet Information Services). Elle est implémentée en VB.NET, ce qui offre l'avantage d'un environnement de développement sophistiqué et confortable (Visual Studio) dans lequel, contrairement à JavaScript, nous disposons de toutes les possibilités de Windows, par exemple l'utilisation de fichiers temporaires ou la création de diagrammes avec des paquets graphiques.

CIS mobile communique avec le système SAP via des interfaces perfomantes sur le réseau local, basées sur SAP RFC et SAP GUI. SAP Gateway et OData sont également possibles, mais ne sont pas utilisés dans CIS mobile, car nous prenons également en charge les systèmes ERP plus anciens et également les systèmes non Unicode.

L'acquisition des données est réalisée dans des modules fonctionnels Abap, la mise à jour des données SAP (par ex. dates, interlocuteurs, offres) via des transactions SAP GUI (scripting), afin de garantir tous les contrôles et mises à jour standard SAP.

Tous les composants de l'architecture CIS-mobile sont des technologies standard (HTML5, VB.NET, IIS, Abap, RFC et SAP GUI), chacune d'entre elles offrant déjà une fonctionnalité robuste et riche.

D'une manière relativement simple et évidente, ces éléments sont assemblés en une architecture qui permet le développement d'applications web sophistiquées dans l'environnement SAP.

Application côté serveur

L'application côté serveur présente de nombreux avantages : Premièrement, la sécurité, car une application JavaScript dans le navigateur peut être manipulée en appelant le débogage JavaScript.

Deuxièmement, nous pouvons conserver sur le serveur, dans un cache d'application distinct accessible par tous les processus utilisateur, des données en lecture seule fréquemment utilisées, auxquelles l'application peut accéder en quelques microsecondes.

Troisièmement, il est plus facile de garantir un développement confortable, un dépannage et un fonctionnement stable en continu sur un seul serveur que dans une architecture où de grandes parties de l'application s'exécutent sur une multitude d'appareils et de versions de logiciels. Pour un grand nombre d'utilisateurs, il est possible de répartir les applications sur plusieurs serveurs.

La connexion entre l'interface utilisateur HTML et VB.NET se fait par action de l'utilisateur en un seul roundtrip entre le front-end et le serveur. Plusieurs requêtes peuvent ensuite avoir lieu entre le serveur et le système SAP.

Comme le temps de réponse d'une requête web est en moyenne plus de dix fois supérieur au temps de réponse du réseau local, il s'agit d'une stratégie raisonnable qui nous permet d'obtenir de très bons temps de réponse.

En revanche, dans le cas d'une application côté navigateur, il faut s'efforcer de ne pas déclencher trop de roundtrips vers le serveur par action de l'utilisateur, ce qui signifie en général que l'interface de données des services appelés devient de plus en plus volumineuse et doit être adaptée à chaque information supplémentaire.

La réutilisation de services par d'autres apps devient difficile, soit parce que l'on se procure trop d'informations et que le système SAP est inutilement surchargé, soit parce que l'on dispose de nombreux services spécialisés, mais que l'on a alors besoin de plus de roundtrips.

UI et application

Le lien logique entre l'interface utilisateur HTML et VB.NET consiste en un mappage de la hiérarchie HTML sur la hiérarchie d'objets dans VB.NET. Au total, l'application CIS-mobile est réalisée sous la forme d'environ 200 classes VB.NET, dont le nom et le contenu s'inspirent généralement des objets de gestion SAP, par exemple les postes de vente VBAP ou les divisions T001W.

Les attributs des classes sont abordés dans l'interface HTML par leur nom, qui est collecté par l'interprétation du DOM et envoyé au serveur.

L'évaluation des attributs de classe et la navigation au sein de la hiérarchie d'objets sur le serveur se font alors de manière dynamique. Chaque classe VB.NET peut fournir ses propres parties d'interface utilisateur sous forme d'images HTML.

Nous obtenons ainsi une certaine indépendance de l'interface utilisateur par rapport à l'application. Si, par exemple, le point d'expédition est affiché sous forme de code "1000" dans la position de commande ("VSTEL") et que le texte correspondant "Point d'expédition Zurich" est souhaité, il suffit d'utiliser l'attribut "VSTEL.VTEXT" en HTML.

Sur le serveur, l'accès au texte se fait alors automatiquement via la table SAP TVSTT, ce qui ne représente en général qu'un accès au cache de quelques microsecondes.

Aucun codage supplémentaire n'est ici nécessaire, ni en HTML/JavaScript, ni en VB.NET, puisque le lien entre le code du point d'expédition et le texte est connu via le modèle de données. Dès que nous remplaçons à nouveau "VSTEL.VTEXT" par "VSTEL", l'accès à la table de texte n'est plus nécessaire sur le serveur.

Voilà pour cette petite incursion dans un détail de l'architecture, qui montre que la modélisation et l'interprétation du modèle au moment de l'exécution permettent d'économiser beaucoup de code d'application.

Séparation des préoccupations

La séparation de l'IU (HTML), du codage de l'application (VB.NET) et des accès SAP (Abap) facilite un processus de développement robuste et bien structuré. Dans Fiori, comme l'IU et l'application sont implémentées conjointement en JavaScript, cette séparation ne peut être obtenue qu'au prix d'une discipline appropriée.

Conclusion

De par son architecture, la force de Fiori réside dans les petites applications isolées. CIS mobile est optimisé pour mettre à disposition de l'utilisateur professionnel la SAP Business Suite de manière adéquate, même dans une interface web mobile : rapide, claire et complète.