OpenUI5

SAP livre le framework UI5 sous deux formes. OpenUI5 est la version open source ; SAPUI5 est celle intégrée aux produits SAP comme SAP BTP et la plateforme ABAP. La principale différence est la licence, pas le modèle de programmation.

Trois faits découlent de cette origine commune :

1. Même cœur. Le runtime, le data binding, le routage et les bibliothèques de contrôles les plus courantes, par exemple sap.m, sap.ui.layout et sap.ui.unified, sont identiques dans les deux livraisons.
2. Mêmes noms techniques. Les noms des contrôles, les noms des bibliothèques et les API correspondent : du code écrit pour OpenUI5 continue de fonctionner lorsque le runtime passe à SAPUI5.
3. Versions alignées. Les deux livraisons suivent la même ligne de versions, même si SAP précise que les numéros de version peuvent différer au niveau du patch. La boîte de dialogue des informations techniques (Ctrl+Alt+Shift+P) affiche la version réellement chargée par une application.

SAPUI5 est donc un sur-ensemble : tout le contenu d'OpenUI5, plus des bibliothèques propres à SAP. OpenUI5 est le sous-ensemble open source de SAPUI5, pas un framework distinct.

La comparaison des listes de bibliothèques publiées pour la version 1.154 montre que chaque bibliothèque OpenUI5 fait aussi partie de SAPUI5, tandis que SAPUI5 en ajoute plusieurs dizaines. Les écarts les plus importants dans les projets SAP :

OpenUI5 reste très complet : sap.m, sap.f, la mise en page object page de sap.uxap, sap.ui.table, les contrôles pilotés par métadonnées de sap.ui.mdc, les bibliothèques de flexibilité sap.ui.fl et sap.ui.rta, les integration cards et la bibliothèque du thème SAP Horizon. La liste évolue d'une version à l'autre ; vérifiez-la pour la version que vous ciblez. OpenUI5 couvre les briques d'une application web complète, mais pas les couches SAP qui génèrent ou hébergent les applications SAP Fiori.

Appliquez ce critère de décision : si l'application dépend du runtime d'un produit SAP ou d'une bibliothèque réservée à SAP, utilisez SAPUI5 ; sinon, OpenUI5 est un choix valable.

OpenUI5 convient lorsque :

• l'application s'exécute en dehors des produits SAP, par exemple un portail web public ou un outil interne sur un back-end non SAP ;
• le projet est lui-même open source, comme un outil UI5, un exemple ou une bibliothèque de contrôles personnalisés, et ne doit pas dépendre de code sous licence SAP ;
• une équipe apprend UI5 et souhaite un runtime et une documentation librement accessibles.

SAPUI5 convient lorsque :

• l'application s'exécute dans le SAP Fiori Launchpad ou SAP Build Work Zone, qui chargent de toute façon le runtime SAPUI5 ;
• l'application utilise SAP Fiori elements, les smart controls ou les graphiques SAP ;
• l'application est livrée sur la plateforme ABAP ou SAP BTP, où SAPUI5 fait partie du produit.

Pour Alder Manufacturing, une page d'auto-inscription fournisseur pour Cedar Office Supply sur un serveur web non SAP est candidate à OpenUI5 ; un list report des commandes d'achat dans le launchpad ne l'est pas. OpenUI5 est le bon choix lorsque l'indépendance vis-à-vis des licences des produits SAP compte davantage que les bibliothèques propres à SAP.

• Pas de floorplans générés. Sans SAP Fiori elements, les list reports et les object pages doivent être construits à la main avec des contrôles standard ; l'effort correspond donc à celui du SAPUI5 freestyle, pas à celui du développement piloté par annotations.
• Pas de runtime de launchpad propre. Les applications destinées au SAP Fiori Launchpad s'exécutent sur le runtime SAPUI5 du launchpad, pas sur OpenUI5. En pratique, une application OpenUI5 qui rejoint un paysage SAP devient une application SAPUI5.
• La persistance de la flexibilité est externe. Les bibliothèques de flexibilité sont incluses, mais stocker en production les modifications des key users et des utilisateurs finaux exige un back-end : le layered repository d'un système ABAP ou des services SAP BTP. Les connecteurs de stockage navigateur sont destinés aux tests.
• Modèle de support. Les bugs et demandes d'évolution d'OpenUI5 sont remontés publiquement sous forme d'issues GitHub ; la couverture d'un usage donné d'OpenUI5 par un contrat de support SAP dépend des conditions de ce contrat.

Ces limites découlent de la séparation elle-même : OpenUI5 est le framework, et SAPUI5 y ajoute ce dont les produits SAP ont besoin.

1. Démarrer sur OpenUI5 et découvrir une dépendance tardivement. Un projet qui a ensuite besoin des smart controls, de SAP Fiori elements ou de l'export vers tableur doit passer à SAPUI5. Correctif : listez les bibliothèques requises avant de choisir la livraison.
2. Assimiler OpenUI5 à la conformité SAP Fiori. Les contrôles OpenUI5 suivent le design SAP Fiori, mais ce sont la mise en page, la navigation et la formulation qui déterminent si une application respecte les SAP Fiori Design Guidelines. Correctif : évaluez l'application au regard des guidelines, pas seulement des contrôles.
3. Mélanger les livraisons dans un même paysage. Lancer certaines applications depuis le réseau de diffusion de contenu OpenUI5 et d'autres depuis celui de SAPUI5 complique les comparaisons de versions et le diagnostic. Correctif : utilisez une seule livraison par application et documentez-la.
4. Ignorer les différences au niveau du patch. Les numéros de version d'OpenUI5 et de SAPUI5 peuvent diverger au niveau du patch. Correctif : consultez la boîte de dialogue des informations techniques lorsqu'un bug apparaît dans une livraison et pas dans l'autre.

La plupart des problèmes OpenUI5 sont des décisions de périmètre prises trop tôt, pas des défauts du framework.