Extensibilité side-by-side

Une extension side-by-side est une application distincte qui traite SAP S/4HANA comme un système avec lequel elle communique, et non comme du code qu'elle modifie :

1. L'extension est construite et déployée sur SAP BTP, dans le runtime et le langage adaptés au cas d'usage : ABAP dans l'environnement SAP BTP ABAP, ou Java et Node.js, par exemple avec CAP.
2. Elle lit et modifie les données SAP S/4HANA uniquement au travers d'API distantes libérées, que SAP documente sur le SAP Business Accelerator Hub.
3. Elle peut réagir aux business events publiés par SAP S/4HANA, ce qui lui évite d'interroger le système à intervalles réguliers pour détecter les changements.
4. La connectivité et la confiance sont configurées entre SAP BTP et l'ERP : destinations, plus SAP Cloud Connector pour les systèmes on-premise.
5. L'extension a son propre cycle de vie. Elle est déployée, dimensionnée et mise à jour indépendamment des releases de SAP S/4HANA.

L'extensibilité side-by-side transforme donc une extension en un problème d'intégration doté de sa propre application, plutôt qu'en une modification à l'intérieur de l'ERP.

Les recommandations de SAP en matière d'extension distinguent plusieurs archétypes d'applications side-by-side :

• Applications proxy et de confort, qui simplifient ou remodèlent l'accès à SAP S/4HANA pour un public précis.
• Applications de substitution, qui remplacent une étape standard par une étape spécifique.
• Applications de prétraitement et de post-traitement, qui préparent les données avant qu'elles n'atteignent l'ERP ou agissent sur ce que l'ERP a produit.
• Applications analytiques, qui combinent les données SAP S/4HANA avec d'autres sources.

Les modèles typiques comprennent les applications full-stack pour un seul client, les applications SaaS multitenant construites par des partenaires, les scénarios hub qui relient plusieurs systèmes ERP ou services cloud, les applications mobiles et l'automatisation entre systèmes. Chez Alder Manufacturing, un portail de suivi des livraisons pour les chauffeurs de Bright Freight, qui n'ont pas d'utilisateur SAP S/4HANA, est un cas side-by-side naturel. L'extensibilité side-by-side convient le mieux lorsque l'extension sert de nouveaux utilisateurs, de nouveaux canaux ou plusieurs systèmes.

• Clean core par construction. L'ERP n'est pas modifié, et l'extension ne dépend que d'API et d'événements libérés.
• Cycle de vie indépendant. L'extension peut être livrée chaque semaine tandis que SAP S/4HANA suit son propre calendrier de releases, et les mises à niveau de SAP S/4HANA ne touchent pas à son code.
• Libre choix de la pile. Les équipes peuvent utiliser ABAP, Java ou JavaScript et les services SAP BTP adaptés, de SAP Build Apps à CAP.
• Une portée au-delà des utilisateurs SAP. Partenaires externes, fournisseurs et clients peuvent utiliser l'extension sans compte SAP S/4HANA.
• Périmètre multisystème. Une même application peut combiner SAP S/4HANA avec d'autres systèmes SAP et non-SAP.

Pour les extensions qui ont leur propre public, leurs propres besoins de montée en charge ou leur propre rythme de releases, l'extensibilité side-by-side est l'option que SAP positionne sur SAP BTP.

• Pas de transaction partagée. Un appel distant ne peut pas modifier les données SAP et les données spécifiques dans une même unité de travail : la cohérence doit donc être conçue avec des compensations ou des relances.
• Limitée par les API distantes. Si aucune API ou aucun événement libéré ne couvre l'opération nécessaire, l'extension ne peut pas y accéder proprement ; il faudra peut-être d'abord construire une API ABAP Cloud on-stack.
• Davantage de pièces mobiles. Connectivité, propagation d'identité, supervision et exploitation s'ajoutent pour chaque extension.
• Volume de données et latence. Lire de grandes quantités de données SAP, ou multiplier les appels de faible granularité, est plus lent et plus coûteux qu'un accès on-stack.
• Un second cycle de vie à assumer. Chaque extension a besoin d'un responsable, d'un budget et d'un modèle de support après la mise en production.

L'extensibilité side-by-side garde le cœur propre en déplaçant la complexité dans le paysage qui l'entoure, où elle doit toujours être gérée.

Les recommandations d'architecture d'extension de SAP proposent un test pratique. Caractéristiques qui orientent vers chaque option :

De nombreux besoins nécessitent les deux : un service ABAP Cloud on-stack qui expose une API distante spécifique, et une application side-by-side qui la consomme. La décision se prend besoin par besoin, et le couplage aux données SAP S/4HANA est le critère déterminant.

• SAP S/4HANA Cloud Public Edition : le service SAP S/4HANA Cloud Extensibility sur SAP BTP relie un système enregistré à un subaccount, avec le service plan api-access pour les API et le plan messaging pour les événements ; pour les connexions entrantes, une destination HTTP est générée lors de la création de l'instance de service.
• Private Edition et on-premise : SAP Cloud Connector et les destinations relient SAP BTP au système, et les API OData libérées sont activées sur SAP Gateway ; les événements quittent le système via le composant Enterprise Event Enablement.
• Toutes les éditions : pour les appels exécutés sous l'identité de l'utilisateur connecté, la principal propagation est configurée, avec une authentification unique (single sign-on) via SAP Cloud Identity Services pour la Public Edition et via le Cloud Connector pour la Private Edition et l'on-premise.

Le modèle d'extension est identique d'une édition à l'autre ; seules la connectivité, la configuration des événements et celle de la confiance diffèrent.