Stratégies d'extension clean-core pour la supply chain SAP

Les landscapes entrepôt et supply chain tendent à accumuler de la logique spécifique plus vite que d'autres modules SAP, car la réalité opérationnelle — une interface d'automatisation particulière, une règle de conditionnement propre à un client, une stratégie de rangement non standard — correspond rarement exactement au paramétrage standard. Non maîtrisée, cette logique spécifique s'intègre dans les objets standard et devient la principale source de risque de montée de version.

EWM en particulier est proche des opérations physiques : interfaces d'automatisation, transactions RF et gestion des exceptions sont exactement le type de logique qui se voit enrichie sous pression de délai, directement dans les objets standard, lorsqu'un projet court vers sa mise en production. C'est précisément cette dette qui rend la prochaine montée de version S/4HANA ou la prochaine mise à jour de release EWM coûteuse et risquée.

Le clean core est la discipline consistant à maintenir cette personnalisation nécessaire hors des objets standard et derrière des points d'extension définis, afin que les montées de version touchent du paramétrage et des extensions aux interfaces connues, plutôt que du code standard modifié aux effets de bord imprévisibles.

Les extensions side-by-side s'exécutent sur SAP BTP, en dehors du système ERP ou EWM lui-même, en communiquant via des API publiées. Le SAP Cloud Application Programming Model (CAP) et le RESTful ABAP Programming Model (RAP) sont les deux boîtes à outils standard pour construire cette logique — CAP pour les services natifs BTP, RAP lorsque du développement ABAP est justifié, exposés via OData ou REST.

Ce modèle convient aux fonctionnalités qui n'ont pas besoin de s'exécuter à l'intérieur du processus EWM ou S/4HANA lui-même : couches de reporting, outillage d'investigation des exceptions, orchestration d'intégration, ou microservices entiers qui consomment des données EWM sans avoir besoin d'être déployés à ses côtés. Cela maintient le parcours de montée de version du système cœur totalement dégagé de cette logique.

La contrepartie est une complexité architecturale et une latence supplémentaires — les extensions side-by-side dépendent de la disponibilité des API et des allers-retours réseau, ce qui en fait un mauvais choix pour une logique devant s'exécuter de façon synchrone dans une confirmation d'ordre entrepôt ou une boucle de transaction RF serrée.

L'extensibilité in-app utilise les points d'extension publiés — outils d'extensibilité key-user, BAdI publiés, extensions de vues CDS et API publiées — à l'intérieur du système S/4HANA ou EWM lui-même. C'est le bon choix pour la logique qui doit réellement s'exécuter in-process : champs personnalisés, validations de champ, logique de détermination dans un flux de création d'ordre entrepôt, ou une implémentation de BAdI publié pour une étape de processus EWM spécifique.

La discipline qui compte est la retenue : n'utiliser que des points d'extension publiés et stables pour les montées de version, et considérer tout objet non marqué comme publié ou extensible par le key-user comme hors limites, quelle que soit la commodité apparente d'une modification directe. Les directives d'extensibilité de SAP existent précisément pour indiquer quels objets peuvent être étendus sans compromettre les montées de version futures.

Le test pratique porte sur l'endroit où la logique doit s'exécuter et sur son degré de couplage avec la transaction qu'elle sert. Une logique à l'intérieur d'une confirmation d'ordre entrepôt, d'une sortie d'écran RF synchrone, ou tout ce qui a des contraintes de latence strictes, relève de l'in-app, via un point d'extension publié. Une logique pouvant s'exécuter de façon asynchrone, servant plusieurs systèmes, ou bénéficiant de cycles de déploiement indépendants, relève du side-by-side sur BTP.

Dans la plupart des landscapes EWM et S/4HANA supply chain, la réponse est les deux, appliqués délibérément et non par défaut — extensibilité in-app pour la logique de processus fortement couplée, extensions side-by-side pour l'orchestration, le reporting et les fonctionnalités transverses, avec une gouvernance clean-core qui définit lequel s'applique où avant le début du développement, pas après.