Le sort des spécifiques dans SAP Business Technology Platform (BTP)
Avec la volonté de généraliser les éditions cloud de S/4HANA, SAP entend en principe faire de la Business Technology Platform (BTP) le lieu d’hébergement pour les spécifiques des clients. Cependant, l’éditeur ne ferme pas la porte à la possibilité de rapprocher les applications les moins découplées de son cœur standard.
Commercialement, la BTP comprend une liste de produits pour bénéficier de bases de données, d’outils de gestion de données, de datawarehousing, d’analytique, de quelques capacités de machine learning, de services IoT et surtout d’outils de développement.
Techniquement, la Business Technology Platform, autrefois nommée SAP Cloud Platform, est une PaaS hébergée chez les fournisseurs de cloud. Il s’agit donc du lieu d’accueil des types de services listés ci-dessus, à retrouver dans l’interface SAP Discovery Center. L’éditeur allemand présente la BTP comme l’espace où les clients peuvent déployer des applications innovantes. Mais c’est aussi une PaaS pour héberger les extensions personnalisées, des spécifiques, existants ou non.
Pour les entreprises en provenance d’ECC, c’est un changement de taille, car elles doivent passer d’une approche monolithique à une architecture découplée, voire de microservices. « Nous avons un impact organisationnel à anticiper. Aujourd’hui, tout est compris dans un même bloc. Demain, j’ai plusieurs blocs auxquels je dois associer des compétences, et il faut je change d’une approche monolithique à une autre basée sur les données », considère Gianmaria Perancin, président de l’USF, le club des utilisateurs français SAP.
SAP BTP : trois environnements de développement + 1
Car si certains services sont parfois prêt à l’emploi et se connectent directement à S4/HANA, d’autres sont des briques dans lesquelles piocher pour développer les applications d’une entreprise. En l’occurrence, SAP dispose de plusieurs environnements de développement depuis le Cockpit de BTP. Le plus ancien se nomme NEO. Il s’agit d’une branche propriétaire de BTP hébergée sur les data centers de SAP pensée comme une « enterprise PaaS ». Elle est consacrée au développement d’applications HTML 5 (via le framework SAPUI5 ou OpenUI5), Java et SAP HANA extended application services (SAP HANA XS). Neo exécute une partie des services présents sur le catalogue Discovery Center, et permet surtout d’orchestrer des applications sur des serveurs Java, sur des machines virtuelles. Son accès dépend d’un sous-compte différent du reste de la plateforme de développement.
L’environnement Cloud Foundry est open source, et a été choisi par SAP justement pour remplacer l’ancien NEO sur les infrastructures des cloudistes (AWS, GCP, Azure, Alibaba Cloud). Cloud Foundry permet d’accueillir les runtimes des applications ABAP, Java et JavaScript (via Node.js), mais aussi PHP, Go, Ruby, .Net Core, etc. via des buildpacks. À cela s’ajoute, l’environnement Kyma, un projet open source conçu pour étendre les capacités de CF avec des microservices conteneurisés et des fonctions Python ou Node.js (FaaS, Serverless) dans des clusters Kubernetes. Enfin, le petit nouveau se nomme « environnement ABAP » et s’appuie sur le même espace Cloud Foundry.
« Dans l’environnement Cloud Foundry, vous pouvez créer un nouvel espace pour le développement ABAP. C’est ce que nous appelons l’environnement ABAP. Il vous permet de créer des extensions pour les produits basés sur ABAP, tels que SAP S/4HANA Cloud, et de développer de nouvelles applications cloud. Vous pouvez transformer le code personnalisé existant basé sur ABAP ou les extensions vers le cloud », peut-on lire dans la documentation.
Quid du développement low-code ?
Le low-code est bien une deuxième voie de développement dans la BTP. Là encore, il existe deux possibilités évidentes. La première consiste à utiliser Business Application Studio, un outil à déployer dans l’environnement Cloud Foundry. Il permet de concevoir des UX SAP Fiori à déployer dans le runtime CF. Deuxième possibilité, depuis le Discovery Center, Mendix met à disposition SAP Rapid Application Development, une solution low-code réunissant Mendix Studio Pro et Mendix Development Portal pour créer des applications métiers (onboarding, outil de commande d’équipements en entreprise, etc.). De son côté, SAP prépare plusieurs outils BPM et RPA. À chaque fois, il s’agit de s’appuyer sur des connecteurs vers les composants clés de S/4HANA.
Les environnements Cloud Foundry, Kyma et ABAP forment la « Multi-Cloud Foundation ». Si l’éditeur ne mentionne pas réellement le terme, sûrement pour ne pas froisser les fournisseurs de cloud, cette approche multicloud est pourtant dans la feuille de route de SAP. D’ailleurs, CF et Kyma sont davantage tolérants aux services et aux développements « non SAP ». Pour les clients qui déploient S/4HANA on-premise, l’accès à la Business Technology Platform est distant, après la mise en place d’un tunnel sécurisé pour éviter le blocage du pare-feu (oui, S4/HANA est possiblement hybride).
BTP, la terre d’accueil des spécifiques avec RISE with SAP
Or la Business Technology Platform prend une importance forte dans le cadre du contrat unique proposé avec RISE with SAP. Alors, qu’est-ce que recommande l’éditeur allemand pour ceux qui souhaiteraient faire migrer leurs spécifiques en périphérie de S4/HANA Cloud ?
Tout d’abord, il faudra passer par la suite d’outils « Readiness Check », et ce le plus tôt possible dans la préparation de la migration, préconise l’éditeur. Readiness Check permet de lister les fonctions métiers actives d’un système existant dans le but d’identifier celles compatibles avec S/4HANA. Il recommande les applications Fiori les plus pertinentes, révèle les intégrations impactées par la migration, indique les solutions adaptées à l’activité de l’entreprise, liste les add-ons compatibles et donne accès à Custom Code Migration.
Custom Code Migration est un outil de migration du code personnalisé qu’il faut soit rattacher à un environnement de test S/4HANA, soit à l’environnement ABAP au sein de la BTP. Custom Code Migration est inclus dans l’offre RISE with SAP et permet de migrer les extensions existantes et de les modifier dans BTP, en consommant les crédits associés BTP au contrat.
« Clean Core » : SAP veut protéger son code standard
Le but premier de SAP n’est pas d’assurer une compatibilité parfaite des spécifiques existants avec S/4HANA. L’éditeur souhaite que ses clients appliquent l’approche « Clean Core ».
La notion de « Clean Core » vise à débarrasser au maximum S4/HANA du code personnalisé. Désormais, SAP veut que l’on ne touche pas à son moteur.
« En termes pratiques, garder le noyau propre (Clean Core) signifie appliquer une politique de modification zéro ou minimale depuis le début. En bref, ne modifiez pas le code standard SAP, car cela bloque le système pour les mises à jour et les mises à niveau du système, et augmente l’effort des cycles de test et de mise à niveau. Essayez de rester proche de la norme et pour les besoins différenciés/uniques de l’entreprise, utilisez les API en liste blanche pour les extensions, afin d’incorporer le code personnalisé », lit-on dans la documentation de SAP.
Néanmoins, l’on comprend également qu’il est toujours possible de s’éloigner du standard SAP, notamment avec les éditions cloud privées : c’est tout simplement fortement déconseillé.
Une migration des spécifiques à planifier un an à l’avance
Custom Code Migration vise donc en premier lieu à détecter les éléments de code incompatibles et inutilisés de SAP ERP.
« SAP recommande de collecter les données d’utilisation dans vos systèmes de production au moins un an avant votre projet de conversion SAP S/4HANA, à l’aide d’ABAP Call Monitor et de SUSG. »
Olga DolinskajaProduct manager, ABAP Platform, SAP
« Nos statistiques des 15 dernières années montrent que 30 à 60 % du code personnalisé dans un système SAP ERP en production n’est pas exécuté, une autre partie considérable peut être remplacée par le code standard SAP lors de la conversion du système. La suppression du code obsolète permettra de réduire fortement les coûts liés à l’adaptation et à la maintenance future du code personnalisé. En même temps, il s’agit certainement d’un premier pas vers le Clean Core », écrit Olga Dolinskaja, Product Manager, ABAP Platform, chez SAP.
« L’identification du code personnalisé non utilisé commence par la compréhension de son usage dans les environnements de production du client. SAP recommande donc de collecter les données d’utilisation dans vos systèmes de production au moins un an avant votre projet de conversion SAP S/4HANA, à l’aide d’ABAP Call Monitor et de SUSG. […] », ajoute-t-elle.
Custom Code Migration doit également aider à identifier le code personnalisé à simplifier et à vérifier si un équivalent « standard » existe. Une fois l’analyse effectuée, la suppression du code « obsolète » est effectuée via Custom Code Migration ou SAP Software Update Manager.
Après migration, le code peut enfin être simplifié via la fonction « Quick Fixes » dans ABAP development Tools (ADT) pour Eclipse. SAP promet « jusqu’à 60 % d’automatisation pour les simplifications les plus fréquentes ».
Dans ce paradigme, l’approche lift and shift, même pour ceux qui auraient opté pour S/4HANA sur site, n’est plus recommandée.
« Il existe plusieurs façons de procéder, par exemple en supprimant l’ancienne logique de gestion, en repensant vos applications personnalisées à l’aide de l’extensibilité de SAP S/4HANA ou en envisageant la transformation SAP BTP pour les extensions personnalisées à couplage lâche », assure Olga Dolinskaja. « Bien sûr, il s’agit d’un défi et cela vous coûtera du temps et des efforts, mais ces efforts seront récompensés lors des futures mises à jour de SAP S/4HANA et de la transformation vers SAP BTP ».
Un cinquième environnement isolé de S/4HANA, une alternative en cours de développement
Mais SAP a bien conscience que certaines applications ou certaines extensions sont étroitement liées au standard SAP. Comme l’extensibilité « classique » n’est pas prise en charge dans S/4HANA Cloud, il faut bien un autre environnement que BTP (correspondant à une extensibilité « Side by Side », sic) pour ces programmes moins découplés.
« À partir de 2021, SAP prévoit d’offrir une option d’extensibilité supplémentaire dans le cadre de SAP S/4HANA et de SAP S/4HANA Cloud pour compléter les capacités d’extensibilité actuelles des utilisateurs clés (in-app) », renseigne le guide dédié à l’implémentation du code personnalisé de SAP.
L’option d’extensibilité prévue pour les développeurs (on-stack) doit répondre aux exigences programmeurs ABAP qui souhaiterait maintenir leurs applications customs tout en respectant la notion de « clean core ».
« Techniquement, cela vous permettra de développer des extensions personnalisées sur la même plateforme ABAP que celle employée par l’instance SAP S/4HANA ou le locataire SAP S/4HANA Cloud. Une séparation claire entre le code personnalisé et le code standard est obtenue en adoptant le modèle de programmation d’applications RESTful ABAP basé sur des vues CDS et un ABAP optimisé », envisagent les auteurs.
Si un tel environnement de développement voit le jour, il pourrait sans doute convenir aux clients en provenance d’ECC, puisqu’ils pourront réutiliser une partie de leur logique applicative de leur système SAP ERP. L’éditeur prévient que les fonctionnalités ABAP les plus classiques telles que les transactions et les programmes SAP GUI ne seront pas disponibles.
