Cet article est la ‘version 2’ de ce premier tutoriel sur la réalisation d’un scénario de test d’un webservice avec JMeter, qui date du mai 2008 (le temps passe vite…).
Dans la première version de l’article, nous en étions à la version 2.3.1 de JMeter. Pour cette ‘version 2’, on passe directement à la future version 2.5.1. D’une part, maintenant l’interface graphique de JMeter sur les WebServices est traduite en français, et d’autre part un certain nombre d’améliorations graphiques et de convivialité ont été apportées sur la dernière version de JMeter.
JMeter permet de faire des tests de charge sur des webservices via SOAP (avec le protocole Version 1.1). La suite vous propose une petite démonstration.
Pour ce test de charge (ici simple) sur un webservice, il faut un …webservice… pour ma part, j’ai suivi ce tutoriel du site developerWorks d’IBM pour avoir un webservice tout simple de type « hello world » : Develop and execute WS-BPEL V2.0 business processes using the Eclipse BPEL plug-in
Passons maintenant à JMeter et la préparation du scénario de tir de charge.
L’aspect fonctionnel du tir est volontairement absent de ce tutoriel afin de rester focalisé sur la partie « webservice » / SOAP. Je vous renvoie vers mes autres tutoriels pour voir cet aspect.
Sur JMeter, on commence bien entendu par la création du Groupe d’unités.
Ensuite on passe directement à l’ajout de la Requête WebService (SOAP), qui va nous servir pour faire la requête SOAP vers le webservice qui a été ‘développée’ dans le tutoriel d’IBM.
On termine par l’ajout des récepteurs de résultats. Ici, j’ai ajouté un Rapport consolidé ainsi qu’un Arbre de résultats (qui est particulièrement utile pour le débogage).
Pour revenir au webservice d’exemple, on va utiliser son descripteur WSDL pour obtenir les services qu’il propose. Pour cela on utilise l’URL d’accès http://localhost:8080/ode/processes/HelloWorld sur laquelle, on ajoute « ?wdsl » à cette URL pour avoir le service de découverte.
Dans JMeter, on sélectionne la requête WebService, et dans le champ WSDL URL on saisit l’URL de découverte ci-dessus.
Puis, on clique sur le bouton Charger WSDL afin de remplir automatiquement les champs de paramétrage du web service.
Ensuite, la liste des méthodes du webservice est affichée dans la liste déroulante. On choisit la méthode à utiliser, puis on clique sur le bouton Configurer. Ce bouton va pré-remplir les champs de la requête WebService.
Il faut maintenant remplir le champ Données Soap/XML-RPC dans l’échantillon. Pour cela, nous allons nous aider du logiciel SoapUI.
On crée un nouveau projet, dans lequel, on remplit le champ Initial WSDL/WADL par l’URL du descripteur de déploiement déjà indiqué à JMeter ci-dessus.
Dans l’explorateur de webservice de SoapUI, on choisit le service HelloWorldSOAP11Binding (la version 1.1 du SOAP, JMeter ne connait pas la version 1.2)
Après avoir double-cliqué sur Request 1 dans la fenêtre de requête, on a un modèle de message SOAP comme le montre la capture ci-dessous. On donne une valeur pour l’entrée du service web, puis on sélectionne le message SOAP et on le copie dans son presse-papiers (le fameux Ctrl-C)
On revient dans JMeter, au niveau de la Requête WebService (SOAP) afin de faire le coller (Ctrl-V) dans le champ Données Soap/XML-RPC.
On prendra également la peine de cocher la case Lire la réponse SOAP afin de pouvoir capter le retour de l’appel au WebService. (Si ce n’est pas coché, il n’est pas possible de faire par exemple des assertions de réponses ou d’utiliser un extracteur d’expression régulière pour récupérer des valeurs)
On complète le scénario JMeter par la modification du paramétrage du Groupe d’unités. Ici, une unique unité (utilisateur virtuel) qui lancera 10 fois l’appel.
Et hop, on lance le tir.
Les réponses s’affichent dans l’onglet Données de réponses du récepteur Arbre de résultats.
L’exploitation des résultats suit la même logique qu’un tir de charge « web ». cf les autres tuto sur Jmeter.
Et voilà pour ce petit tutoriel WebService.
En complément, noter qu’il est tout à fait possible de faire des tests de charge sur des webservices en utilisant par la Requête HTTP classique comme on le ferait pour un site Web. On évite ainsi le temps d’analyse du fichier XML, etc. par JMeter pendant le tir (et donc de la consommation CPU excessive du poste de tir).
L’avantage aussi d’utiliser une requête HTTP classique c’est que le serveur Proxy de JMeter peut être utilisé pour créer automatiquement les requêtes HTTP/SOAP.
Ci-dessous, le résultat d’une création automatique par le serveur Proxy d’une requête de webservice « cachée » dans une requête HTTP.
On voit ci-dessus que le message SOAP est sur 1 ligne et dans les paramètres de la requête comme une valeur (sans nom).
On remarquera également en fils de la requête HTTP, le Gestionnaire d’entêtes HTTP, qui contient un champ SOAPAction qui indique le service web à appeler.
Voilà, ensuite c’est la même chose pour le lancement du tir. Les résultats se présentent exactement de la même façon qu’avec une requête WebService.
Bon courage dans vos tests de services web !
./
Bonjour,
tout d’abord, merci pour ce tutoriel très bien fait pour un néophyte comme moi !
J’ai une problématique de sécurité d’accès sur mon Web service.
Je ne peux donc pas charger le WSDL et donc encore moins exécuter une requête soap.
J’ai tenté, sans succès, ma chance en précisant l’url du WSDL sous la forme : http://username:password@server/pathtowsdl
auriez-vous une solution ?
Merci
ELU
Merci
Ajouter un élément de configuration Gestionnaire d’autorisation HTTP
Bonjour,
Est-il prévu d’améliorer le sampler SOAP pour permettre d’envoyer au moins une piece jointe ?
A noter aussi que ce sampler SOAP fait 2 requetes HTTP si le champ wsdl est rempli : 1 pour le WSDL et l’autre pour l’appel de service.
Cdt,
GBT
Bonjour,
Avant tout, merci pour ce tutoriel très bien conçu!
Savez-vous s’il est possible de paramétrer JMeter pour lui faire tester un webservice crypté avec Rampart? J’ai beau chercher dans les paramètres et la doc, je ne trouve rien à ce sujet.
Merci d’avance
Over