Incomming and outgoing request of a WCF service

[mlooise]

Hi,

I have a small question regarding message logging in WCF. Is it possible to log the incomming and outgoing request of a SOAP message? What I have done so far is setup MessageLogging trough the existing diagnostic mechanisms of WCF and try to hook this into application insight.

 <diagnostics>
      <messageLogging logEntireMessage="true"
              logMalformedMessages="true"
              logMessagesAtServiceLevel="true"
              logMessagesAtTransportLevel="false"
              maxMessagesToLog="500"
              maxSizeOfMessageToLog="-1"/>
    </diagnostics>

and

<system.diagnostics>
    <trace autoflush="true" indentsize="0">
      <listeners>
        <add name="myAppInsightsListener"/>
      </listeners>
    </trace>
    <sources>
      <source name="System.ServiceModel.MessageLogging" switchName="sourceSwitch" >
        <listeners>
          <add name="myAppInsightsListener" />
          <remove name="Default"/>
        </listeners>
      </source>
    </sources>
    <switches>
      <add name="sourceSwitch" value="All"/>
    </switches>
    <sharedListeners>
      <add name="myAppInsightsListener" type="Microsoft.ApplicationInsights.TraceListener.ApplicationInsightsTraceListener, Microsoft.ApplicationInsights.TraceListener" />      
    </sharedListeners>
  </system.diagnostics>

What this does is send a whole lot of data to AI and that seems encouraging at first. However, some of the data sent to AI does not contain the ai.operation.name. This seems to result in the message not beeing shown in AI together with the request. Some messages that do contain this ai.operation.name are shown correctly. The reponse of the soap call are in this way logged as a trace, but the incomming request (only way I found was throught ServiceLevelReceiveRequest) does not.

Is there any other way to achieve this? Or maybe i am missing a complete concept here. Is there another way? Our goal here is to be able to trace incomming and outgoing message (SOAP message) of our WCF webservice on our OTA environments.

Hope someone can offer some advice.

Regards, Martin

[tomasr]

@mlooise There is an example of doing this by implementing a custom telemetry module here: https://github.com/Microsoft/ApplicationInsights-SDK-Labs/blob/master/WCF/Shared.Tests/TraceTelemetryModule.cs

This might be an option if you have not-too-long messages.

[mlooise]

@tomasr Thanks for your reply. I tried this solution and it seems to fit my needs. Thanks!

I am wondering; why is this module currently implemented in the test package of AI.WCF. It looks to me as it could be usable as a telemetrymodule for general use (users could then just config it in the AI.config). It worked out of the box for me emitting events for every request/response. Now I had to copy it to my own code because it isn't useable from the testpackage. I guess there's a reason for this? Is this module maybe memory extensive? (uses a xml reader)

This is maybe a general comment about the modules of AI.WCF; it took me quite some time to see what is actually in the package and how to use it. Especially also how not te use it (not combine it with the web package for example). I think that some general guidelines or example could be very usefull. I would be happy to provide some input for some examples or maybe a wiki page here on GitHub.

[tomasr]

@mlooise The reason this is in the test package is because it is literally helper code to test a library feature, rather than something expected that users would use on its own.

It's also not very efficient, as it requires buffering the whole message content in memory. Some users might be OK with that, but for others that might introduce an unacceptable penalty (particularly if you're using large messages and/or streaming).

That said, I guess we could consider adding it as a default module and disable it by default.

As for documentation improvements, if you've got questions/issues you struggled with, let us know and I'll try to improve the readme to include those!

[mlooise]

@tomasr Ok clear, thought some like that. I think that it can be a usefull addition to the package. We are for instance going to use it on our Develop and Test environments to make reproduction of testing-issues easier. We don't want to enable it on Production or Acceptence because it could indeed have a performance/resource impact. Still; If it is clear to 'use at own risk' and only enable it when you known what you're doing .. I think it's usefull!

About the documentation: I think it would help to define a kind of 'default' configuration when implementing this package in a WCF service; what modules of web e.g. should you disable. VisualStudio by default enables a lot which really should not be enabled when using this package e.g:

<Add Type="Microsoft.ApplicationInsights.Web.RequestTrackingTelemetryModule, Microsoft.AI.Web">
<Add Type="Microsoft.ApplicationInsights.Web.ExceptionTrackingTelemetryModule, Microsoft.AI.Web"/>

Maybe this could be explained a bit more. Also I didn't really have a clear overview of available modules when just getting the nuget package. If this could be clarified a bit I think this would help a lot of people.

[tomasr]

About tracking the messages, another option I've considered is adding code to track not the raw messages, but the actual parameters passed to the function (maybe as json? not sure). That could be useful in some scenarios, particularly if there's a way to annotate them for selective tracking.

About the docs, It's definitely an interesting issue, because it's far beyond the WCF SDK. It's really part of how the Application Insights SDK is designed.

Basically the default install will register all modules, and usually there's no reason to change much of it. The install adds a bunch because some of the dependencies we have (the Windows Server SDK, in particular) adds a bunch on it's own (plus if you enable the Web SDK, it brings in a bunch, too).

In your case, you installed the Web SDK, which is definitely not installed by default when adding the WCF SDK. It is, however, added by the Visual Studio templates by default, so that's a bit on the annoying side. Still, right now it should sort of "just work" even if you have both installed.

I think definitely this could use some higher level docs on how the ApplicationInsights.config file works, but I will add some documentation on each on to the Readme in any case.