> Tech > Exemples : Météo RESTful et génération d’un PDF

Exemples : Météo RESTful et génération d’un PDF

Tech - Par iTPro - Publié le 17 février 2012
email


Exemple : météo RESTful

Le temps ne sera pas toujours calme ou ensoleillé, mais je peux vous assurer qu'il sera RESTful ! Il existe un site web appelé Weather Underground qui vous procure des prévisions météo … RESTful.

J'ai écrit

un exemple de programme nommé WUNDERG (figure 3). WUNDERG prend une chaîne de recherche comme paramètre (A, figure 3). Ce peut être un code postal ou un nom de ville ; WUNDERG consultera la météo de ce lieu et l'affichera sur l'écran. Signalons une difficulté : certains caractères autorisés dans des noms de villes ne sont pas acceptés par un HTTP URI. Pour résoudre cela dans un navigateur, vous demanderiez à l'utilisateur d'entrer les données dans un formulaire HTML afin que le navigateur saute (escape) les caractères spéciaux éventuels quand il construit un URI à partir du formulaire. HTTPAPI offre la même fonctionnalité dans ses routines webForm. En B de la figure 3, je crée un nouveau formulaire web avec l'API webform_open() provenant de HTTPAPI. Après quoi j'utilise la routine webform_setVar() et la routine webform_getStr() pour définir la chaîne de requête et renvoyer le résultat codé à mettre dans mon URI, respectivement. webform_close() libère la mémoire que le formulaire web utilisait. Et dès lors que les données se trouvent dans mon URI, la mémoire n'est plus nécessaire.

Encore une fois, http_url_get_xml() est utilisé pour envoyer la requête au service web (C, figure 3), et une sous-procédure est utilisée pour obtenir les bits appropriés de XML et les renvoyer dans des variables RPG (D, figure 3). Comme les prévisions météo peuvent être trop longues pour l’opcode DSPLY de RPG, j'utilise l'API Display Long Text (QUILNGTX) pour afficher les résultats sur l'écran (E, figure 3). QUILNGTX fait surgir une boîte sur un écran 5250 contenant un message. Celui-ci peut contenir jusqu'à 15 millions de caractères : C’est plus qu'il ne m'en faut !

Exemple: générer un PDF

Contrairement aux services web SOAP, où le résultat est toujours un document XML, un service web RESTful peut renvoyer toute sorte de document. XML, bien sûr, mais aussi une image, un fichier son, un document de gestion, ou tout autre genre de fichier. Comme il n'a pas l'obligation de faire tenir ce document dans un document XML, contrairement à SOAP, on n'a plus à se préoccuper de coder ou décoder un document en base64. Il vous suffit de recevoir le document dans le format souhaité.

En recherchant un exemple de cette technique sur Internet, je suis tombé sur un site appelé html2pdf.com. Comme son nom l'indique, vous pouvez lui donner l'URI de toute page web HTML, et il la convertira en un document PDF, une image PNG ou des données JSON. C'est clair et net, aussi j'ai créé la commande HTML2PDF (figure 4). Pas mal pour un programme RPG dont l'écriture ne m'a pris que 20 minutes ! Bien sûr, le gros du travail a été fait par les gars de html2pdf.com. Merci à eux.

La figure 5 montre le code RPG qui s'exécute derrière la commande. Il soumet l'URI et le format de sortie au service web RESTful (A, figure 5). Contrairement aux autres exemples, je n'appelle pas http_url_get_xml(). Mais j'appelle http_url_get(), qui télécharge la sortie provenant du service dans un fichier de l'IFS plutôt que de l'exécuter par l'intermédiaire d'un analyseur XML.

HTTP à un mécanisme appelé "redirect" qui ordonne à un service web de visualiser un URI différent de celui qu'il a demandé à l'origine. Sous le capot, le serveur HTTP envoie une réponse 301 au navigateur en même temps qu'un nouveau URI qu'il devrait visualiser. Dès qu'il voit le 301, le navigateur se dirige vers la nouvelle page.

Pour accomplir la même chose dans HTTPAPI, vous devez écrire dans votre programme RPG du code qui recherche le code de réponse 301. Il existe une sous-procédure nommée http_redir_loc() que vous pouvez appeler pour obtenir le lieu vers lequel elle vous demande de vous rediriger (B, figure 5).

Traitement des erreurs et dépannage

L'exemple de code RPG que j'ai fourni pour cet article appelle la routine http_debug() provenant de HTTPAPI pour valider l'assistance au débogage. Il écrit un journal de vos communications HTTP dans un fichier stream de l'IFS, qui est facile à consulter pour le dépannage. Par exemple, la ligne de code suivante active la sortie debug et l’écrit dans un fichier nommé /tmp/debug.txt in your IFS:

http_debug(*ON: '/tmp/debug.txt');

Notons aussi que les routines http_url_get_xxx() renverront une valeur 1 en cas de réussite. Tout autre nombre indique leur échec. Un nombre positif indique que le serveur HTTP a renvoyé un message d'erreur ; un nombre négatif indique que HTTPAPI a trouvé une erreur côté client. Dans tous les cas, vous pouvez appeler la routine http_error() pour obtenir un message d'erreur.

Si tout le reste échoue, le meilleur endroit pour obtenir de l'aide sur HTTPAPI est la liste de publipostage des projets open source FTPAPI et HTTPAPI. Vous pouvez vous inscrire à cette liste sur la page d'accueil de HTTPAPI. Tout comme HTTPAPI, la liste de publipostage est gratuite.

Trouver un petit quelque chose

Il y a pléthore de services web sur Internet. Beaucoup d'entre eux contiennent des routines dignes d’être intégrées dans vos applications. Certains sont gratuits, d'autres non. Il existe un moteur de recherche de services web à programmable.com/apis. C'est une excellente interface pour rechercher des services web. Essayez donc de trouver quelque chose d'intéressant pour vous. C'est utile et distrayant !
 

Téléchargez gratuitement cette ressource

Le Guide d’Orchestration du Parcours client

Le Guide d’Orchestration du Parcours client

Au-delà de la clarification des nouveaux concepts de gestion du parcours client, ce guide vous permettra de définir, créer et mettre œuvre une orchestration complète articulée autour des trois volets essentiels au succès de l’expérience client et de l’entreprise.

Tech - Par iTPro - Publié le 17 février 2012