Headless, mais pas sans tête

Produits configurables avec SAP Commerce et SAP Spartacus

Pour répondre à l'hétérogénéité des besoins en matière de vente, SAP Commerce peut être adapté aux exigences individuelles grâce à des packs d'extension modulaires. L'extension Configurator Complex Products (CCP) permet de gérer des produits configurables et complexes et réalise l'intégration avec SAP Variant Configuration and Pricing Services (souvent abrégé en CPS), qui est responsable de la mise en œuvre de la logique de configuration. Une abstraction appropriée permet également d'intégrer des environnements de configuration non natifs de SAP, par exemple des configurateurs historiques.

Outre la mise en œuvre fonctionnelle et logique de la personnalisation des produits configurables, CCP fournit un front de magasin rudimentaire pour l'affichage et l'interaction des produits dans le catalogue de produits du système de commerce. La représentation continue des structures de produits - du moteur de configuration au catalogue de produits au point de vente central (PoS) - permet de concevoir une expérience client continue et d'automatiser les processus de production internes à l'entreprise sur la base des données de produits gérées de manière centralisée.

SAP Spartacus

SAP Spartacus est un projet open source sous licence Apache License 2.0, géré et développé principalement par l'équipe cloud de SAP Commerce. Basé sur le framework Angular, Spartacus implémente une UI headless qui s'intègre out of the box avec le système de commerce SAP en tant que storefront. Dans ce contexte, le terme headless signifie que SAP Commerce et SAP Spartacus sont des applications indépendantes et autonomes, la responsabilité de la livraison du contenu incombant au système SAP Commerce, tandis que le storefront de Spartacus met en œuvre la conception et l'interaction.

Contrairement aux fronts d'attaque traditionnels, qui sont généralement des pages de serveur Java (JSP), l'application à page unique (SPA) dissocie le front-end du back-end. Cela permet de gérer et d'exécuter les cycles de développement indépendamment les uns des autres et de séparer les bases de code. La communication entre les applications se fait exclusivement via des API basées sur le web. En standard, Spartacus fournit toutes les fonctions attendues d'une boutique en ligne, dont la page d'accueil, la page de détail du produit, le panier d'achat et le check-out, entre autres. 

Le développement d'une interface de magasin configurateur commence par le choix de la technologie appropriée. Pour créer la transparence dans les bases de décision pour une technologie pour la mise en œuvre du front de magasin individuel, une comparaison des alternatives de décision aide. Les fronts de magasin accélérateurs classiques sont annotés comme obsolètes dans les versions actuelles de SAP Commerce et doivent être entièrement supprimés du système au deuxième trimestre 2024. SAP justifie cette décision par les avantages du découplage du front-end et du back-end. Suite à cette décision de la part de SAP, le redéveloppement d'un Accelerator Storefront traditionnel ne représente plus une option du point de vue actuel.

Les alternatives restantes sont le développement individuel d'une façade de magasin à partir de zéro et l'utilisation des fonctionnalités prédéfinies du framework Spartacus. 

Spartacus offre out of the box un front de magasin exécutable, dont la personnalisation est basée sur les concepts de configurabilité et d'adaptabilité. Les configurations modifient le comportement de Spartacus, par exemple l'adresse du backend à connecter, l'authentification et la présentation. Pour favoriser l'adaptabilité, la base de code de Spartacus est également explicitement conçue pour réutiliser et adapter les éléments de code sur la base des concepts d'injection de dépendance du framework SPA Angular. Grâce à la mise en œuvre du projet Spartacus par SAP Commerce Cloud, les projets de développement basés sur Spartacus bénéficient d'une expertise technique approfondie dans l'environnement commercial.

De plus, Spartacus met en œuvre une gestion évolutive de l'état du front-end. Le développement en interne de ces composants de base dans le cadre d'un projet individuel retarde le déploiement du premier front de magasin entièrement opérationnel et augmente sensiblement les coûts de maintenance et de développement. Les critères de qualité classiques du développement logiciel relèvent en outre de la responsabilité de l'équipe de développement. D'autre part, dans le cadre d'un projet individuel, l'équipe de développement est indépendante sur le plan technologique et a la responsabilité de chaque décision et de l'implémentation de la logique.

Concepts transversaux

Tant le système SAP Commerce que SAP Spartacus tirent parti du modèle de conception logicielle Façade. Une façade constitue une couche d'abstraction sur une ou plusieurs sources de données pour préparer les données dans un but précis. Le SAP Commerce met en œuvre une Configuration Facade rudimentaire dans le backend afin d'obtenir les données de configuration, de les agréger et de les préparer pour une utilisation dans un front office de configuration. Comme les fonctionnalités rudimentaires ne sont que très rarement suffisantes pour répondre aux besoins de configuration individuels, les développeurs doivent être en mesure d'ajouter des fonctionnalités spécifiques à cette façade. La base technologique pour le développement dans SAP Commerce est le framework Java-Spring-webmvc. 

SAP Spartacus utilise également le modèle de conception Façade dans le frontend pour préparer les données obtenues du backend à l'utilisation dans le web frontend. Pour personnaliser cette fonctionnalité, il faut savoir utiliser l'injection de dépendances Angular et les jetons d'injection qui lui sont inhérents. Sur la base des jetons d'injection, les composants peuvent être échangés et étendus afin de créer une expérience utilisateur personnalisée. SAP Commerce et SAP Spartacus utilisent également le concept OCC (Omnichannel Commerce). L'OCC poursuit l'objectif d'une expérience client sans faille à travers tous les points de contact du client avec l'entreprise, indépendamment du moyen de communication utilisé.

D'un point de vue technique, OCC dans SAP Commerce signifie l'interface de mise à disposition des données préparées dans la façade sur la base de services web. SAP Spartacus reprend ce concept et récupère les données dans sa couche OCC avant de les transmettre à la façade. Tant les façades que l'OCC sont des bases élémentaires pour pouvoir développer un front de magasin robuste, évolutif et maintenable.

Compétences SAP Commerce

La possibilité de personnaliser le système SAP Commerce repose également sur les configurations et l'extension de la base de code préétablie. À des fins de configuration, le système SAP Commerce est livré avec le moteur propriétaire ImpEx (importation et exportation). Grâce à la syntaxe tabulaire des scripts ImpEx, il est possible d'apporter des modifications faciles à comprendre et reproductibles au comportement du SAP Commerce. Les personnalisations de la destination et de la mise en page en sont un exemple. Ce que l'on appelle les "destinations utilisées" (en anglais "Consumed Destinations") permettent l'intégration dans d'autres systèmes back-end. En appliquant un script ImpEx correspondant, la destination utilisée peut être redirigée vers le moteur spécifique au client avec des informations d'authentification spécifiques. La mise en page peut en outre être adaptée en ce qui concerne les conteneurs à afficher dans le frontend, qu'un storefront utilise ensuite pour afficher les contenus correspondants.

Pour préparer les données, le SAP Commerce utilise les concepts de populator et de mapper en combinaison avec les façades. Un populator est responsable de la conversion des données en un objet existant. Plusieurs populateurs peuvent être connectés les uns derrière les autres afin de représenter une transformation globale des données. Les mappeurs sont responsables, au sein des populateurs, de la génération d'un nouvel objet de données à partir d'un autre type de données. Ensemble, les populateurs et les mappeurs forment la transformation de données qui fournit l'input pour la façade.

L'utilisation systématique de ce type de transformation des données a un effet nettement positif sur les critères de qualité du code écrit. Le concept de gestion des données est au cœur du front de stockage de Spartacus : il se compose de l'implémentation de la gestion d'état avec NgRx (Redux), de l'utilisation systématique des observables ainsi que des concepts de normalisation et de sérialisation. La combinaison de ces éléments rend le front de stockage centré sur les données et réactif. NgRx est une implémentation Angular open source du framework Redux. L'état des données stockées dans NgRx est communiqué exclusivement via des observables, ce qui permet à l'IU de réagir en permanence aux modifications des données. 

Kit de compétences Spartacus 

La normalisation désigne le processus de transformation des données du back-end Commerce dans la façade Spartacus afin de les préparer pour l'affichage. Toutes les données entrantes passent par des normaliseurs dédiés. Inversement, toutes les données modifiées par l'interaction de l'utilisateur circulent de la façade Spartacus vers le backend Commerce par l'intermédiaire de sérialiseurs, qui sont responsables de la transformation des données en retour vers le modèle OCC.

Conclusion

CCP et SAP Spartacus offrent une interface de configuration prête à l'emploi qui s'intègre parfaitement avec les configurateurs SAP existants. Si une expérience client individuelle doit être représentée avec les deux systèmes, les entreprises ne peuvent toutefois pas éviter d'adapter la logique existante. Pour cela, il faut une expertise dans le backend, c'est-à-dire Java Spring webmvc, ainsi que dans le frontend, c'est-à-dire Angular. Bien que l'affichage des configurateurs réagisse de manière adaptative aux données du backend, les entreprises atteindront rapidement leurs limites avec l'implémentation standard dans les deux systèmes. Il est possible de développer son propre front de magasin à partir de zéro, mais cela comporte des risques très différents. Pour les maîtriser, il faut que l'équipe de développement dispose d'un savoir-faire approfondi dans différents domaines de l'ingénierie logicielle.