Introduction
Contrairement à la majorité des modules de SAP qui utilisent des idocs pour permettre l’interfaçage des objets, SAP Transportation Management s’appuie majoritairement sur des échanges de fichiers XML asynchrones à travers le protocole standard SOAP (Simple Object Access Protocol).
Nous distinguons 2 typologies d’interfaces SOAP:
- Les services consumers: SAP va générer un fichier XML pour l’envoyer à une adresse (=endpoint), ils sont suffixés par *Out dans leurs noms
- Les services providers: SAP va générer un endpoint pour permettre à des fichiers XML de s’y intégrer ils sont suffixés par *In dans leurs noms
Chaque objet dans SAP TM est livré avec son lot de webservices comme présenté de manière non exhaustive sur le schéma suivant à travers l’objet Freight Order (= Mission de transport):
Paysage Applicatif simplifié
Si en revanche vous souhaitez vous intégrer avec système legacy (= un éditeur autre que SAP), il est hautement recommandé dans la majorité des cas de passer par un middleware. Je reviendrai sûrement plus tard sur le rôle et les possibilités du middleware, mais pour le moment disons simplement que c’est un traducteur de messages permettant de faire communiquer 2 systèmes ne parlant pas le même langage que ça soit dans la grammaire (=structure du message) ou dans le vocabulaire (=transcodification).
Voici donc le même schéma mis à jour avec cette nuance:
Paysage Application cible
Trêve de « théorie » passons à la pratique de simulation d’un service provider. Pour simuler ces interfaces, j’aime m’appuyer sur le logiciel SOAP UI qui a défaut d’être ergonomique, est simple et efficace pour tester et construire mes maquettes.
Dans un premier temps, nous devons générer le endpoint du service choisi de notre objet. Voici le scénario choisi:
Une entreprise travaillant sur SAP TM a répliqué ses besoins de transports (=Freight Units) vers un 3PL à travers un service consumer standard. Ce 3PL réalise la planification du transport pour le compte du donneur d’ordre pour créer dans SAP TM la mission de transport (=Freight Order) à travers un service provider et contenant:
- Le transporteur
- Le transporteur sous-traitant
- Le moyen de transport
- Les dates & heures de (dé)chargements
- Les assignation des UF dans l’OF
- La référence de la mission de transport du 3PL
- Etc.
Rendez-vous dans la transaction SOAMANAGER pour créer le endpoint sur le service TransportationOrderGenericRequest_In. Pour simplifier l’exercice, je sollicite une authentification basic (=basée sur mon user & mot de passe) mais il est recommandé de fonctionner par certificats dans un environnement de production pour sécuriser les échanges.
Transaction SOAMANAGER – Création Manuelle d’un Service
Transaction SOAMANAGER – WSDL généré
Une fois le service généré, deux endpoints sont générés:
- Le endpoint du service que nous avons décrit plus haut
- Le endpoint du WSDL (=Web Services Description Language) sur lequel on va s’appuyer pour répliquer très simplement la structure attendue par SAP dans SOAP UI
De manière transparente, un service sera crée dans la transaction SICF:
Transaction SICF – Génération du service
Une fois le endpoint renseigné dans SOAP UI, la structure du message est généré, il ne nous reste plus qu’à y assigner nos informations:
SOAP UI – Récupération des informations du service de SAP
Avant de processer notre message, regardons la situation de notre Freight Unit. On peut voir que son étape de transport est au statut « non planifié »:
Freight Unit non planifiée
Processons maintenant le message. Il est essentiel d’avoir un code retour égal à 200 indiquant que tout s’est bien déroulé. Un code retour de type 400 ou 500 indiquent des typologies d’erreurs très disparates pouvant:
- Que SAP a rejeté la connexion (si les informations d’authentification sont fausses par exemple)
- Que le endpoint n’existe pas
- Que l’adresse est introuvable
- Etc.
SOAP UI – Processing message XML
Il est possible d’avoir un code retour égal à 200 mais de trouver une erreur dans SAP dans la transaction SRT_UTIL qui nous indique les erreurs fonctionnelles. Le message pourra au besoin être relancé manuellement ou automatiquement par un programme batché.
Dans notre cas, tout s’est déroulé correctement, notre étape d’Unité de Fret est dorénavant planifiée et le Freight Order a correctement crée avec les informations que l’on souhaitait:
Freight Unit planifiée
Freight Ordre créé
En espérant que ces quelques lignes vous aient appris quelque chose ou sensibilisé à l’architecture SOA. N’hésitez pas à me contacter sur mon adresse email au besoin.