SoapUI n’est pas mon amI

clip_image001Un retour d’expérience sur le thème d’un petit coup de gueule. En effet j’ai récemment eu, disons, des expériences malheureuses avec l’utilisation de web services soap fourni par des tiers et donc pas forcement codés avec des technos Microsoft. En tant que client de ces web services (en général du code C# dans des applis SharePoint par exemple), je me suis vite retrouvé dans la relation suivante (bien sûr je schématise un peu) :

 

– Moi : je ne comprends pas j’ai un problème avec le web service

– Fournisseur : ah on vérifie, ne quittez pas….

– …

– Fournisseur : Pour nous tout est ok ! ça doit venir de votre code …

– Moi : … je ne comprends pas j’ai déjà tout vérifié 10 fois ! vous êtes sûr ?

– Fournisseur : oui, oui ! on vient de faire un test avec SoapUI et ça fonctionne ! on vous envoi la capture d’écran…

 

Ok, Oui, … mais NON !

 

La vérité c’est que ça ne marchait pas, du moins pas tout à fait dans les règles ! Alors je pose la question suivante :

 

SoapUI qu’est-ce que ça fait et qu’est-ce que ça ne fait pas ?

 

Pour être précis, j’entends sur la partie SOAP, car SoapUI permet aussi de faire du REST, du JDBC et autres…

 

Donc j’avoue je n’en sais rien ! Ou presque…. Mis à part que si j’ai bien compris, des rares fois où je l’ai utilisé, il est capable de télécharger le wsdl et d’invoquer des méthodes du service et d’afficher la réponse XML. Alors je ne sais pas si j’aurais vraiment le temps de me pencher plus sur la question en détail et j’attends volontiers vos retours ! Notamment vis-à-vis des 2 problèmes ci-après que j’ai pu avoir :

 

Une fois c’était un problème de wsdl. Celui contenait des références vers des fichiers xsd donnant le schéma des objets retournés par le service. Ces références étaient sur des url différentes de celle du wsdl. Url inaccessibles depuis mon poste de développement. Donc je n’arrivais pas à générer le code C# avec les outils de Visual Studio et WCF (uniquement le wsdl et pas les xsd cela ne suffit pas). Manifestement le développeur du service avait vérifié l’accès au wsdl avec SoapUI et testé l’appel d’une des fonctions.
Mais apparemment SoapUI ne cherche pas spécialement à analyser la réponse xml pour voir si les données correspondent aux schémas. Peut-être même qu’il n’a pas cherché à télécharger les xsd en question. Ou encore il est possible que SoapUI sache faire ça mais que le développeur ne sache pas l’utiliser ? Cette fois ci le problème a vite été diagnostiqué car l’erreur dans Visual studio a été assez explicite, et une ouverture du wsdl dans le navigateur et on a vite compris…

 

Une autre fois c’était un peu plus complexe. Le proxy avait bien été généré, le code client C# fonctionnait, la config WCF était ok, tout roulais… Jusqu’à une mise à jour du web service par le « fournisseur ». Et bien sûr à partir de là ça ne marchais plus de notre côté. Vous imaginez la situation, étant bien sûr « prévenus » / « à temps » (rayer la mention inutile) de la mise à jour, j’ai demandé à ce qu’ils vérifient une seconde fois de leur côté et j’ai eu droit à ma capture d’écran de SoapUI…
De mon côté le comportement était que la méthode appelée ne semblait plus renvoyer aucune données, sans une quelconque erreur, juste un retour « null ». Même en mode pas à pas, impossible de constater une exception dans le code de la classe auto générée.

 

Le bon réflexe dans ce cas, c’est de disposer rapidement d’une application de test en C#, et pas une « générique ». Une bonne vielle application console, c’est vite fait, on ajoute les références au service, au récupère le bout de code pour l’appel, on met les paramètres d’entrée en dur qui vont bien et c’est parti on reproduit le problème ! Ensuite ? On modifie la config de l’appli de test pour activer la trace WCF ! C’est assez simple, voilà ici la documentation. Le fichier de trace généré est lisible avec un outil fourni avec Visual Studio (svctraceviewer) et va permettre entre autres de consulter les messages soap envoyés et reçus ! On reste ensuite sur la vérification « humaine », à base de comparaison et de compréhension de la syntaxe soap mais c’est déjà mieux d’avoir les données au niveau du client.

clip_image002

 

Dans mon cas j’ai pu en effet constater que je recevais une réponse du service, et à première vue il y avait bien des données ! Voilà encore une fois pourquoi mon « fournisseur » me dit que son service marche. SoapUI ne cherche pas à analyser la réponse et une simple lecture « humaine » de la réponse xml permet de valider « rapidement » (trop sans doute) que la fonction retourne bien des données…

 

Il se trouve que la réponse en question contenait sur les données des références à des namespaces qui ne correspondaient pas à ceux déclarés dans le wsdl et associés aux xsd décrivant les objets reçus. En clair la couche WCF ne voyait pas de données correspondant à des objets susceptibles d’être renvoyés pour cette méthode. Donc elle me fournissait une valeur null au lieu du tableau d’objet que j’attendais ! Tout ça à quelques caractères près dans ce fameux nom de namespace… il m’a fallu quand même un peu de temps pour le trouver celui là !

 

J’ai donc pu à mon tour faire mes petites captures d’écran expliquant les différences et en montrant le xml que je capturais de mon côté, le tout envoyé au « fournisseur » qui a donc finalement compris d’où venait le problème…

 

Mon conseil est donc :

prenez le temps de mettre en place un test unitaire de votre côté (client) en utilisant les outils fournis par Visual Studio et la couche WCF et activez toute traces utiles. Cela vous prendra un peu de temps au départ mais vous en fera gagner tellement après ! Et c’est sans compter sur la qualité de vos relations avec votre « fournisseur » !

 

 

Je tiens à préciser que l’objectif de cet article n’est pas de critiquer l’outil SoapUI. Ne le connaissant pas je ne me permettrai pas. L’objectif est bien de faire prendre conscience de l’utilisation qui peut en être faite et des conclusions qui en sont tirées ! Si vous voulez en savoir plus sur cet outil, voilà ce que dit l’éditeur : « SoapUI est le leader mondial Open Source d’outil de tests fonctionnels il est utilisé principalement pour les tests d’API. SoapUI prend en charge plusieurs protocoles tels que SOAP, REST, HTTP, JMS, AMF et JDBC. SoapUI vous permet de créer des tests de performance de pointe très rapidement et d’exécuter des tests fonctionnels automatisés » Et le site de l’éditeur : http://www.soapui.org/About-soapUI/what-is-soapui.html

 

 

Ceux qui pensent que chaque fois où j’ai écrit « fournisseur » dans cet article j’ai eu envie d’écrire « développeur Java » se trompent totalement 😀

Publié dans Développement divers Tagués avec : , , , , , , ,

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Verifions que vous êtes un humain * Time limit is exhausted. Please reload CAPTCHA.

Archives

Social

  • Twitter
  • LinkedIn
  • Flux RSS
  • mvp
  • technet
  • Google+