Mes: noviembre 2006

Recientemente Google ha comenzado un nuevo servicio muy interesante que consiste en la posibilidad de poder crear buscadores personalizados. El servicio se llama Google Co-op y permite que cada usuario pueda crear un buscador especializado en sus intereses, indicando los sitios relevantes en los que buscar y cosas por el estilo.

Como la idea me ha parecido muy buena, he decido probar a crear un buscador personalizado para Microsoft Dynamics CRM 3.0. Este buscador permite que utilicemos la potencia de google para buscar información sobre nuestra herramienta CRM favorita obteniendo unos resultados más precisos. Básicamente lo que he hecho ha sido personalizar el buscador para que realice las búsquedas sobre páginas web relacionadas con Microsoft CRM 3.0 (blogs, msdn, la KB, grupos de noticias, etc), y parece que funciona más o menos bien. Por lo menos, a mi me sirve para poder obtener unos resultados más precisos en las busquedas sobre información relacionada con Microsoft CRM.

Bueno, probad Microsoft CRM Search (hay también un enlace en el panel de la derecha) y dadme vuestra opinión, indicadme sitios para incluir en las búsquedas que echeis en falta, etc…

Un saludo,

Marco Amoedo.

Después de una semanita sin postear nada, he estado bastante liado en varios proyectos que tenemos entre manos, retomamos el tema de los callouts en Microsoft Dynamics CRM 3.0. En el post anterior de esta serie vimos los conceptos básicos de los callouts, hoy intentaremos explicar los dos tipos de callouts de los que disponemos y sus diferencias.

Pre-Callouts

Un pre-callout es un callout invocado por la plataforma de Microsoft CRM antes de la ejecución del evento para el que se ha registrado. Esto quiere decir, que antes de que el CRM realice la operación se ejecutará nuestra callout, dándonos la posibilidad de insertar la lógica que queramos antes de que se produzca la ejecución de la operación en Microsoft CRM.

El código de los pre-callouts (al igual que el de los post-callouts) se ejecuta de manera síncrona. Esto significa que el sistema inicia la ejecución del código del callout y espera a que se complete su ejecución antes de continuar con la ejecución de algún otro pre-callout registrado para el mismo evento o ejecutar la operación de Microsoft CRM que lo ha disparado. Este modelo de ejecución nos permite, como veremos, realizar modificaciones sobre los datos dirigidos a la operación de Microsoft CRM. Pero también tiene una contrapartida que debemos tener muy en cuenta. Al insertar un callout estamos aumentando el tiempo de ejecución de la operación de Microsoft CRM, por lo que debemos tratar de optimizar nuestro código para evitar introducir demasiada latencia en las operaciones. E incluso, lanzar ejecuciones asíncronas en otro Thread siempre que sea posible.

Cuando un pre-callout es invocado, el sistema le pasa el conjunto completo de atributos de la entidad involucrada en la operación, pero solo los atributos con un valor distinto de nulo, el contexto de la entidad y el contexto de usuario. El pre-callout puede modificar el conjunto de atributos y devolvérselos al sistema. Además, el pre-callout tiene la posibilidad de indicar devolverle instrucciones al sistema sobre la ejecución de la operación, indicándole si continuar, si no ejecutar más callouts del mismo evento, o si abortar la ejecución de la operación de Microsoft CRM. Incluso, es posible devolver un mensaje de error, el cual será mostrado al usuario si el callout le pide al sistema que aborte la ejecución. La siguiente imagen obtenida del SDK de Microsoft CRM ilustra el modelo de los pre-callouts.

Si hay más de un pre-callout registrado para el mismo evento, el sistema los invoca de manera secuencial. Los contextos de entidad y usuario serán los mismos en cada invocación, pero el conjunto de atributos puede variar, ya que cada callout puede modificarlos.

Ejemplo de firma de un pre-callout:

public virtual PreCalloutReturnValue PreCreate(
CalloutUserContext userContext,
CalloutEntityContext entityContext,
ref string entityXml,
ref string errorMessage
);

Post-Callouts

Los post-callouts son invocados una vez se ha completado con éxito la ejecución de la operación en el sistema, es decir, si por algún motivo falla la ejecución de la operación del sistema los post-callouts no se ejecutan. Y al igual que ocurre con los pre-callouts, no tenemos límite en el número de post-callouts a registrar para un evento, estos se ejecutarán de forma secuencial.

Una diferencia clave con respecto a los pre-callouts, es el conjunto de atributos de la entidad que reciben. En este caso, debemos de especificar en la configuración del callout que atributos de la entidad queremos recibir. Y además tenemos dos conjuntos de atributos de la entidad, los pre-values que son los atributos que tenía la entidad antes de ser procesada por el sistema, y los post-values que son los valores de los atributos de la entidad una vez que esta ha sido procesada por el sistema. Por lo tanto debemos de indicar que conjunto de atributos previos necesitamos, y que conjunto de valores posteriores necesitamos.

Como ya mencionamos, los post-callouts también se ejecutan de forma síncrona con el sistema aunque en este caso no es posible indicar instrucciones sobre la ejecución ya que no hay ningún valor de retorno (no podemos detener la ejecución de callouts, abortar….) Y es aquí donde se hace más relevante el buscar modelos de ejecución asíncrona en nuestro código, ya que al no poder influir sobre el resultado de la operación en el CRM no tiene sentido aumentar el tiempo de ejecución. Por ejemplo, si pensamos en un post-callout que escriba un log de modificaciones de datos de entidades, lo lógico sería que el código del callout lancemos un thread que haga el trabajo para retornar la ejecución lo antes posible a Microsoft CRM.

Ejemplo de firma de un método de post-callout.

public virtual void PostUpdate(

CalloutUserContext userContext,

CalloutEntityContext entityContext,

string preImageEntityXml,

string postImageEntityXml

); 

Pre vs Post

Ahora que ya tenemos más o menos claro el concepto de pre-callout y el de post-callout ¿Cuándo utilizamos los pre y cuando los post?

Pues como siempre, depende. Pero como norma general, los pre-callouts estarán indicados para aquellas situaciones en las que necesitemos poder modificar el conjunto de datos que recibe una operación de Microsoft CRM o evaluar este conjunto para influir sobre la ejecución de la operación. Por ejemplo, comprobación de duplicados, atributos calculados, validación de datos, etc. Mientras que los post-callouts estarán indicados para situaciones en las que no necesitemos influir sobre los atributos o sobre la ejecución de la operación y en las que necesitemos estar seguros que la operación ha sido realizada. Como por ejemplo, log de modificaciones, sincronización con otros sistemas, etc.

En la siguiente entrega

En el siguiente post de la serie veremos cómo desarrollar un pre y un post-callout, y cómo registrarlos estableciendo las configuraciones adecuadas en el fichero callout.config.xml. Pero ya os adelanto que para desarrollar un callout disponemos de una clase base de la que tendremos que heredar y redefinir el evento(s) que queramos manejar.

Si queréis ver más cosas y no podéis esperar al siguiente post, en el SDK de Microsoft CRM 3.0 tenéis disponible muchísima información sobre los callouts y su desarrollo.

Espero vuestro comentarios y sugerencias, un saludo.

Marco Amoedo

El otro día me plantearon esta cuestión ¿Cómo puedo hacer que los valores de un picklist (lista desplegable) varíen en función de los valores de otro picklist? Al recibirla me puse a pensar, y recordé que en alguna parte había visto un ejemplo de cómo conseguir esto. Así que me puse a buscar donde lo había visto para responder a la pregunta. Después de un rato buscando, encontré esta entrada del blog de Ben Vollmer donde explicaba cómo conseguirlo.

La solución que proponía Ben Vollmer está muy bien, de hecho, me parece una de las formas más elegantes de conseguirlo. Pero al probarla descubrí un pequeño problema, nada grave, que consistía en que al abrir un registro en modo de actualización un registro se perdía la selección hecha en la lista dinámica. Así que basándome en la idea y el código de Ben Vollmer he creado un ejemplo sobre cómo conseguir picklist dinámicos solucionando ese pequeño problemilla.

¿Qué es un picklist dinámico? Básicamente es hacer que las opciones que se presentan en un picklist varíen de forma dinámica según alguna opción que elija un usuario (otro picklist, checkbox, etc…). Por ejemplo, tenemos un picklist donde se puede elegir el sector al que pertenece una cuenta y otro en el que podemos elegir el subsector. La idea es que al elegir un sector en el picklist de subsectores solo se muestren los que correspondan a ese sector. En este ejemplo haremos esto, es decir, que varíen las opciones de un picklist en función de otro picklist, pero la idea sería la misma en otras situaciones.

Antes de seguir, decir que al final del post podéis encontrar un enlace para descargaros la demos (código y personalizaciones).

Para construir nuestro ejemplo vamos a crear una entidad nueva en el CRM llamada «Demo Picklist», y le vamos añadir dos campos de tipo picklist: uno llamado «lista» y otro «sublista». Como es evidente, el objetivo es que las opciones que se muestran en la sublista varíen según la opción seleccionada en la lista. Al crear los picklist debemos indicar todas las opciones disponibles en la lista y en la sublista, pero es muy importante que las de la sublista vayan en orden con respecto a las de la lista, tal y como vemos en la siguiente tabla.

Como se ve en la tabla, por cada opción de la lista tenemos una serie de opciones correspondientes en la sublista. Es muy importante que las opciones de la sublista vayan agrupadas (ordenadas) en función de la opción de la lista a la que pertenecen para facilitar el trabajo posterior de filtrar opciones a mostrar en la sublista.

Bien, ya tenemos creados los picklist y los hemos añadido al formulario ¿Qué código JScript necesitamos para hacer funcionar el invento? Lo primero será añadir código al onload() del formulario para poder hacer las inicializaciones necesarias. En este código debemos de hacer una copia del conjunto completo de opciones de la sublista para poder recuperar en cada momento las que necesitemos, para ello copiamos el valor de la propiedad Options en la propiedad originalPicklistOptions, así podremos recuperarlas cuando nos hagan falta. Además, si ya tenemos seleccionado un valor en la lista debemos de limitar el conjunto de opciones de la sublista (llamando al onchange de la lista, como veremos más adelante) y si no deshabilitarla. Básicamente es lo que hace el siguiente código.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

var CRM_FORM_TYPE_CREATE = 1;
var CRM_FORM_TYPE_UPDATE = 2;

// Solo habilitamos el picklist dinamico para formularios de creacion o
// actualizacion, para el resto no es necesario.
switch (crmForm.FormType)
{
  case CRM_FORM_TYPE_CREATE:
  case CRM_FORM_TYPE_UPDATE:

    // Obtener referencia a la lista maestra
    var lista = crmForm.all.new_lista;
    // Obtener referencia a la sub lista
    var sublista = crmForm.all.new_sublista;

    // Guardamos el conjunto completo original de opciones de la sublista
    // utilizando la propiedad originalPicklistOptions
    sublista.originalPicklistOptions = sublista.Options;

    // Si no hay ningun valor seleccionado en la lista
    // deshabilitamos la sublista. Se volvera a habilitar
    // cuando el usuario seleccione un valor
    if (lista.DataValue == null)
    {
      sublista.Disabled = true;
    }
    else
    {
      // Ya tenemos seleccionado un valor, debemos limitar el conjunto
      // de iopciones de la sublista. Para ello disparamos el evento
      // onchange de la lista.

      // Almacenamos el valor seleccionado en la sublista
      var temp = sublista.DataValue;
        
        // Disparamos el onchange para limitar las opciones
      new_lista_onchange0();
      
      // Volvemos a fijar la opcion que estaba seleccionada
      sublista.DataValue=temp;
    }

  break;
}

Nota: El problema, que tenía el código de Ben Vollmer era que le faltaban las líneas 29 y 35, lo que hacía que cuando estábamos en un formulario de actualización se perdiese la opción seleccionada en la sublista.

Ahora tenemos que escribir el código para el onchage de lista. Este código se encargará de que cada vez que se modifique el valor seleccionado en la lista se establezcan las posibles opciones en la sublista. Gracias a que introducimos en orden los valores de la sublista, lo que tenemos que hacer es elegir un subarray del array original de opciones de la sublista (que en el onload convenientemente copiamos a la propiedad originalPicklistValue) basándonos en la opción seleccionada en la lista. Por ejemplo, para la opción 1 de la lista el array sería del elemento 1 al 3. Y una vez que tenemos el array no hay más que asignárselo al array Options de la sublista. ¡Y listo¡ Ya tenemos picklist dinámico. El código es el siguiente.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

// En funcion de el elemento seleccionado en la lista, escogeremos las opciones que se muestran
// en la sublista. 
var lista = crmForm.all.new_lista;
var sublista = crmForm.all.new_sublista;
var comienzo = -1;
var fin = -1;

// Para facilitar la tarea las opciones de la sublista estan agrupadas en orden de correspondencia
// con las opciones de la lista, así que solo tenemos que elegir un rango de opciones de la 
// sublista en función de las opcion de la lista
switch (lista.DataValue)
{
  case «1»:
    comienzo = 1;
    fin = 3;
    break;

  case «2»:
    comienzo = 4;
    fin = 6;
    break;
    
  case «3»:
    comienzo = 7;
    fin = 8;
    break;
}


// Si tenemos indices limitamos las opciones de la sublista
if (comienzo > -1 && fin > -1)
{
  // Creamos un array temporal donde almacenar las opciones
  var tempArray = new Array();

  // Inicializar indice para el array temporal
  var indice = 0;

  // Ahora recorremos la lista original de opciones de la sublista que 
  // cacheamos en el onload del formulario y recogemos las que 
  // perteneces a la opcion seleccionada en la lista
  for (var i = comienzo; i <= fin; i++)
  {
    tempArray[indice] = sublista.originalPicklistOptions[i];
    indice++;
  }

  // Copiamos el subconjunto de opciones seleccionado
  sublista.Options = tempArray;

  // Habilitamos la sublista
  sublista.Disabled = false;
}
else
{
  // No se ha seleccionado una opción en la lista, o la opcion no es valida
  sublista.DataValue = null;
  sublista.Disabled = true;
}

Para facilitar la labor, os dejo un zip con el código, y un fichero xml con la personalización de prueba para que podáis importarla en vuestro sistema y ver el funcionamiento. Y ahora os digo lo típico (es que me hace ilusión ponerlo): Este código se proporciona tal cual, sin garantía de ningún tipo. No es recomendable utilizarlo en un sistema en producción sin haberlo probado primero. Y leed el leeme.doc.

¿Qué os parecen los picklist dinámicos? ¿Algún bug en el código? Espero vuestras opiniones, correcciones, etc..

Un saludo,

Marco Amoedo

Introducción

Este es el primer post de lo que espero sea una serie de post dónde tratar de recopilar información sobre callouts en Microsoft CRM 3.0. El objetivo final es tratar de hacer un tutorial (en castellano) sobre los callouts en Microsoft CRM 3.0. Intentaré cubrir todos los temas relacionados con los callouts, pero os animo a que si echáis en falta algo me lo comentéis para incluirlo. Así mismo, me gustaría recibir vuestros comentarios sobre cada post que vaya publicando para corregir los errores que encontréis, o cualquier otra sugerencia que queráis hacer.

Pues, ¿empezamos?…

El Concepto

La idea de los callouts en Microsoft CRM 3.0 es proporcionar un mecanismo, más o menos sencillo, para personalizar la lógica de negocio del CRM. Es decir, poder modificar o extender el comportamiento de las operaciones de negocio básicas del CRM.

Una forma de ver los callouts es pensar en eventos. Podemos pensar que Microsoft CRM 3.0 nos proporciona unos puntos de extensión en forma de eventos a los que nos podemos subscribir. Así, los callouts son como unos manejadores de eventos que cumplen un determinado interfaz y que se ejecutan cuando el CRM dispara el evento para el que lo hemos subscrito. Además, como Microsoft CRM 3.0 está creado sobre .Net, podemos utilizar cualquier lenguaje disponible en .Net (.Net CLR-Compilant).

La arquitectura

El modelo de los callouts de CRM 3.0 sigue una arquitectura bastante sencilla e intuitiva, lo que los convierte en una herramienta de extensión muy efectiva. Para empezar, disponemos de dos tipos de callout: los pre-callouts y los post-callouts. Los pre-callouts son aquellos que se ejecutan antes de que se realice la operación de negocio, mientras que los post-callouts se ejecutan después de que se ha completado la operación de negocio. La siguiente imagen, obtenida del SDK de Microsoft CRM 3.0, ilustra este concepto.

Cuando se solicita la ejecución de una operación de negocio, ya sea a través de un cliente de Microsoft CRM, de alguna herramienta de Microsoft CRM como el Administrador de implementaciones, o a través de terceras aplicaciones utilizando los servicios web del CRM, el servidor de Microsoft CRM se encarga de ejecutar uno a uno el código de los pre-callouts que hayamos registrado para esa operación. Una vez ejecutados todos exitosamente sin que ninguno de ellos indicase que se debe abortar la operación, el Servidor de Microsoft CRM ejecuta la operación de negocio. Cuando ha terminado la ejecución de la operación de negocio, Microsoft CRM comienza la ejecución uno a uno de los post-callouts registrados para la misma. Una vez terminado el proceso devuelve el resultado al solicitante de la operación. Para el solicitante de la operación (cliente del CRM, herramientas del CRM, o terceros) la ejecución de los callouts es totalmente transparente, en ningún momento tienen conocimiento de que se está ejecutando código personalizado.

A continuación tenéis la lista de tipos de callouts disponibles en Microsoft CRM 3.0. Pero hay que recordar, que no todos los tipos de callouts están disponibles para todas las entidades. Cada entidad tiene disponible un subconjunto de esta lista, podéis consultar la lista completa de callouts por entidad en esta página del SDK.

Como podéis ver tenemos disponibles, más o menos, un pre y un post callout por cada tipo de operación básica del CRM. Hay que destacar que no existe limitación en cuanto al número de callouts que podemos subscribir a un evento, el servidor ejecutará secuencialmente todos los que se encuentre subscritos al evento disparado.

Los callouts reciben parámetros (marcados por un interfaz) cuando son invocados por el Servidor de Microsoft CRM, y pude devolver resultados al mismo. Los parámetros y valores de retorno disponibles dependen del tipo de callout. Pero en general reciben información sobre la instancia que genera el evento, el usuario que ha solicitado la ejecución y puede devolver modificaciones sobre los datos de la instancia y decisiones sobre la ejecución de la operación (pudiendo incluso abortarla).

Aplicaciones de los Callouts

Aunque no creo que haga falta explicar la utilidad de este mecanismo de personalización de la lógica de negocio del CRM, voy a proponer un par de ejemplos que a lo mejor ayudan a verle la utilidad.

Imaginad que necesitáis auditar los cambios que se realizan sobre los datos contenidos en el CRM y quien los realiza. En este caso los callouts son una buena solución. Podemos registrar post-callouts para todos los eventos que nos interese auditar y que estos se encarguen de escribir un registro de modificaciones. (En este post ya habíamos tratado este tema)

O pensad que necesitamos recoger ciertos datos adicionales al crear una nueva cuenta en Microsoft CRM, o simplemente comprobar si ya está duplicada. En este caso, un pre-callout puede ser la solución.

En el siguiente post….

En el siguiente post veremos las diferencias existentes entre los pre-callouts y los post-callouts, los interfaces disponibles para los callouts, la información que podemos recibir y devolver, y los pasos básicos necesarios para registrar un pre-callout y un post-callout en Microsoft CRM 3.0.

Espero vuestras sugerencias y comentarios,

Un saludo,

Marco Amoedo

El fin de semana pasado estuve en el Code Camp en Madrid, donde tuve la suerte de poder conocer en persona a mucha gente del mundillo y a muchos compañeros de Geeks.ms, y sobre todo de aprender de ellos y compartir charlas muy interesantes. El caso es que hubo un par de veces que me preguntaron qué era eso del CRM, y la verdad, es que no es trivial dar una explicación clara y concisa. Y como creo que un ejemplo vale más que mil definiciones, voy a intentar hacer un pequeño símil que resuma la esencia de lo que es CRM y las herramientas CRM.

Muchas veces, comprar en una pequeña tienda de barrio al lado de tu casa es una experiencia mucho más satisfactoria que ir a una gran tienda de un centro comercial por la sencilla razón de que recibes un servicio mucho más personal. El tendero de al lado de tu casa conoce tu nombre y sabe los suficiente de ti como para conocer tus necesidades y poder ofrecerte un servicio personalizado. Mientras que en las grandes superficies, el trato es mucho más impersonal y menos ajustado a tus necesidades.

La personalización del trato es algo muy difícil de mantener a medida que una organización crece en tamaño y operaciones. Esto se debe en gran medida a que el número de clientes crece en proporción, lo que hace muy complicado atender a cada uno de ellos de forma individualizada como cuando la organización es más pequeña. Sin embargo, hoy en día está más que claro que a todos nos gusta recibir un trato cercano, a nadie le gusta ser un número más, y que cuando una empresa te trata de un forma más personalizada lo notas y te sientes más cómodo comprando sus producto o servicios. Es aquí donde entran en juego las estrategias CRM y los sistemas de información que las soportan.

Para poder dar ese trato, que nuestro tendero consigue sin más ayuda que la de su memoria y su sonrisa, las compañías necesitan sistemas de información que permitan almacenar la información sobre sus clientes y explotarla para conseguir darles esa personalización en la atención. Y no sólo se trata de datos personales, e información sobre las transacciones que ha realizado con la empresa, si no que debemos ser capaces de manejar cosas más abstractas como sus preferencias horarias, gustos, etc. A partir de esto es donde surge la necesidad de las herramientas de gestión de las relaciones con los clientes, para poder conseguir la personalización en el trato al cliente en cualquier interacción que realicen con la empresa por muy grande que esta sea.

Las ventajas que proporcionan las herramientas CRM, bien utilizadas, están claras desde el punto de vista del cliente: una personalización que hace la experiencia del trato con la empresa más agradable y adecuada a sus necesidades ¿Pero qué pasa desde el punto de vista empresarial? Volviendo a los ejemplos, imaginad al vendedor de prensa del barrio. Como conoce los hábitos de sus clientes, sabe que el domingo la gente compra más periódicos que por la semana ya que tienen tiempo para leerlo tranquilamente en su casa, así que los domingos encarga al distribuidor un mayor número de ejemplares. Además sabe que Juan, uno de sus clientes, es un fan de la novela de ciencia-ficción, así que cuando viene a comprar el periódico le ofrece la última novela de este tipo que ha salido al mercado. Y que a Pedro le encanta viajar, así que le recuerda que este fin de semana el periódico incluye por 3€ más un libro sobre viajes por el Norte de España. O pensad en el panadero, como por la semana la mayoría de sus clientes comen fuera de casa vende menos pan, pero sabe que los domingos sus clientes compran más pan, y más bollería para desayunar tranquilamente mientras leen el periódico en su casa. Además sabe que a Juan le encanta la empanada y cuando hace alguna le ofrece. O los bares cuando retransmiten un partido de fútbol, o la frutería cuando es la temporada de las fresas… etc.

Está claro, conocer a sus clientes les ha servido para adaptarse a sus demandas, y poder maximizar sus beneficios. Han podido ajustar su oferta a las necesidades de sus clientes, y además, gracias a conocer sus gustos y sus hábitos, han podido obtener mayores beneficios al poder cubrir necesidades no explícitas. Las herramientas CRM tratan de conseguir algo similar pero a mayor escala, de permitirle a una gran superficie conocer los hábitos de sus clientes, y además personalizar el trato para que si a Juan le gusta comprar vinos de gran reserva le envíen una invitación a una cata de vinos o información sobre nuevos vinos disponibles. O para que cuando Pedro acuda al servicio técnico de una gran superficie de informática con un ordenador al que se le ha fastidiado su disco duro, el que lo atienda sepa que se lo ha comprado hace menos de dos meses, por lo que debe ser un defecto de fábrica, y que además Pedro tiene capacidad de decisión sobre las adquisiciones de material informático de su empresa, por lo que decida ofrecerle un servicio de reparación express sin coste adicional.

Bueno, espero que este ejemplo sobre lo que es CRM os haya servido de algo, os recomiendo que leáis este otro ejemplo de John Strauman sobre el mismo tema, y espero vuestros comentarios.

Un saludo,

Marco Amoedo