La première version de SAP CPQ (Configure-Price-Quote) est sortie il y a vingt ans et depuis, l’application a été réinventée à plusieurs reprises. Techniquement, cela signifie que de nombreuses technologies d’intégration différentes ont alimenté la boîte à outils que vous pouvez utiliser pour vous connecter à SAP CPQ.
Par exemple, l’application offre plusieurs types et variétés d’API (interfaces de programmation), et il est difficile d’identifier l’option qui correspond le mieux aux exigences de votre projet.
Nous allons tenter de vous donner un résumé succinct, mais complet des différents connecteurs SAP CPQ avec leurs avantages et leurs inconvénients. Ainsi, vous disposerez d’un document d’une page, directement applicable au développement de votre intégration SAP CPQ.
API SOAP
De quoi s’agit-il ?
Il s’agit de la première interface web exposée par SAP CPQ. Elle a été développée pour être utilisée dans le paradigme standard SOAP (Simple Object Access Protocol).
Chaque méthode requiert le nom d’utilisateur et le mot de passe de l’exécuteur de l’action comme paramètres dans l’enveloppe SOAP, et presque toutes ont un seul paramètre XML principal dans lequel vous devez inclure toutes les données d’entrée.
Les pages d’aide SAP vous fourniront généralement un schéma XML (eXtensible Markup Language) d’entrée et de sortie, une liste d’exemples d’entrée et de sortie et une brève description du flux d’exécution.
Quand les utiliser ?
Les API doivent être utilisées si vous avez le temps de développer des appels de SOAP. Ainsi, vous pourrez vous appuyer sur les contrôles de validation et les mesures de sécurité appliquées par SOAP.
Un autre avantage de ces API est qu’elles exécutent des opérations de niveau macro, ce qui signifie que pour la majorité des tâches standard, vous aurez besoin d’un seul appel d’API.
Quelques inconvénients
Les API vous imposent de travailler avec de grands schémas d’entrée XML et de fournir des valeurs pour plusieurs champs (pour les champs obligatoires, mais aussi pour les champs sans lesquels vos objets contiendraient des données commerciales incorrectes). Par exemple : disons que vous utilisez une méthode web qui crée un nouveau devis, mais que l’attention de l’utilisateur est centrée sur un seul élément de ce processus. Les devis sont l’objet le plus important de SAP CPQ et le parent de tous les objets utilisés pendant le processus d’établissement d’un devis - l’utilisateur devrait fournir de nombreuses données qu’il pourrait ignorer du point de vue de sa tâche actuelle. Les API REST atomiques pourraient être un meilleur choix pour des opérations ponctuelles.
API REST
De quoi s’agit-il ?
Parallèlement au changement de paradigme global de SOAP à REST, la couche d’interface utilisateur SAP CPQ a évolué pour être entièrement remplacée afin que l’application profite d’une interface utilisateur réactive.
D’autres réimplémentations ont également été réalisées et certaines sont encore en cours de développement ou de distribution. Ainsi est sortie, par exemple, la version 2 du moteur dans laquelle les pages d’administration recourent à des technologies plus récentes.
Presque toutes les API REST requièrent un appel d’authentification préalable pour obtenir un token et exigent que celui-ci soit transmis pour tous les appels suivants. Vous trouverez ici plus d’informations sur l’authentification dans le cadre de nos API REST, mais en substance, comme l’application utilise elle-même les mêmes API, vous devrez établir et gérer une session SAP CPQ de manière équivalente, ou transmettre un token sans ouverture automatique de session entre les appels.
Pourquoi les utiliser ?
Les API REST se distinguent surtout par leur granularité - cela signifie qu’un seul appel d’API exécute une seule opération atomique correspondant approximativement à un seul clic dans SAP CPQ.
Si, par exemple, vous créez un seul produit configurable dans le paramétrage, vous serez en mesure de suivre les appels d’API qui s’exécutent pour chaque clic effectué dans l’assistant de configuration produit. Vous devrez établir une chaîne de tous ces appels de méthode web pour créer un produit par programmation à l’aide de REST. Avec SOAP, il n’y aurait qu’un seul appel d’API.
Vous pourriez vous demander en quoi cela constituerait un avantage pour les API REST. La réponse est que les API n’ont pas été développées dans cette optique - elles ont été exposées pour vous permettre d’exécuter rapidement un changement ponctuel dans SAP CPQ. Si, par exemple, vous devez mettre à jour une étiquette d’attribut dans un produit, il vous faudra un appel pour vous authentifier et un autre appel court pour mettre à jour les données d’attribut.
Avec les API SOAP, vous devrez fournir des valeurs pour tous les champs de produit (ce qui peut représenter beaucoup pour une hiérarchie) et veiller à ne rien écraser avec des données incorrectes.
De plus, avec REST, vous pouvez effectuer de nombreuses opérations qui ne sont tout simplement pas prises en charge avec le schéma SOAP fixe d’origine : l’API SOAP de création de produit vous permet de créer des produits simples et offre une prise en charge limitée pour les produits configurables, tandis qu’avec REST, vous pouvez faire tout ce que l’application elle-même est capable de faire - dans notre exemple, la création de systèmes de produits.
Ainsi, les API permettent d’exécuter un nombre impressionnant d’opérations tout en ne nécessitant que peu de développement pour établir des appels de REST.
Existe-t-il des inconvénients ?
Les inconvénients pourraient être l’effort important que nécessite l’exécution des opérations de niveau macro et le support supplémentaire requis pour celles-ci (p. ex. : annulation de toutes les opérations réussies pour supprimer des données partielles si un appel d’API échoue au milieu d’une séquence). De plus, il est difficile pour les personnes externes de comprendre la sémantique de certaines propriétés JSON, car Swagger se concentre uniquement sur les types de données (d’autant que certaines propriétés sont des identifiants de base de données) de sorte qu’une assistance des consultants SAP est requise dans certains cas.
Les différents types d’API
Intéressons-nous maintenant de plus près aux différents types d’API. Les explications ci-dessous sont un peu techniques.
API pour les opérations des utilisateurs finaux
Lorsque le design réactif a été introduit pour toutes les pages des utilisateurs finaux dans l’application, l’ensemble de l’interface utilisateur a bien entendu été recodé. Ainsi, pour chaque opération exécutée dans l’interface utilisateur, une autre API a été exposée afin de prendre en charge l’opération en question, toutes les API étant immédiatement disponibles pour un usage public.
Vous devez vous authentifier en appelant la méthode /api/rd/v1/Core/LogIn dans un premier temps, puis transmettre le token header CSRF(Cross-site Request Forgery) obtenu et les cookies ASP.NET_SessionId et WebCom-lbal pour tous les appels web suivants. Vous devez imiter le comportement de l’application SAP CPQ et communiquer avec le serveur comme le fait l’application elle-même depuis un navigateur client.
API d’administration
Les pages de configuration de SAP CPQ ont été remodelées à plusieurs reprises, mais la dernière réimplémentation comprend la migration progressive des pages de configuration vers un cadre Angular. Parallèlement à la transition vers une technologie de nouvelle génération, l’objectif de SAP est d’améliorer le temps de réponse des pages.
Seuls quelques modules ont été migrés jusqu’à présent, dont les principaux (produits, attributs, utilisateurs et quelques autres). Vous pouvez reconnaître les pages de configuration migrées au setupSpa contenu dans l’URL.
Ici aussi, l’avantage est que toutes les nouvelles API ont été immédiatement mises à disposition pour un usage externe.
Un appel /basic/api/token API doit d’abord être effectué aux fins d’authentification, puis il faut transmettre le bearer token OAuth 2.0 obtenu à chaque appel web suivant. Les instructions se trouvent sur la page d’aide mentionnée concernant l’autorisation.
Les méthodes web pour les déploiements de script constituent un autre ensemble important d’API appartenant à ce groupe, mais elles sont indépendantes du travail de réimplémentation effectué sur la configuration.
API utilisant un JWT
Les besoins opérationnels de certaines API nécessitaient l’utilisation d'un token web JSON pour l’authentification, afin de respecter une architecture de niveau supérieur.
Pour utiliser un token, vous devez définir Shared Secret dans les pages de l’application, faire appel à un service public pour générer un token JWT et le transmettre à chaque appel suivant.
API pour devis 2.0
Avec l’introduction du nouveau moteur de création de devis, des API fonctionnant uniquement pour cette version de moteur ont été exposées.
Ici, vous devez utiliser l’authentification de base, ce qui permet à SAP d’exécuter un nombre très diversifié de méthodes d’authentification que le CPQ prend en charge.
API REST à usage spécial
Plusieurs API REST n'appartenant pas aux groupes ci-dessus sont exposées pour couvrir certaines tâches isolées.
Deux exemples : la méthode web de téléchargement de fichiers de contenu (prend en charge plusieurs types d’authentification) et l’API SCIM (System for Cross-domain Identity Management) (pour la maintenance utilisateur conforme à la spécification, qui utilise également le bearer token aux fins d’authentification).
Exposition d’une API personnalisée
La possibilité d’exposer en quelques clics une API REST personnalisée avec n’importe quelle logique de fond est l’une des intégrations de CPQ les plus populaires. En d’autres termes, chaque script Python global est automatiquement exposé en tant qu’API externe et vous pouvez l’invoquer sur l’URL suivante : http://yourCPQ environment/customapi/executescript?scriptname=yourScriptName.
Vous convertissez votre script en une API complète en attribuant une valeur de résultat à la variable d’environnement ApiResponse. Vous pouvez également définir le script (et par conséquent l’API elle-même) pour obtenir les valeurs des paramètres d’entrée.
Souscription à des événements
Les API ci-dessus sont des mécanismes qui vous permettent de déclencher une action côté CPQ. Mais le déclenchement d’une action peut également être invoqué dans le sens contraire, si vous souscrivez à un événement de domaine SAP CPQ.
Vous effectuez la configuration en choisissant un événement, en saisissant une URL webhook (que notre moteur appellera lorsque l’événement se produit) et en entrant les paramètres d’appel (comme les données d’authentification).
Le CPQ publie actuellement un événement lorsqu’un produit est ajouté, mis à jour ou supprimé ou lorsqu’une commande est passée, mais à l’avenir, la liste des événements sera alimentée par SAP.
SAP CPQ comme partie intégrante de l’entreprise intelligente
Comme SAP CPQ, à l’instar de tous les logiciels CX, appartient à l’architecture SAP, il existe des flux d’intégration tout prêts dans le hub des API SAP qui relient différents composants des solutions d’expérience client ou S/4HANA à SAP CPQ. Il n’est pas nécessaire de recréer le contenu de l’intégration, il suffit de réutiliser les packages sur votre propre instance de capacité d’intégration dans le cloud au sein de la SAP Integration Suite.
Vous pouvez exploiter davantage les potentiels de la SAP Integration Suite et, par exemple, inclure SAP API Management dans votre architecture système pour transférer automatiquement les tokens CSRF entre les appels, au lieu de tout coder manuellement.
Conclusion
Il existe plusieurs moyens de procéder à l’intégration à SAP CPQ et il est assez difficile de différencier leurs spécificités à tous, surtout si vous découvrez SAP CPQ.
Le présent article vous donne un aperçu condensé de toutes les options énumérées, ainsi que des avantages et inconvénients et des principaux cas d’utilisation pour chaque option.
Nous voulons vous faire profiter des informations les plus pertinentes concernant le CPQ. Vous souhaitez en savoir plus ou découvrir comment nos experts peuvent vous aider à implémenter et à connecter le CPQ ? Contactez-nous !
Comments