Side-by-side : étendre S/4HANA Public Cloud avec de petites applications Cloud Foundry, sans sacrifier le clean core

Chaque projet S/4HANA Public Cloud arrive au moment où l’extensibilité key user atteint son plafond. Un champ supplémentaire, une validation, une mise en page adaptée : aucun problème, c’est fait pour cela. Mais ensuite la vente veut un tableau de bord qui agrège le chiffre d’affaires sur plusieurs années et des dizaines de milliers de documents. Ou un service a besoin d’un petit processus que le standard ne connaît pas. Et la question est sur la table : faut-il finalement toucher au cœur ?

Non. La réponse est le side-by-side : une petite application sur SAP BTP Cloud Foundry qui vit à côté du système et lui parle exclusivement via des API publiées. L’ERP reste intact, l’extension tourne à côté, et « petite » est à prendre au pied de la lettre.

En bref : quand l’extensibilité key user ne suffit pas, construisez une petite application CAP sur SAP BTP Cloud Foundry qui lit et écrit dans S/4HANA Public Cloud uniquement via des API publiées, connectée par le service Destination et un communication arrangement dédié. Restez sobre : tableaux de bord orientés lecture et petits scénarios d’écriture clairement délimités. Les mises à niveau passent alors sans que personne ne s’en aperçoive, et les coûts d’exploitation restent faibles.

Le modèle : une petite application à côté du système

Le schéma est toujours le même, et c’est précisément sa force. En backend, un service construit avec le SAP Cloud Application Programming Model (CAP), en Node.js ou en Java, qui récupère, agrège ou enrichit des données de S/4HANA. Devant, un frontend : SAPUI5/Fiori si l’application doit ressembler à SAP, un frontend web simple sinon. La connexion à l’ERP passe par le service Destination et un communication arrangement dans S/4HANA, et seules des API publiées du SAP Business Accelerator Hub sont consommées. SAP documente l’approche sous le nom d’extensibilité side-by-side avec SAP BTP.

C’est tout. Pas de zoo de frameworks, pas de plateforme maison, pas de modification. Quiconque a déjà monté un projet Node.js se repère dans CAP en quelques jours. Et comme l’environnement Cloud Foundry facture la mémoire par instance, une application qui tourne dans quelques centaines de Mo coûte peu à exploiter.

Un exemple tiré d’un de nos projets

Dans une entreprise commerciale suisse, la vente voulait voir dans le CRM ce qu’un client avait acheté au fil des ans : chiffre d’affaires par année, par groupe de produits, tendance. Les données brutes se trouvent dans l’ERP, réparties sur environ 75’000 commandes clients. Aucun rapport CRM standard ne couvre cela, et personne ne voulait modifier l’ERP pour autant.

Nous avons donc construit une petite application side-by-side : un service CAP qui lit les commandes via l’API publiée des commandes clients, les agrège par client et sert un tableau de bord simple. Elle est intégrée sous forme de mashup directement dans SAP Sales Cloud V2, avec authentification unique pour que personne ne se connecte deux fois. Le commercial ouvre le client dans le CRM et voit le tableau de bord comme s’il faisait partie du produit.

Le résultat : l’ERP n’a jamais été touché. L’application tourne dans quelques centaines de Mo de mémoire Cloud Foundry, et les coûts d’infrastructure mensuels se situent dans les deux chiffres en francs. La vente a obtenu une vue du client qui n’existait pas auparavant. Le même modèle côté CRM est décrit dans notre article sur l’extension de Sales Cloud V2 avec des applications Cloud Foundry sur mesure.

La checklist d’architecture

Pour garder le modèle propre, nous nous en tenons à cinq points dans chaque projet :

1. Uniquement des API publiées. Ce qui n’est pas documenté comme publié sur le SAP Business Accelerator Hub n’est pas consommé. Cette seule règle décide si l’application survit aux mises à niveau.
2. Un communication arrangement par scénario. Pas un arrangement fourre-tout avec tous les périmètres, mais un arrangement dédié par cas d’usage métier. Les autorisations restent traçables et le décommissionnement indolore.
3. Propagation de l’identité ou utilisateur technique : décider consciemment. Si l’ERP doit savoir quelle personne interroge, il vous faut la propagation de l’identité (principal propagation). Un utilisateur technique est plus simple, mais l’application vérifie alors elle-même qui peut voir quoi. Les deux sont légitimes ; ne pas décider ne l’est pas.
4. Service Destination plutôt que des URL dans le code. Points de terminaison, identifiants et méthode d’authentification vivent dans la destination, jamais dans le dépôt de code.
5. Un sous-compte BTP par environnement. Test et production séparés, chacun avec des destinations pointant vers le système S/4HANA correspondant. Cela paraît évident et c’est étonnamment souvent sauté.

Le bénéfice : des mises à niveau dont personne n’a à se soucier

S/4HANA Public Cloud reçoit ses mises à niveau de version selon le calendrier de SAP, que cela vous plaise ou non. Si vous aviez modifié le cœur, vous testeriez vos modifications à chaque mise à niveau. L’application side-by-side ne remarque pas la mise à niveau, parce qu’elle n’utilise que des API publiées et versionnées que SAP maintient stables. Notre tableau de bord de l’exemple a traversé plusieurs versions sans aucun travail de notre part.

C’est tout l’intérêt du clean core : pas un dogme, mais la liberté de laisser les mises à niveau se faire.

Construire sobrement

La règle la plus importante pour les applications side-by-side n’a rien de spectaculaire : construisez-les sobrement. Tableaux de bord orientés lecture, petits scénarios d’écriture via des API publiées, tâches clairement délimitées. C’est là que le modèle excelle.

Deux signaux d’alerte tirés de projets que nous avons repris. Premièrement, si vous vous surprenez à répliquer la moitié de l’ERP dans une base HANA Cloud, arrêtez-vous et repensez la cible. À partir de là, vous construisez un second système avec tous les problèmes de synchronisation qui vont avec. Deuxièmement, surveillez les limites de débit des API. Une application qui interroge à nouveau 75’000 documents à chaque chargement de page apprend à ses dépens que les API publiées sont limitées. Agrégez, mettez en cache et rechargez selon un calendrier.

Si la logique doit au contraire s’insérer de manière synchrone dans le flux de documents de l’ERP, ABAP Cloud est le meilleur outil ; nous l’avons décrit dans Embedded Steampunk dans S/4HANA Public Cloud. Vous choisissez un partenaire pour ce type de travail ? Notre panorama des partenaires de développement SAP BTP en Suisse indique quoi demander, et SAP BTP chez Spadoom montre notre façon de travailler. Les applications side-by-side sont aussi une brique typique de la pile intégrée S/4HANA Public Cloud et Sales Cloud V2, c’est pourquoi nous couvrons les deux moitiés avec une seule équipe, comme le décrit notre guide du meilleur partenaire SAP pour le Cloud ERP et le CRM en Suisse.

Questions fréquentes

Combien coûte l’exploitation d’une petite application Cloud Foundry ?

Moins que ce que la plupart des gens imaginent. Vous payez essentiellement la mémoire Cloud Foundry, plus de petits montants pour des services comme destination et autorisation. Notre application d’exemple, avec quelques centaines de Mo de mémoire, coûte un montant à deux chiffres en francs par mois ; le coût déterminant est le développement, pas l’exploitation, et même celui-ci reste raisonnable pour un scénario ciblé.

Quand l’extensibilité key user, quand BTP Cloud Foundry, quand ABAP Cloud ?

L’extensibilité key user pour les champs, les validations et les adaptations d’interface dans une application existante. BTP Cloud Foundry quand vous avez besoin de votre propre agrégation de données, de votre propre interface ou d’une intégration dans un autre système comme un CRM. ABAP Cloud (developer extensibility, aussi appelé Embedded Steampunk) quand la logique doit tourner près des transactions de l’ERP et que l’équipe maîtrise ABAP.

Une telle application peut-elle être intégrée dans SAP Sales Cloud V2 ?

Oui. Sales Cloud V2 intègre l’application sous forme de mashup dans la vue du compte ou de l’opportunité. Avec une authentification unique bien configurée, les utilisateurs ne remarquent pas qu’ils travaillent dans une application externe ; c’est ainsi que fonctionne le tableau de bord de chiffre d’affaires de notre exemple.

L’application casse-t-elle quand SAP modifie l’API ?

Les API publiées sont versionnées, et SAP garde les versions publiées stables ; les nouvelles versions s’ajoutent. Le risque se situe presque entièrement du côté des interfaces non publiées, c’est pourquoi la première règle de notre checklist est de ne consommer que des API publiées.

---

Votre extensibilité key user est à bout et la prochaine proposition sur la table parle de modifier le cœur ? Nous vous montrons à quoi ressemble le modèle side-by-side dans votre cas. Parlez à notre équipe.