Hacer un "Trace" de un Servicio de WCF

Siguiendo con WCF vamos a ver como hacer un “trace” de las comunicaciones de nuestro servicio.

Gracias a la forma de trabajar con WCF no va a hacer falta tirar ni una línea de código; solo tenemos que modificar el fichero de configuración de nuestro servicio.

Lo que vamos a tener que indicar es qué queremos guardar, cómo lo queremos hacer y dónde lo vamos a guardar.

Para este ejemplo tenemos un servicio web muy simple; solamente tiene un método que devuelve la fecha actual. Y el servicio web lo sirve una aplicación que hace de host. Tiene dos endpoints: uno para el puerto 8000 usando un basicHttpBinding y uno para el puerto 8080 usando un netTcpBinding. Solo vamos a hacer el tracing para el host, así que solo vamos a modificar el app.config del host.

Sin aplicar el “tracing” el archivo app.config del servicio tiene esta pinta:



<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>
  <system.serviceModel>
    <services>
      <service behaviorConfiguration=”MyConf”
               name=”XService.Service”>
        <endpoint address=”Service”
                  binding=”basicHttpBinding”
                  name=”XBasicHttpBindingEndpoint”
                  contract=”XService.IService” />
        <endpoint address=”Service”
                  binding=”netTcpBinding”
                  name=”XNetTcpBindingEndpoint”
                  contract=”XService.IService” />
        <host>
          <baseAddresses>
            <add baseAddress=”http://localhost:8000/XService” />
            <add baseAddress=”net.tcp://localhost:8080/XService” />
          </baseAddresses>
        </host>
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name=”MyConf”>
          <serviceDebug includeExceptionDetailInFaults=”true”/>
          <serviceMetadata httpGetEnabled=”true”/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Lo primero que haremos es definir el qué: qué es lo que queremos guardar. Para hacerlo usaremos la etiqueta messageLogging de diagnostics, que está dentro del espacio de nombres (etiquetas) <system.serviceModel>



<system.serviceModel>
   <diagnostics>
     <messageLogging
       logEntireMessage=”true”
       logMessagesAtServiceLevel=”true”/>
   </diagnostics>
    <!– … –>
</system.serviceModel>

El campo logEntireMessage indica que queremos que se guarde todo el cuerpo del mensaje, si no solo se guardaría la cabecera. La opción logMessagesAtServiceLevel guardará los mensajes tal y como salen del servicio y llegan al servicio.
Hay más opciones a escoger: podemos guardar los mensajes a nivel de la capa de transporte, el número de mensajes máximo, etc.

Ahora vamos a definir el cómo y el dónde. Para hacerlo usaremos la librería de <system.diagnostics>.
La información de tracing es recibida por las sources. En nuestro caso usaremos una única source del tipo System.ServiceModel.MessageLogging, que guarda mensajes. Otra opción es la source System.ServiceModel que guarda eventos del servicio como cuando empeza a escuchar cuando se cierra, etc. Luego le añadimos un listener que definiremos luego, así que por ahora tenemos esto:



<system.diagnostics>
    <sources>
      <source name=”System.ServiceModel.MessageLogging”
              switchValue=”Verbose”>
        <listeners>
          <add name=”MyListener”/>
        </listeners>
      </source>
    </sources>
    <!– … –>
  </system.diagnostics>

Ahora tenemos que definir el listener al que hemos llamado MyListener:



<system.diagnostics>
    <!– … –>
    <sharedListeners>
        <add initializeData=”C:app_tracelog.svclog”
           type=”System.Diagnostics.XmlWriterTraceListener”
           name=”MyListener”
           traceOutputOptions=”None”/>
    </sharedListeners>
</system.diagnostics>

Aquí le indicamos dónde guardar los datos, qué tipo de Listener utilizar y qué opciones quieres usar. Las opciones sirven, por lo que he visto (aún me lo tengo que mirar mejor) , para correlar diferentes peticiones y respuestas de diferentes clientes. En nuestro caso solo tenemos un cliente y no tenemos activada ninguna opción.

Con esto ya tenemos echo nuestro tracing y podemos probarlo.

A nivel de código no tenemos que tocar nada así que ejecutamos nuestro servicio y nuestro cliente como siempre. Cada vez que el cliente y el servicio se comuniquen se guardarán las entradas correspondientes en nuestro archivo de log.

Para poder ver cómodamente el archivo podemos usar una utilidad que viene cuando te instalas el SDK de Windows llamada “Service Trace Viewer”. Si abrimos el fichero con el programa veremos algo así:

trace


A la izquierda podemos escoger las diferentes entradas del log. Ahora solo tenemos dos: la petición y la respuesta. Y a la derecha podemos ver el contenido de la entrada. Si seleccionamos la pestaña de XML podemos ver el mensaje enviado por el cliente haciendo la petición y la respuesta del servicio.


peti


Y la respuesta:


resp


Ahora podéis hacer diferentes pruebas. Por ejemplo, en este caso usaba el binding por net-tcp, si lo usáis con basicHttp podréis ver la cabecera HttpRequest y la del mensaje SOAP.
Podéis hacer un trace a nivel de transporte o añadir seguridad y ver como el mensaje primero está encriptado y luego se desencripta, etc.

En este ejemplo hemos editado el archivo de configuración de nuestro servicio a mano, pero hay una utilidad que te ayuda bastante a hacerlo: Service Configuration Editor. Con Visual Studio 2005 y las extensiones para .NET Framework 3.0 podías acceder a él apretando el botón derecho del mouse encima del fichero .config que querías modificar y escoger la opción adecuada. Con Orcas debes abrirla a parte o, al menos yo no la he encontrado. Está dentro de las utilidades del SDK de Windows. Yo la he añadido al menu Tools del Visual Studio Orcas por comodidad.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *