Test du service web

trois options en bas (B) et cliquez sur Finish. Que vous le croyiez ou non, c’est tout : vous voilà prêts à tester le service web.

La figure 4 montre le iSeries Listing. L’information la plus importante ici est l’entrée Program interface stream file (A) qui contient l’adresse du fichier PCML. S’il y a des erreurs quand vous créez le service web, le fichier PCML est l’un des endroits où rechercher leur cause. Une fois le service web créé, la vue Web Service Test Client est affichée. De là, vous pouvez tester toutes les procédures, présentées ici en tant que méthodes. Les quatre premières méthodes listées sont générées à des fins de test. A noter que chaque procédure provenant du programme RPG a deux méthodes. L’une renvoie l’information au client test et élimine le formatage XML. L’autre a _XML dans son nom, et le format de données renvoyé est XML. La figure 5 montre la méthode returnstate_XML. Le cadre Inputs (A) montre pSTATE (de notre programme RPG) mais, vous vous en souvenez, je l’utilise comme une variable de renvoi. Tout ce que j’ai à faire est de cliquer sur Invoke et le service web appelle la procédure ReturnState dans mon programme de service. Le cadre Result (B) montre l’information de renvoi dans XML. Ou bien, avec la méthode ReturnState, comme le montre la figure 6, le cadre Result (A) n’affiche que la valeur de renvoi de la procédure et la valeur variable de pSTATE sans le coding XML.

La figure 7 illustre la méthode ReturnOpnBal. Dans le cadre Inputs (A), j’ai entré TX pour l’état et mis la valeur par défaut du solde ouvert à 0, même s’il (solde ouvert) est utilisé comme une variable de renvoi. L’application renâcle un peu et échoue si vous n’initialisez pas la variable numérique. Si les variables numériques ne sont pas initialisées, le cadre Results montre l’erreur « exception : java.lang.NumberFor – matException ». Cela me rappelle une erreur de données décimales dans RPG. Le cadre Results de la figure 7 a la valeur de renvoi de la procédure de 0 ou SQLCOD à partir de la source. Le programme de service ne change pas pSTATE et donc sa valeur est encore TX, mais vous pouvez voir que pOPNBAL montre la valeur renvoyée du programme de service.

Le service web peut aussi être testé en utilisant Web Services Explorer. La figure 8 montre la vue Web services Explorer pour le même service web. Vous pouvez lancer Web Services Explorer de deux manières. La première consiste à utiliser la vue Project Explorer provenant de la perspective Web. A partir du Project Explorer, vous trouverez le service web sous JSR-109 Web Services. Ouvrez le dos sier Services, trouvez votre service web, puis faites un clic droit et sélectionnez Test with Web Services Explorer. La seconde consiste à faire un clic droit partout où vous trouvez le fichier WSDL et à sélectionner Test with Web Services Explorer.

Web Services Explorer n’a pas besoin des méthodes de test, donc vous ne verrez que les six méthodes pour les trois procédures. De la même manière que le Web Services Test Client, un ensemble de méthodes renvoie le code XML – ces noms _XML – et l’autre ensemble supprime le code XML et renvoie simplement la valeur. Le cadre Navigator dans la figure 8 (A) affiche l’information du service web, y compris les méthodes. Le cadre Actions (B) est l’endroit où vous invoquez le service web en entrant les paramètres d’entrée, si nécessaire. La section Status (C) montre les résultats obtenus en invoquant le service web. J’ai aussi trouvé la vue TCP/IP Monitor de la figure 9 commode pour vérifier le temps de réponse (A) et pour voir toute l’enveloppe SOAP (B). La morale de ce bref article est simple : que vous préfériez la vue Web Services Test Client ou la vue Web Services Explorer, il est facile de créer et de tester un service web à partir de WDSc en utilisant vos programmes de service basés sur le serveur !