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.
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.
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.
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.
