Debugging “Skipping logentry” in WS-I Basic Profile Testing Tool

Cet article est également disponible en français.

Web Service Initiative tools allow us to test a web service in terms of conformity to Basic Profile. This is partly done statically through a WSDL analysis, and partly dynamically, based on messages captured from the service use.

To realize such a capture, a monitoring tool is supplied and, using proxy / MITM method, records everything that passes around between client and server. This generally works fine, but when passing the logs to the analyzer to create the final report, one can get this kind of errors :


The problem of course is that the log entries are not being taken into account by the analyzer, and the resulting report will be static, and quite limited.

Where this becomes a real pain is that there is basically nothing on the web about this problem :


The only page referencing this (when one extends the search by forgetting the second part of the message, one only finds two additional non-relevant pages) explains the problem, but nobody gave any answer :


In short, it starts smelling bad, and we are going to have to dive into the code. Luckily, WS-I at least provided a .NET version of the tool (it would have been even better with PDB or source code, mind you). So, let’s jump in the different DLL files, passing them to ILDASM. I give you the right one : WSITest-Assertions.dll contains our error message. We can verify this by opening the library inside ILDASM :


Then, we make a dump of it :


We accept the standard options. No need to get complicated here : anyway, we are just looking for a string…


In order to search for the string more easily, we save the dump as IL code :


Then we can open the file just created. It happens that the “Skipping logentry” message is in three different places in the code, each time with the same sub-message “not from specified service” :


Going up, we find the class, and can use Reflector or ILSpy to see the corresponding code :


Piece of luck : the three code parts actually call the same “ProcessMessage” function, which is located in a second assembly :


Clicking on this function brings us to the library, which is WSITest-AnalyzerCore :


Inside, we indeed reach the method called ProcessMessage :


When taking a look at the code, we see that there is a link to a correlation mode. This sounds quite logical, since the code is supposed to link the configuration parameters and the ones from the log. The log entries should indeed correspond to the service under test :


But where the problem seems to be is that the code does not even talk about the “operation” correlation mode. It only deals with Endpoint and Namespace modes :

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)));

However, in the configuration file supplied by the WS-I Basic Profile tool, namely analyzerConfig.xml, the correlation mode is valued to “operation” :

<logFile correlationType=”operation”>traceLog.xml</logFile>

So, we try with a different mode, namely Endpoint, which seems more adapted :

<logFile correlationType=”endpoint”>traceLog.xml</logFile>

And it works ! Messages from the log are then correctly taken into account by the analyzer :


Question : whatever would we do without ILDASM / ILSpy ?

OK, I know : we would drop a mail to WS-I, asking for bu correction… But their FAQ is not technical and there is no forum (nor activity in the tools, by the way). So, short of debugging on one’s on tools, nothing short to correct the problem…

Hope this helps !

About JP Gouigoux

Jean-Philippe Gouigoux is a French software architect & MVP Connected Systems Developer. He regularly talks at University of South Brittany and Agile Tour.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha Captcha Reload