Integración de Dynamics CRM 2013 con Microsoft Azure

Microsoft Dynamics CRM 2013 no debería funcionar como una plataforma aislada, sino como parte de un ecosistema donde debe tener algún nivel de integración con otros sistema como, por ejemplo, la plataforma de ERP de la organización que lo usa. Una forma de implementar dicha integración es cableando explícitamente los puntos de integración con cada uno de los otros sistemas, con el riesgo de tener que revisar todo cuando alguno de los sistemas cambie. Otra forma es aflojar el acoplamiento usando un intermediario cuya responsabilidad sea recibir actualizaciones del CRM (por ejemplo, se creó un nuevo caso, se desactivó una cuenta, se adicionó un contacto a una cuenta) y distribuirlas entre los componentes relevantes del ecosistema. Este es el mecanismo que discutiremos aquí a través de Microsoft Azure.

• Dos formas de integración con Microsoft Azure
• Extensiones de Azure para Microsoft Dynamics CRM
• Colas del Bus de servicios de Azure
• Colas de Azure

Dos formas de integración con Microsoft Azure

Hay varias formas de implementar la intermediación entre aplicaciones a través de Microsoft Azure. Aquí vamos a comparar dos enfoques diferentes: a través de las extensiones de Azure para Dynamics CRM y a través de colas del Bus de servicios de Azure. La diferencia fundamental es que el primer enfoque se basa en un plugin convencional que usa su contexto genérico para pasar información a Azure, mientras que el segundo envía peticiones REST de más bajo nivel a la cola de Azure con exactamente los datos que requiere la operación. 

La ventaja obvia del enfoque de las extensiones de Azure para Dynamics es que es más familiar para el desarrollador acostumbrado a usar plugins, lo que le permite salir a producción más rápido que si tiene que aprender a interactuar a más bajo nivel con Azure. Por otro lado, la ventaja de usar directamente las colas de Azure es que con grandes volúmenes de datos e interacciones frecuentes se va a obtener un mejor desempeño al tener mayor control sobre qué se envía, cómo y cuándo.

Extensiones de Azure para Microsoft Dynamics CRM

Microsoft Dynamics CRM 2013 (tanto Online como OnPremises) puede integrarse con Azure acoplando el flujo de ejecución de eventos del CRM al bus de servicios de Azure. Dicha conexión permite que los datos que están siendo procesados como parte de la operación actual del CRM puedan ser publicados en el bus. Las soluciones del bus de servicios de Azure que estén suscritas al CRM pueden estar alerta y, cuando lleguen publicaciones del CRM al bus, leer sus datos, que son almacenados en una instancia remota del contexto de ejecución pasado en tiempo real a los plugins asíncronos del CRM.

La operación arranca con un plugin, que puede ser de alguna de las dos clases de plugins asíncronos soportadas por la funcionalidad de integración: de caja (OOB o Out Of Box) o personalizados.

El CRM ya trae en la caja un plugin habilitado para Azure (Azure-aware), que se ejecuta con confianza total (full trust) en el CRM. La idea es incluir un paso en este plugin que identifique la entidad y mensaje de destino para que, una vez registrado en el CRM, el plugin pueda notificar al servicio asíncrono para que éste publique el contexto remoto de ejecución en el bus de servicios de Azure.

También es posible escribir plugins personalizados habilitados para Azure, los cuales se ejecutan con confianza parcial (partial trust) en entorno protegido (sandbox). Ver Write a custom Azure-aware plug-in.

Del otro lado, se necesita que al menos una solución conteniendo uno o más extremos de servicio (endpoints) esté escuchando en una cuenta de solución del bus de servicios de Azure. Si el contrato del extremo de servicio no es de cola, debe escuchar activamente, mientras que si es de cola no necesita hacerlo porque los mensajes se van almacenando hasta que sea el turno del extremo de servicio para procesarlos. 

Colas del Bus de servicios de Azure

El bus de servicios de Azure soporta dos esquemas de mensajería: el original síncrono por retransmisión (relayed messaging) y el actual asíncrono que es gestionado (brokered messaging). La principal desventaja del primer esquema es que exige que ambos participantes de la comunicación (emisor y receptor) estén en línea en el momento de la conexión, lo cual motivó la creación del esquema gestionado. Este último almacena los mensajes enviados por el emisor hasta que el receptor está disponible para procesarlos. La ventaja obvia es la nivelación de la carga, ya que el receptor no necesita reservar costosos recursos para estar en capacidad de procesar incluso las solicitudes que le envíen los emisores en un pico de mucha congestión, sino que el intermediador dosifica esas solicitudes a un ritmo que el destinatario puede procesar con menos recursos.  

Aquí es donde entran en escena las colas que a través de una política FIFO (First In, First Out) entregan mensajes, en el mismo orden en que llegaron, a uno o más receptores. Su longitud crece y se contrae en la medida en que la carga entrante varía. Este uso de las colas para mediar entre emisores de mensajes y consumidores brinda un bajo acoplamiento inherente entre los componentes, ya que al no conocer los detalles de los demás componentes, un receptor puede ser mejorados sin tener efecto alguno sobre los emisores (y viceversa).

En adición a las colas, el equema de mensajeria gestionado también ofrece suscripciones que permiten la comunicación uno-a-muchos en un patrón de "publicar/suscribirse". Es especialmente útil para escalar a un número muy grande de receptores, donde cada mensaje publicado queda disponible para cada suscriptor que se haya registrado en el "tema". Los mensajes son enviados a un tema y entregados a uno o más suscripciones asociadas, dependiendo de reglas de filtrado que se definen por cada suscripción. Las suscripciones pueden usar filtros adicionales para restringir los mensajes que quieren recibir. El emisor envía mensajes a un tema como si estuviera enviándolo a una cola. Las suscripciones actúan como colas virtuales que reciben copias de los mensajes que fueron enviados al tema (si pasan los filtros de la suscripción) y desde las cuales los receptores pueden consumir mensajes como lo harían con una cola.

Colas de Azure

Finalmente tenemos las colas de la infraestructura de almacenamiento de Azure, que estarían a más bajo nivel que las colas del bus de servicios de Azure. Éstas ofrecen una interfaz simple Get/Put/Peek basada en REST que implementa mensajería persistente y confiable dentro de un servicio o entre servicios. Las colas de Azure deberían usarse en lugar de las colas del bus de servicios cuando:

• Nuestro CRM debe almacenar más de 80G de mensajes en una cola, donde los mensajes deben persistir por menos de 7 días.
• Nuestro CRM hace seguimiento al avance en el procesamiento de un mensaje al interior de la cola. Esto es útil si el proceso que está trabajando en un mensaje fallece. El proceso que venga después puede usar esa información para retomar el trabajo donde el proceso anterior lo dejó.
• Nuestro CRM requiere registros de log del lado del servidor para todas las transacciones ejecutadas contra las colas.  

Reglas de enrutamiento en Microsoft Dynamics CRM 2013 SP1

Como ya vimos, la versión 2013 SP1 de Microsoft Dynamics CRM trae nuevas funcionalidades que se pueden instalar después de la actualización de junio de 2014. En esta ocasión nos concentramos en la definición paso a paso de reglas de enrutamiento de casos, que facilitan la definición de a quién se debe asignar un caso dependiendo de las condiciones en cada punto del proceso de atención.

1. Crear nuevo conjunto de reglas
2. Adicionar elementos de regla
3. Activar conjunto de reglas

Crear nuevo conjunto de reglas

Los conjuntos de reglas de enrutamiento se definen en soluciones. Hay que evitar en lo posible personalizar directamente la instancia del CRM o a través de la solución predeterminada, que es prácticamente lo mismo. En su lugar, recomiendo crear una nueva solución no administrada o modificar una ya existente:

Ir a CONFIGURACIÓN / Soluciones / Nuevo (o seleccionar una solución no administrada ya existente).

Ir a Conjuntos de reglas de enrutamiento y dar click en "Nuevo".

Se abre una nueva ventana para definir el nuevo conjunto de reglas. Llenar el nombre y la descripción para der una idea precisa de el alcance y la intención del conjunto de reglas a quienes deban hacer mantenimiento a los procesos del sistema en el futuro. Click en "GUARDAR" para grabar el registro y habilitar la asociación de subregistros.

Después de grabar, aparece en la sección "Elementos de regla" habilitado el botón "+". Click en el botón para adicionar un nuevo elemento de regla.

Adicionar elementos de regla

Se abre una nueva ventana para definir un elemento de regla. Llenar Nombre obligatoriamente para poder grabar el nuevo registro. Es muy recomendable llenar también la descripción para ubicar a quienes deban mantener el proceso a futuro aunque el campo no sea obligatorio.

Una vez definido el encabezado, ir a la sección "Condiciones If" de Criterios de Regla para llenar las condiciones. Estas condiciones se pueden agrupar en bloques "AND" y "OR".

Para cada condición se selecciona la entidad a la que corresponde el campo a evaluar. La selección está restringida a Caso (Incident) o a alguna entidad con la que Caso tenga una relación.

Una vez definida la entidad, seleccionar el campo, el operador y el valor. En este ejemplo, seleccionamos la entidad Caso, el campo "Tipo de Solicitud", el operador "Es igual a". Como el campo corresponde a una relación con una entidad personalizada, en la pantalla aparece un botón de búsqueda para seleccionar un valor específico. 

Aparece una ventana para buscar registros. Como se puede definir más de un registro como valor de la condición, además de marcar uno o más registros en el listado hay que dar click en el botón "Seleccionar" para incluir los registros resaltados en la sección de "Registros seleccionados". Una vez hemos definido al menos un valor, podemos dar click en el botón "Agregar".

Una vez se ha definido la primera condición, podemos definir otras condiciones adicionales (implícitamente se relacionan con la primera condición a través de un operador "AND"). En este ejemplo adicionamos una segunda condición con la entidad Caso, el campo personalizado "Estado de Documentación", el operador "Es igual a". Como este campo no corresponde a una relación con registros de otra entidad sino a una lista de opciones, la pantalla no muestra un botón de búsqueda sino uno de selección de valores:   

Para seleccionar un valor de una lista de opciones, dar click en un valor de la columna "Valores disponibles", click en el botón ">>" para pasar el valor resaltado a la columna "Valores seleccionados" (puede ser más de uno). Finalizamos con click en el botón "Aceptar".

Una vez definidas todas las líneas en la sección "Condiciones If", pasar a la sección "Condiciones Then". Seleccionar si el enrutamiento será a una Cola o a un Usuario/Grupo. Si es este último caso, solamente se pueden usar grupos propietarios, no de acceso.

Después de marcar el tipo de asignación, click en el botón de Búsqueda de registros. 

De la lista seleccionar un valor y dar click en el botón "Guardar" para grabar el nuevo elemento.

Activar conjunto de reglas

Una vez hayamos definido todos los elementos de regla para este nuevo Conjunto de reglas de enrutamiento, hay que activar el registro dando click en el botón "Activar" de la barra de comandos. El sistema pide confirmación y se responde con click en el botón "Activar" del diálogo emergente. 

Cuando el registro tenga su estado en "Activo" será evaluado por el sistema cada vez que se grabe un registro de la entidad Caso.

Como la definición de este Conjunto de reglas de enrutamiento se hizo sobre una solución no administrada, para que sea visible para los usuarios del sistema hay que publicar los cambios. Ir a la solución y dar click en el botón "Publicar todas las personalizaciones". 

Instalación y creación de SLA en Dynamics CRM 2013 SP1

Microsoft Dynamics 2013 SP1 trae nuevas funcionalidades interesantes, entre las que destaco en esta oportunidad la implementación nativa de contratos de niveles de servicio o SLA (Service Level Agreement). Vamos a ver cómo instalar y crear nuevos SLAs nativos paso a paso.

1. Instalación de la actualización de productos
2. Creación de nuevo SLA
3. Creación de condiciones del SLA

1. Instalación de la actualización de productos

Los SLA nativos no vienen predeterminadamente con el Service Pack. Es necesario pedir al administrador del servidor que active las actualizaciones de Windows Update para que Dynamics pueda encontrar y descargar los paquetes correspondientes (a partir de la versión 6.1.0.581). Una vez se ha hecho la actualización de la infraestructura, hay que instalar la actualización de productos:

Ir a CONFIGURACIÓN / Administración / Instalar actualizaciones de productos

En la siguiente pantalla, se puede encontrar más información sobre el contenido de las actualizaciones. Hay que tener en cuenta que una vez instalados los nuevos paquetes ya no hay vuelta atrás.

Ahora en el área de CONFIGURACIÓN aparece una nueva sección "Administración de servicios", que agrupa la configuración de varias de las funcionalidades usadas en el módulo de Servicio del CRM. Entre estos elementos encontramos dos nuevos: "Contratos de nivel de servicio" (SLA) y "Derechos". Este último lo estudiaremos en otra oportunidad.

2. Creación de nuevo SLA

El elemento de configuración  "Contratos de nivel de servicio" lleva a una vista de todos los registros existentes. Para crear uno nuevo, se da click en "+ NUEVO".

Aparece una pantalla con el formulario para crear el nuevo registro. Los datos mínimos a diligenciar son "Nombre" y "Aplicable desde". El título no se actualiza hasta que no se grabe el registro dando click en el botón "GUARDAR" de la barra de comandos.

3. Creación de condiciones del SLA

Una vez se ha grabado el registro del nuevo SLA, el formulario actualiza el título con el nombre que definimos en el paso anterior y permite la creación de nuevos subregistros de Elementos del SLA. Para hacerlo, dar click en el botón "+" en la esquina superior derecha de la sección "Detalles de SLA" del formulario.

Se abre una nueva ventana (verificar que el navegador no tiene bloqueadas las ventanas emergentes) donde podemos definir uno de varios elementos que componen la definición del SLA. En dicho elemento especificamos las siguientes características:

• General
• Aplicable cuando
• Criterios de éxito
• Error de elemento de SLA
• Acciones de error
• Advertencia de elemento de SLA
• Acciones de advertencia

General

Corresponde al nombre que identifica el elemento dentro del SLA y al campo de la entidad Caso (Incident) con el que se va a asociar este elemento en particular, que hace las veces de fuente para los KPI (Key Performance Indicators). Las opciones son: "Seguimiento para el", "Primera respuesta por" y "Resolver por". Una vez se ha grabado el elemento no es posible cambiar la opción que se seleccionó. 

Aplicable cuando

En esta sección se definen una o más condiciones que indican a Dynamics CRM cuándo se debe crear una nueva instancia del SLA asociada a un registro específico de la entidad Caso. Estas condiciones se pueden agrupar de manera muy similar a como se definen las condiciones de las Búsquedas Avanzadas. Estas condiciones se evalúan cada vez que cambia el campo del caso con el que se relacionó el elemento de SLA. En este ejemplo, el campo relacionado es "Resolver por" y cada vez que cambie de estado se evaluarán las condiciones de "Aplicable cuando".

Como lo advierte Microsoft en "How is the SLA applied?", cuando se crea un nuevo caso, se aplica el SLA (predeterminado o a través de un Derecho)y se actualizan los valores de los campos de Caso relacionados. Cuando el Caso es modificado y cambia el valor de alguno de los campos de Caso usados en las condiciones de "Aplicable cuando", el SLA de aplica otra vez.

Cuando el SLA se aplica de nuevo, todos los elementos de SLA se vuelven a evaluar con base en los campos actualizados del Caso y las acciones de error o de advertencia se disparan si el tiempo se cumplió. Esto ocurre incluso si las acciones de error o advertencia ya se habían disparado antes de que el caso fuera actualizado. Para prevenir esto se puede agregar campos personalizados a la entidad Caso (Incident) para marcar cuando ya se han disparado las acciones de error/advertencia e incluir dichos campos en las condiciones de tal manera que solo se cumplan la primera vez.

Cada condición tiene varios componentes, usualmente una entidad + campo + operador + valor. En este ejemplo usaremos la entidad Caso (Incident), el campo Prioridad, el operador "Es igual a" y seleccionamos un valor de una lista de opciones (Alta, Normal, Baja) dando click en el botón "...", aunque para otros campos que no estén asociados a una lista de opciones se puede definir un valor manualmente, como un número o una fecha. 

Criterios de éxito

En esta sección definimos una o más condiciones de manera idéntica a como se hizo en la sección anterior. Indican al CRM cuándo una instancia activa del SLA asociada a un registro específico de la entidad Caso debe desactivarse.

Error de elemento de SLA

Una vez definidas las condiciones que disparan una instancia del elemento de SLA (Aplicable cuando) para un registro de la entidad Caso y que cancelan dicha instancia (Criterios de éxito), definimos cuánto tiempo de plazo le damos al criterio de éxito antes de declarar el SLA como incumplido. Este tiempo se puede definir seleccionando un valor de una lista de varias opciones en minutos, horas o días. En este ejemplo definidos 30 minutos. 

Para poder seguir definiendo los demás subregistros del elemento de SLA hay que grabar con el botón "Guardar" de la parte superior izquierda de la ventana emergente. 

Acciones de error

Una vez grabado el nuevo elemento de SLA, aparece disponible la opción de "Agregar paso" donde se puede escoger entre: Enviar correo electrónico, Crear registro, Actualizar registro, Asignar registro y Cambiar estado.

Las acciones que se definan aquí se dispararán si ha transcurrido el tiempo definido en la sección "Error de elemento de SLA" desde el momento definido en "Aplica desde" del encabezado del SLA y no se ha cumplido todavía la condición definida en "Criterio de éxito".

Advertencia de elemento de SLA

De manera análoga a como lo hicimos en "Error de elemento de SLA", opcionalmente podemos definir cuánto tiempo de plazo le damos al criterio de éxito antes de disparar acciones de advertencia. Este tiempo se puede definir seleccionando un valor de una lista de varias opciones en minutos, horas o días. El valor debería ser menor que el tiempo de error, por lo que para este ejemplo definimos 15 minutos.  

Acciones de advertencia

Las acciones que se definan aquí se dispararán si ha transcurrido el tiempo definido en la sección "Advertencia de elemento de SLA" desde e evento definido en "Aplica cuando" y no se ha cumplido todavía la condición definida en "Criterio de éxito".

Flujos de Proceso de negocio en Dynamics 2013: ciclo de vida

Los Flujos de proceso de negocio (FPN) o Business Process Flows son uno de los cuatro tipos de procesos que soporta Microsoft Dynamics CRM y es nuevo para la versión 2013.
El ciclo de vida de un FPN es el siguiente:

• Creación de una instancia del flujo de proceso de negocio
• Cambio de la etapa activa del flujo de proceso de negocio

Creación de una instancia del flujo de proceso de negocio

Los flujos de procesos de negocio (FPN) por definición están asociados a una o más Entidades. Cuando el formulario de la Entidad inicial se abre con un registro ya existente, Dynamics abre la instancia del FPN asociada al registro y ubica al usuario en la etapa activa del proceso. Cuando se trata de un nuevo registro, se dispara el evento de creación de una instancia siempre y cuando:

• La Entidad tenga habilitado su uso en FPN.
• No haya una instancia previa de un FPN asociada a este registro en particular.
• Haya definido al menos un (pueden ser varios) FPN activado para esta Entidad y habilitado para uno de los roles de seguridad del usuario actual.

Dynamics entonces:

• Identifica el FPN al tope de la lista de los que el usuario puede usar y crea una nueva instancia de ese FPN.
• Asigna un nuevo ID que identifique de manera única esta instancia particular del FPN.
• Define cuál es la etapa del proceso. Como se está creando el registro de la Entidad, obviamente la etapa es la primera.
• Define la Entidad inicial y el ID del registro específico dentro de la Entidad.

Cambio de la etapa activa del flujo de proceso de negocio

Los FPN pueden ser usados en una o varias sesiones, es decir que el usuario puede grabar el registro, cerrar el formulario y volver nuevamente a abrirlo en otra ocasión para continuar con el proceso. Se puede avanzar hacia otra etapa del proceso durante la misma sesión inicial o en una sesión posterior. En cualquier caso, Dynamics actualiza la instancia del FPN así:

• Cambia la etapa activa del proceso por la etapa actual.

Si la nueva etapa está asociada a una Entidad diferente de la inicial, adicionalmente a lo anterior:

• Se da la opción al usuario de seleccionar un registro relacionado con el registro de la Entidad inicial o crear uno nuevo.
• Se adiciona el tipo de la nueva Entidad y se asigna el id del registro de la Entidad que el usuario creó o seleccionó.

Una vez un nuevo registro ha sido asociado a una etapa N, es posible cambiarlo devolviendo el proceso al paso anterior (N-1) y avanzando nuevamente a la etapa N para que el FPN pida que se seleccione o cree el registro. Si el proceso ya tenía registros asociados de Entidades diferentes en las etapas posteriores (N+1, N+2, etc.), éstas se actualizan a nulo en la instancia del FPN, ya que dichos registros dependían de la relación con el registro que ya no está en la etapa N.

Preparación para la certificación en Microsoft Dynamics CRM 2013

"Ustedes tan de buenas, yo no recibí capacitación". Seguramente hemos escuchado esto varias veces y me parece chévere compartir lo que hemos aprendido para facilitar la tarea a quienes vengan después o que aún no se han certificado.

• Configurar la instancia en inglés.
• Instalar el bloque de datos de ejemplo.
• Leer los materiales de entrenamiento.
• Desarrollar los laboratorios.
• Entrenarse para el examen con los simuladores.
• Preguntar a un amigo.

Configurar la instancia en inglés.

Nuestros clientes usan sus instancias en español, por lo que es muy importante estar familiarizado con la terminología del CRM como está traducida en la versión en español. Sin embargo, para quien apenas está conociendo los conceptos puede ser muy frustrante no encontrar una correspondencia lógica entre los nombres traducidos en español y el original que sale en la documentación (y en el examen de certificación).

Mi recomendación es instalar el idioma inglés en el CRM (CONFIGURACIÓN / Administración / Idiomas) y estar cambiando entre la configuración inglés/español según sea la necesidad (Piñón de opciones de la barra superior / Idiomas ).

Por ejemplo, las opciones de Soluciones solamente están disponibles en el idioma base, que en nuestras instancias es español.
Algunas equivalencias no tan evidentes:

Traducción a español	Original en la documentación y examen de certificación
Oferta	Quote
Cliente Potencial	Lead

Instalar el bloque de datos de ejemplo.

La documentación viene con abundantes referencias a datos de ejemplo que se usan en los laboratorios y demostraciones. Instálela en CONFIGURACIÓN / Administración de datos / Datos de ejemplo:

Leer los materiales de entrenamiento.

Hay videos y materiales disponibles en Introduction to Microsoft Dynamics CRM 2013
Tenga en cuenta que los materiales no son perfectos (hay secciones que son claramente un "copy & paste" de otras muy similares) y ante cualquier inconsistencia mejor pregunta a un amigo.

Desarrollar los laboratorios.

Parece obvio, pero a veces no basta con saber dónde están las opciones. Hacer el ejercicio manual ayuda a recordar qué opciones hay disponibles en cada contexto y cuáles no.

Entrenarse para el examen con los simuladores.

Hay simuladores pagados para entrenarse que pueden ser una opción. Tienen el aval del evaluador y las preguntas y respuestas son 100% consistentes con los exámenes. También los hay gratuitos, como los ofrecidos en http://www.examcollection.com/microsoft_exams.html , los cuales funcionan por crowdsourcing, es decir que los miembros de la comunidad aportan sus simuladores construidos con base en lo que recuerdan de los exámenes de certificación que ya presentaron. Hay que tener en cuenta que no son 100% confiables, pero ayudan a tener una idea de qué tan preparado está para presentar el examen real.

Preguntar a un amigo.

Yo tuve la fortuna de contar con el apoyo de un desarrollador experimentado para recorrer la documentación y resolver dudas. Si ese no es su caso, pregunte al vecino cuando no haya podido entender algo por sus propios medios. Muy posiblemente no sea su culpa sino algún error en la documentación, un malentendido causado por una traducción confusa o algún error fácil de detectar para el ojo entrenado.