This article is also available in English.
Les outils du Web Service Initiative permettent de tester un service web en termes de compatibilité avec la norme Basic Profile, et ce de manière statique par une simple analyse du WSDL, mais également en complétant par une analyse dynamique qui se base sur des captures de messages.
Pour cela, on utilise le moniteur fourni comme un proxy / Man In The Middle, qui enregistre et repasse tout ce qu’on fait. Jusque là, pas de souci, mais lorsqu’on passe l’analyseur pour créer le rapport final, on peut se retrouver avec ce genre de message :
Là où c’est gênant, c’est bien sûr que ça veut dire que les messages ne sont pas pris en compte, et qu’on retombe sur un bête rapport statique.
Et là où ça devient carrément embêtant, c’est qu’il n’y a vraiment rien sur le net sur ce problème :
La seule page trouvée qui y fait référence (quand on restreint la recherche à la première partie, on n’a que deux pages de plus et ce sont des faux positifs) ne fait que poser le problème, sans réponse :
Bref, ça commence à pas sentir bon, et il va falloir rentrer dans le code. Heureusement, le WS-I a la bonne idée de fournir une version .NET de leur outil (ils auraient pu mettre les PDB et le source, mais bon). Bref, à l’attaque des différentes DLL, qu’on passe à ILDASM. Je vous donne tout de suite la bonne, c’est WSITest-Assertions.dll qui contient notre message d’erreur. On vérifie ça en ouvrant la librairie dans ILDASM :
Puis on fait un dump :
On accepte les options par défaut. Rien de compliqué, de toute façon : on ne fait que chercher une chaîne…
Pour chercher plus facilement, on enregistre ça sous forme de code IL :
Et on peut ensuite ouvrir le fichier qui a été créé. Il se trouve que le message “Skipping logentry” se trouve à trois endroits différents du code, et à chaque fois avec le même sous-message “not from specified service” :
En remontant, on trouve la classe et on peut utiliser Reflector ou ILSpy pour voir le code correspondant :
Il se trouve que les trois portions de code font appel à la même fonction “Process Message”, qui vient d’une autre librairie :
En cliquant sur cette fonction, on passe sur la librairie en question, qui est WSITest-AnalyzerCore :
Et à l’intérieur, on arrive bien sur notre fonction ProcessMessage :
Quand on regarde le code, on voit qu’il y a un lien avec le mode de corrélation. Logique, puisque c’est le code qui fait le lien entre les paramètres de configuration et ceux en provenant du log. Il faut bien que les logs correspondent au service web étudié :
Mais là où se trouve apparemment le problème, c’est que le code ne traite pas le mode de corrélation “operation”. Il ne traite que les cas Endpoint et Namespace :
public bool ProcessMessage(HttpSoapLog logRequest, HttpSoapLog logResponse, CorrelationType correlation, WsdlOperation wsdlOperation)
{
return this.MessageInEndpoint(logRequest) && (correlation == CorrelationType.Endpoint || (this.MessageInNamespace(logRequest) && (correlation == CorrelationType.Namespace || wsdlOperation != null)));
}
Or, dans le fichier de configuration de l’outil WS-I Basic Profile, à savoir analyzerConfig.xml, la valeur de corrélation proposée par défaut est “operation” :
<logFile correlationType=”operation”>traceLog.xml</logFile>
Du coup, on tente avec un mode de corrélation Endpoint, qui parait plus adapté :
<logFile correlationType=”endpoint”>traceLog.xml</logFile>
Et ça marche ! Les messages du log sont désormais bien pris en compte par l’analyzeur :
Question : que ferait-on sans ILDASM / ILSpy ?
Bon, je sais la réponse en fait : on enverrait un mail au WS-I pour leur demander de corriger, mais la FAQ n’est pas technique, et il n’y a qu’une adresse pour les commentaires généraux (ni beaucoup d’activité sur les outils, d’ailleurs). Du coup, à part déboguer soi-même, point de salut rapide…
En espérant que ça serve à quelqu’un !
