Altova MapForce 2025 Enterprise Edition

Ce chapitre explique comment gérer les erreurs HTTP dans un mappage qui appelle une HTTP API. Si vous voulez gérer les erreurs HTTP (par ex., Not Found, Unauthorized), vous devez définir un nœud de corps correspondant dans la partie de réponse de l’appel du service Web (voir les détails ci-dessous). Autrement, les erreurs HTTP termineront toujours l’exécution du mappage.

Mise en place de l’appel du service Web

Dans le mappage échantillon affiché di-dessous, un fichier CSV dénommé products.csv fournit les ID de produits dans la partie Request de l’appel du service Web. Lorsque qu’un service Web est appelé, la réponse contenant les détails extraits est mappée vers un fichier XML dénommé output.xml.

Si les produits avec des ID fournies existent sur le serveur, leurs détails seront mappés depuis le corps avec le code de statut 200 (succès). S’il n’existe pas de produits avec de telles ID sur le serveur, l’appel du service Web retournera le code de statut 404 (pas trouvé), et la réponse depuis le corps sera mappée depuis le corps avec le code de statut 404 vers le nœud ErrorMessage dans la sortie.

Structures et corps de réponse

Afin de gérer les différentes réponses HTTP du service Web dans le même mappage, vous pouvez créer de multiples items Body comme suit : Cliquez avec la touche de droite sur l’item Body dans le composant du service Web et sélectionnez Ajouter Nœud Corps Avant/Après depuis le menu contextuel. Dans notre exemple, il existe deux corps, chacun gérant un type particulier de réponse HTTP : le corps avec le code de statut 200 gère les réponses réussies, et le corps avec le code de statut 404 gère les erreurs Not Found.

Chacun des items de réponse Body peut être configuré par le biais des touches respectives . Lorsque vous cliquez sur cette touche, le dialogue Structure de réponse s’ouvre (capture d’écran ci-dessous). Les deux corps ont des structures de réponse dans le format XML. Les corps peuvent aussi accepter le contenu d’autres types (par ex., JSON).

Body status=200

Body status=404

Ordre de traitement

Cette sous-section explique comment le mappage traite la requête et sort la réponse dans le document cible.

Contexte cible commun

Selon une des règles fondamentales dans MapForce, le traitement commence toujours par le nœud racine cible et progresse en descendant dans la hiérarchie. Dans notre exemple, la racine cible est ProductList. La racine cible n’est pas connectée, donc le traitement continue avec l’élément Product qui est connectée au nœud Response de l’appel du service Web. Avec cette connexion, un contexte cible commun est établi pour tous les descendants du nœud Product. Ceci signifie que les descendants auront accès à leurs données parent, ce qui aidera à éviter des appels qui ne sont pas nécessaires.

Un produit pour chaque réponse

Selon une autre règle fondamentale dans MapForce, pour chaque item de source, un item est créé dans la cible. Dans notre exemple, ceci signifie que pour chaque réponse, un item Product sera créé dans la sortie. En règle générale, en particulier avec de multiples nœuds Body configurés, vous voudrez généralement vous connecter au nœud Response dans un parent commun dans la cible. Ceci évitera d’effectuer trop d’appels.

Traiter la requête/réponse

Lorsque la connexion est tracée depuis le nœud Product au nœud Response, MapForce sait qu’il doit effectuer un appel de service Web, mais d’abord, il a besoin d’une requête. Puis, la partie requête est traitée. Le paramètre id accepte les valeurs du nœud ProductID du fichier source CSV.

Le fichier CSV contient une séquence de valeurs que nous tentons de mapper au paramètre qui prévoit uniquement une valeur. Dans ce cas, le service Web function sera appelé de nombreuses fois et produit de autant de résultats qu’il y a d’items dans le séquence. Ceci signifie que s’il existe 5 ID produits, un appel sera effectué pour chaque ID.

Lorsque la connexion du nœud id est tracée dans le nœud ProductID, MapForce met en vigueur son parent, le nœud Rows, dans le contexte et les boucles par le biais de chaque ligne (ProductID). Pour chaque ligne, une requête sera établie vers le serveur. MapForce obtiendra ensuite une réponse du serveur et créera un item Product qui a la même ID que celle envoyée à la requête.

Notez que le nœud ProductID dans la cible obtient des données non de la structure Response, mais directement depuis le fichier source CSV. La raison étant que nous voulons obtenir une réponse de chaque ID produit ou qui n’existe éventuellement pas sur le serveur.

Corps

Les corps sont traités du haut vers le bas. Le premier corps qui correspond à la réponse est traité en premier. Ensuite, MapForce se déplace vers le bas de l’arborescence. Si aucun des corps ne correspond, MapForce jettera une exception, et l’exécution du mappage s’arrêtera.

Si un produit avec l’ID fournie par le fichier CSV existe sur le serveur, l’élément Product sera peuplé avec les données du corps avec le code de statut 200. S’il n’existe pas de produit avec une telle ID sur le serveur, le deuxième corps avec le code de statut 404 sera traité, et l’élément Product n’obtiendra que l’ID produit et un message d’erreur.

Sortie

Ci-dessous, vous trouverez la sortie qui affiche les détails des produits avec les ID 1, 5, et 7 qui ont été extraites avec succès. Le produit avec l’ID 6 n’a pas été trouvé, pour cette raison, le corps avec le code de statut 404 a été traité, et la valeur du nœud Message a été mappée dans le nœud ErrorMessage de la cible.