Utilisation de l'API Groupon avec MapForce – Partie 2

Dans la première partie de cette série, nous avons décrit comment connecter Altova MapForce à l'API de Groupon. Nous avons interrogé l'API pour obtenir une liste des divisions de Groupon, puis nous avons utilisé cette liste pour créer des requêtes API pour toutes les offres en cours de chaque division. Dans cette partie, nous allons exécuter les requêtes "/deals" et filtrer les résultats pour ne conserver que les données les plus intéressantes. La liste des requêtes "/deals" que nous avons créée précédemment ressemble à ceci :

Pour traiter toutes les requêtes, nous pouvons connecter la liste en tant que fichier d'entrée dynamique à un nouveau composant de mappage. La dernière fois que nous avions besoin d'un nouveau composant, nous avons intégré une requête API /divisions dans le mappage, et nous avons laissé MapForce créer automatiquement un schéma XML. Nous pourrions faire la même chose ici en intégrant une requête API /deals en tant que fichier d'entrée XML. Il y a juste un petit problème : bien que la documentation en ligne de l'API Groupon décrive clairement les requêtes que nous pouvons effectuer, elle est vague quant aux informations qui seront renvoyées. Avant d'envoyer des dizaines de requêtes à l'API pour toutes les offres actuelles, nous aimerions probablement en savoir un peu plus sur les données qui seront renvoyées.

Faisons un marché

Comme l'a dit Yogi Berra, on peut observer beaucoup de choses simplement en regardant. Commençons par exécuter une requête "/deals" dans XMLSpy. Cela nous permettra d'examiner la réponse à une requête pour une seule division avant de traiter un volume de données potentiellement trop important. Le menu Fichier / Ouvrir de XMLSpy comprend la même option "Basculer vers l'URL" que nous avons utilisée dans MapForce dans la publication précédente. Si nous entrons la requête API "/deals" pour une division couvrant une grande zone métropolitaine, par exemple Dallas, nous obtiendrons probablement suffisamment d'occurrences de "deals" pour pouvoir déduire les caractéristiques de l'ensemble des données. XMLSpy ouvre la réponse à la requête API "/deals" en mode texte, comme s'il s'agissait d'un fichier local :

Comme prévu, nous avons reçu une quantité importante de données lorsque nous avons demandé toutes les transactions pour une seule division ! Une méthode rapide pour analyser la structure de ces données consiste à utiliser l'option du menu XMLSpy DTD / Schéma pour générer un fichier .xsd à partir du fichier XML. Ci-dessous, vous trouverez une version abrégée du fichier .xsd généré, basée sur la réponse à la requête /deals pour Dallas :

Nous pouvons approfondir l'analyse, en suivant les conseils de Yogi, comme si nous revivions la même situation. En examinant tous les éléments du schéma XML, on découvre certaines anomalies intéressantes. Par exemple, il existe deux éléments nommés "redemptionLocation" avec des définitions différentes. Le premier contient une séquence d'éléments enfants :

Et la seconde est définie comme une simple chaîne de caractères :

En revenant aux données XML relatives à Dallas et en recherchant l'élément "redemptionLocation", on trouve les exemples suivants :

Et :

C'est vraiment intéressant, car redemptionLocation = "online" identifie les offres qui peuvent être utilisées de n'importe où, au lieu de nécessiter une visite dans un magasin physique de la division où elles sont proposées. Et si nous effectuions des requêtes à l'API /deals pour toutes les divisions et extrayions une liste de toutes les offres en ligne ? Ce serait une version extrême de Groupon !

Ne demandez que ce dont vous avez besoin La requête de l'API Groupon /deals prend en charge un paramètre optionnel appelé &show= qui permet aux utilisateurs de limiter les données renvoyées. L'utilisation de ce paramètre permet d'économiser de la bande passante et de réduire le temps de traitement des données en supprimant les données inutiles de la réponse de l'API. Nous pouvons également simplifier notre résultat final en incluant uniquement les informations les plus pertinentes, notamment le lien vers la page web de Groupon pour chaque offre. Après avoir supprimé les éléments inutiles du schéma Dallas généré, notre version finale pour le résumé des offres en ligne ressemble à ceci :

Lorsque nous ajoutons le paramètre "&show=" à notre mappage MapForce pour ne demander que les éléments inclus dans le schéma XML simplifié, les requêtes prennent la forme suivante :

Maintenant, nous pouvons intégrer le fichier .xsd modifié dans la configuration et connecter la liste des requêtes API/offres en tant qu'entrée dynamique. Nous n'avons pas besoin de supprimer le fichier texte que nous avons utilisé pour collecter la liste des requêtes, car il pourrait être utile pour le débogage futur.

Ces modifications finalisent la partie d'entrée de la cartographie des données.

Définir la sortie de la transformation des données

Dans XMLSpy, nous pouvons apporter quelques modifications supplémentaires au schéma XML d'entrée afin de concevoir une nouvelle version pour la sortie :

Nous avons supprimé l'élément de réponse car il n'apporte aucune valeur ajoutée, et nous avons éliminé l'élément "redemptionLocation" que nous ne prévoyons pas d'inclure dans le résultat. Nous avons également ajouté un élément de date pour un horodatage, car notre fichier de sortie sera une capture instantanée de données qui évoluent constamment.

Après avoir enregistré cette version du fichier .xsd dans XMLSpy, nous pouvons l'intégrer à la configuration de mappage de MapForce. L'image ci-dessous montre le côté de sortie de la configuration, avec le composant de sortie partiellement connecté. Le filtre en haut lit l'élément "redemptionLocation" pour sélectionner uniquement les offres en ligne, et la fonction "now" insère la date actuelle

La dernière modification que nous avons apportée au schéma XML de sortie consistait à remplacer plusieurs types d'éléments, initialement définis comme dateTime, booléen et entier, par le type de données chaîne de caractères, afin de permettre l'utilisation de textes plus descriptifs. Voici la définition complète de la correspondance, avec les connexions finales vers le composant de sortie :

Voici le résultat

Lorsque nous cliquons sur le bouton "Sortie", MapForce traite l'intégralité de la transformation, du début à la fin, en utilisant son moteur d'exécution intégré. Voici une description des étapes :

Exécutez la requête "/divisions" pour obtenir la liste actuelle des divisions
Concaténer les chaînes de caractères pour créer la liste des requêtes relatives aux offres promotionnelles pour toutes les divisions
Exécutez les requêtes /deals pour générer des données dynamiques pour le composant d'entrée
Filtrer les offres en ligne pour générer le composant de sortie, exécuter les fonctions de mappage restantes, et ajouter l'horodatage une fois que toutes les offres ont été traitées

MapForce ne met que quelques secondes pour effectuer toutes ces étapes et générer un fichier de sortie contenant une série de transactions qui ressemblent à ceci :

Dans la troisième partie de cette série, nous allons concevoir une feuille de style qui transformera automatiquement la sortie XML de notre système en HTML, afin d'afficher les informations de manière attrayante dans un navigateur web et sur les appareils mobiles. À bientôt au stade, Yogi !

XMLSpy et MapForce sont disponibles ensemble dans le pack Altova MissionKit, proposé à un prix spécial. Découvrez par vous-même à quel point il est facile d'utiliser le MissionKit pour convertir des données provenant d'une API web : téléchargez une version d'essai gratuite de 30 jours !

Note de la rédaction : Notre série originale sur la gestion des données provenant de l'API Groupon s'est déroulée en trois parties, que vous pouvez consulter en cliquant sur les liens suivants : La première partie, intitulée Utilisation de Altova MapForce pour traiter l'API Groupon, explique comment créer des entrées dynamiques en collectant des données à partir de plusieurs URL. La deuxième partie, intitulée Utilisation de MapForce pour traiter l'API Groupon – Partie 2, décrit comment nous avons filtré les données de l'API et défini la sortie afin d'extraire uniquement les informations les plus pertinentes. La troisième partie, intitulée Traitement de l'API Groupon – Partie 3, explique comment formater la sortie sous forme d'un seul document HTML optimisé pour les appareils de bureau et mobiles, et présente des méthodes pour automatiser les exécutions répétées.