SnapMSV3service : le développement de produits dans le cloud en pratique

Le bon fonctionnement d'une infrastructure informatique dépend en grande partie d'interfaces appropriées. C'est aussi et surtout le cas dans l'environnement SAP. Il est donc d'autant plus étonnant que la communauté SAP se consacre certes abondamment à la transition vers la nouvelle version S/4-Hana de la composante SAP Core, mais qu'elle n'aborde guère les adaptations absolument nécessaires dans le domaine de l'intégration. Pourtant, le passage au cloud pose des problèmes totalement nouveaux, notamment au niveau des interfaces, qui exigent des approches radicalement différentes.

Intégration signifie adaptation

Des adaptations, il y en a eu chez SAP dès le début, comme le montre un regard en arrière : lancé sur le marché en 1992, SAP R/3 était déjà un système assez ouvert, pour lequel il était facile de programmer des interfaces avec les technologies classiques - RFC, ALE, BAPI et IDOC. Au fil des années, SAP n'a cessé de se réinventer et de se moderniser, notamment dans le domaine de l'intégration. Si dans le passé, il s'agissait de l'ouverture aux protocoles Internet standardisés ou de l'introduction de concepts (et de produits) de middleware, aujourd'hui, en tant qu'utilisateurs SAP, nous sommes de plus en plus confrontés - notamment dans l'environnement cloud - à de nouveaux concepts tels que l'API-First et la communication basée sur des événements.

Et puis le cloud est arrivé

De nombreux clients n'ont pas suivi cette évolution et leurs concepts d'interface en sont toujours à l'ère BAPI/IDOC/RFC. Le passage au cloud (public) n'est toutefois pas possible, car les dernières années ont vu l'émergence d'exigences et de concepts entièrement nouveaux - et ce avec force. De plus en plus d'éléments des processus commerciaux classiques migrent vers le cloud, parfois même le backend SAP lui-même. Mais comme pratiquement aucune entreprise ne reproduit pour la première fois ses processus uniquement dans le cloud, on assiste à l'émergence d'environnements informatiques hybrides composés d'installations dans le cloud et sur site, ce qui soulève de nombreuses nouvelles questions en termes d'interfaces et de connectivité.

S'y ajoutent des approches technologiques telles que API First ou la communication basée sur des événements, qui, tout comme la nouvelle technologie d'interface stratégique Fiori, augmentent le besoin d'intégration. Et presque sur le dessus, il y a la sécurité, un thème transversal extrêmement important pour pouvoir mettre en œuvre des exigences concrètes de manière techniquement propre et conforme aux directives de conformité.

De nombreux professionnels SAP et programmeurs chevronnés sont justement focalisés sur l'"ancien monde Abap" en raison de leur longue expérience, nous le constatons par nous-mêmes. En ce qui concerne les interfaces, ils ont appris à aimer et à maîtriser les concepts de BAPI ou d'IDOC.

Toutefois, selon le concept Clean Core, ces technologies familières ne sont définitivement plus le premier choix. De plus, elles ne sont plus disponibles sur les instances SAP Public Cloud. Elles doivent être remplacées par de nouvelles technologies modernes telles que les API oData ou SOAP. Mais sont-elles vraiment équivalentes ? Ou est-il nécessaire de repenser entièrement les interfaces ?

Contrôle pratique

Pour trouver des réponses à ces nombreuses questions, nous nous sommes penchés sur le sujet avec une application pratique concrète. En tant que développeurs de logiciels dans l'environnement SAP, nous avons toujours le "nez dans le guidon" pour identifier les points noirs de nos clients et leur proposer des solutions. C'est le cas de notre dernier produit : SnapMSV3service est un processus de disponibilité de la livraison et de commande pour les pharmacies hospitalières intégré dans SAP BTP et basé sur le protocole industriel MSV3. Notre produit aide les hôpitaux à identifier rapidement les pénuries de médicaments et à y réagir.

Au départ, il s'agissait de soutenir les pharmacies hospitalières dans le processus d'approvisionnement en médicaments. Avant même le processus de commande, il fallait déterminer si un médicament était disponible chez un fournisseur pharmaceutique donné et, dans le cas contraire, si des produits alternatifs ou d'autres sources d'approvisionnement entraient en ligne de compte.

Pour ce faire, les bases de données pharmaceutiques devaient être intégrées dans le processus numérique de consultation et de commande vis-à-vis des fournisseurs de produits pharmaceutiques. La solution devait en outre être profondément intégrée aux processus standard SAP et répondre aux exigences du RGPD en matière de protection des données. Jusqu'à présent, cette exigence a été résolue de différentes manières : sous forme de processus analogiques, avec des systèmes d'information de marque maison, avec une connexion directe MSV3 aux fournisseurs concernés ou avec le module snap GHT APM, une solution sur site basée sur une interface utilisateur graphique.

Après les recherches nécessaires, il est rapidement apparu que la solution devait être une application cloud, notamment en raison de trois avantages clés : Une base de données unique et toujours à jour pour tous les clients, une connectivité centralisée avec tous les fabricants et fournisseurs de médicaments grâce au protocole MSV3 et l'extensibilité aux clients non-SAP. Nos ensembles de compétences existants en termes de technique et de processus, ainsi que la "cloud capability" de l'exigence prévue, nous ont confortés dans le choix de réaliser la solution sur la BTP. L'indépendance que nous pouvions atteindre, tant par rapport aux versions SAP que par rapport aux processus SAP spécifiques de gestion du matériel des clients potentiels, a également été déterminante.

Bonnes solutions, coûts modérés

Bien entendu, nous avons également examiné les coûts avant de lancer le projet. Les moteurs les plus importants sont les solutions BTP nécessaires (= "services"). En d'autres termes, quel environnement d'exécution est souhaité (Cloud Foundry/Kyma ou BTP Abap) et quelle base de données est possible avec celui-ci ? BTP Abap n'est justement disponible qu'en combinaison avec une Hana DB, d'autres runtimes permettent également PostgreSQL ou d'autres bases de données. De plus, certains "services de base" sont toujours nécessaires, comme le Business Application Studio en tant qu'environnement de développement ou les Identity Services pour la gestion des utilisateurs. Et bien sûr, comme nous l'avons mentionné au début, l'intégration est un thème essentiel. Pour snapMSV3service, nous avons opté pour la solution standard SAP Integration Suite avec le produit middleware Cloud Integration dans l'édition Basic. Notre apprentissage : il est déjà possible de construire de bonnes solutions sur la BTP à des coûts relativement faibles. Il faut toutefois se familiariser avec le catalogue de services et les différentes métriques des services nécessaires - et l'architecture souhaitée doit être claire très tôt.

Processus séparé intégrable

La "cloud capability" de notre solution, définie précédemment, repose sur le fait qu'il s'agit d'un processus bien distinct (de SAP Core) et intégrable à SAP Core. Ce processus comprend trois niveaux ou systèmes : le backend SAP, le portail lui-même - c'est-à-dire l'application snapMSV3service - et le côté fournisseur de MSV3. Le composant clé pour la communication entre ces trois niveaux est SAP Cloud Integration (SAP CI) qui, via SAP Cloud Connector, établit la connexion sécurisée entre le réseau local du client (en cas d'utilisation sur site) ou l'instance S/4 Hana Cloud du client et notre instance SAP BTP. Les besoins sont générés dans le backend SAP du client X et transmis au portail. Là, un utilisateur du portail du client traite ces besoins - il effectue des contrôles de disponibilité par rapport aux fournisseurs MSV3 et réagit à leurs retours. Le processus de commande commence alors avec une particularité essentielle : un numéro de commande correspondant doit être créé dans SAP avant que la commande ne soit effectivement passée auprès du fournisseur MSV3, afin que celui-ci puisse être transmis comme référence lors de la commande MSV3.

Nouvelles API : similaires, pas identiques

Ce processus appelé "créer/modifier une commande mémorisée dans le backend SAP du client" (et recevoir immédiatement en retour le numéro de commande correspondant - nous parlons donc d'une interface strictement synchrone) montre de manière exemplaire à quel point le "nouveau" monde du cloud diffère de l'"ancien" monde sur site. Jusqu'à présent, on obtenait le résultat souhaité avec les appels BAPI_PO_CREATE1 et BAPI_PO_CHANGE, qui s'expliquent d'eux-mêmes pour de nombreux "vieux briscards d'Abap". Dans le "nouveau" monde du cloud, on a besoin pour cela des API oData (version 4) et les tâches souhaitées sont exécutées avec leur Service-ID "API_PURCHASEORDER_2" (Post ou Patch, si l'on souhaite munir certains postes d'une mention de suppression, alors également Delete).

Non seulement la fonction initiale habituelle n'est plus disponible, mais la syntaxe et la fonction sont également totalement différentes. Pour trouver la fonctionnalité souhaitée, le Business Accelerator Hub (api.sap.com) offre certes une bonne première approche (également directement avec des exemples et la possibilité de tester). Mais dans le détail, il manque des informations - par exemple, ce que fait telle ou telle propriété ou quelle valeur doit être définie pour une fonctionnalité donnée. Ce que font les nouvelles API est donc similaire, mais loin d'être identique à ce que l'on connaît.

Facteurs de succès pour le cloud

D'après notre expérience avec le snapMSV3service, les facteurs clés suivants peuvent être résumés pour des solutions cloud réussies : Le processus prévu doit être "compatible avec le cloud", c'est-à-dire qu'il doit pouvoir être séparé de SAP Core et intégré à SAP Core. La question de l'intégration doit être réglée le plus tôt possible. L'ensemble des compétences des architectes doit être adéquat et l'architecture doit être fixée suffisamment tôt.

Pour comprendre les nouvelles interfaces cloud, il faut en outre disposer de connaissances spécialisées - par exemple sur SAP Integration Suite - qu'il convient d'acquérir au plus vite.

Pour réaliser des solutions réellement économiques, il est nécessaire de connaître les services BTP et leurs métriques de licence. Et il est définitivement intéressant de se familiariser avec les nouvelles API techniques pour réaliser des tâches professionnelles concrètes. Et il vaut mieux le faire tôt que tard.

snapconsult.com

Vers l'inscription du partenaire :