Una de las primeras cosas que necesitamos saber en cuanto empezamos a programar o a utilizar un nuevo entorno es como depurar los errores. Desde los típicos, y en algunos casos muy útiles, mensajes por pantalla “pasé por aquí”. Hasta cosas más sofisticadas y eficaces como break points y depuradores, librerías para crear logs…etc. Pero, hagamos como lo hagamos, esto siempre es necesario. Así que Dynamics CRM no iba a ser menos, y no sólo a base de mensajes por pantalla eh!
Microsoft CRM 3.0 incluye una serie de métodos de depuración bastante familiares para los desarrolladores de aplicaciones en .NET, y bastante potentes como para poder resolvernos algún error enigmático de la aplicación. El primero de ellos, ya sé que no es propiamente del CRM, es utilizar el entorno de depuración de Visual Studio que para eso está.
Cuando desarrollemos aplicaciones que llamen a los Servicios Web de Microsoft Dynamics CRM 3.0 acordaros siempre de encerrar la llamada en un bloque try catch. Y siempre, independientemente de otras excepciones que necesitéis capturar, poner una sentencia catch específica para SoapException. Ahí os va un ejemplo. Consultar el blog de Rodrigo Corral (que es un fiera en estos temas) para saber más cosas sobre el manejo de excepciones, y buenas prácticas sobre esto.
try {
//hacer algo con CRM service
}
catch (System.Web.Services.Protocols.SoapException e) {
Log(«Detail = » + e.Detail.InnerText + «rnException: » + e.ToString());
}
Vale, este primer método no es propio del CRM. Bueno, pues vamos a ver un segundo método que tampoco lo es. A estas alturas ya sabemos que el cliente web de CRM está construido sobre .NET, por lo tanto es una aplicación ASP.NET. Ya sabéis por donde voy ¿no? Pues claro, como toda aplicación web ASP.NET podemos activar el modo de depuración, para que en vez de mostrarnos ese mensajito tan frustrante de: “Ha ocurrido un error. Contacte con el Administrado del Sistema”, nos dé una excepción de verdad, de las de toda la vida con su traza y todo. Para hacer esto, sólo tenéis que modificar la línea del web.config de la aplicación web del CRM donde aparece DevErrors, poniéndole el valor a On .
<add key=«DevErrors« value=«Off«/>
Eso sí, por favor acordaros de no dejar esto activado una vez el entorno esté en producción.
Bueno y ahora sí un método propio del CRM, los archivos de trazas. Como toda gran aplicación que se precie Microsoft Dynamics CRM 3.0 ha sido diseñado incluyendo en su código sentencias para realizar logs de trazas que pueden ser de gran utilidad. Por ejemplo para encontrar más detalles sobre los fallos de nuestros assemblies de WorkFlow o Call-Outs, o sobre extraños comportamientos en el CRM, o simplemente por que nos pica la curiosidad por saber más del funcionamiento de Dynamics CRM.
Para activar las trazas tenemos que añadir o modificar una serie de valores en el registro de Windows de nuestro Servidor CRM bajo la clave
HKEY_LOCAL_MACHINESoftwareMicrosoftMSCRM
Nombre |
Tipo |
Valor |
TraceEnabled |
dword |
1 (0 para inhabilitarlo) |
TraceDirectory |
string |
Path completo a un directorio EXISTENTE donde almacenar los archivos de trazas. ¡El CRM no lo crea! |
TraceCategories
|
string
|
«*:Verbose» (sin las comillas).
En vez de verbose puede especificar niveles más restrictivos para contener el tamño del archivo: Info, Warning, Error.
En vez de * se pueden indicar que partes del sistema nos interesa logear: Application, SchedulingEngine, etc, y subcategorías de estas. Consultar el artículo relacionado para más información |
TraceCallStack |
dword |
1 (para incluir la pila de llamadas) |
TraceRefresh |
dword |
1 |
Podeis encontrar más información sobre la activación de logs de trazas y su configuración en el artículo de la Knowledge Base “How to enable tracing in Microsoft Dynamics CRM 3.0”. Incluso hay información sobre como activar estas trazas para clientes Outlook, muy útil si tenemos que depurar estos clientes.
Una vez habilitado, Los componentes de Dynamics CRM empezarán a escribir los logs en ficheros de trazas en el directorio indicado. Un fichero para la aplicación web, otro para el servicio de workflow, y otro para los servicios web.
Para los alumnos aventajados, el fichero más curioso de todos es el de los servicios web. En el podréis comprobar cómo Dynamics CRM utiliza los servicios web “privados”, vamos todos los demás servicios web que tiene a parte de CRMService y MetadataService. Así queda totalmente demostrado que los propio clientes de Dynamics CRM utilizan los servicios web para comunicarse con el servidor. Aunque esto servicios no sean los mismo que los que tenemos disponibles a través del SDK. Podéis curiosear en la carpeta MSCRMServices la cantidad de archivos .asmx que hay.
Bueno y para finalizar, deciros que tampoco hay que olvidar echar un vistazo al registro de eventos del sistema. Por que Microsoft Dynamics CRM 3.0 también muestra bajo el log de Aplicación mucha información importante sobre errores. Por ejemplo el Exchange Router informa ahí de los motivos por los que no promociona un determinado mail al CRM.
Sólo deciros una cosilla más. Los ficheros de log de las trazas son un auténtico coñazo de ver “a pelo”. Pero en el próximo post os enseñaré una herramientilla que nos viene de perlas para ver estos ficheros de forma comprensible por humanos, e incluso en remoto.
Bueno, el que haya leído hasta aquí es que de verdad está interesado en Microsoft Dynamics CRM. Así que tiene todo el permiso del mundo para comentarme sus opiniones sobre este artículo, sobre el blog, sobre el CRM, y hasta sobre el tiempo si no se os ocurre otra cosa.
Saludos, y hasta la próxima
Marco Amoedo Martínez
