Compartir a través de


Obtención de actualizaciones en tiempo real para los cambios de datos mediante Microsoft Graph

En este artículo se describe un patrón de integración común de Microsoft Graph para un escenario empresarial que ofrece mejoras de colaboración empresarial para que las aplicaciones móviles reciban una fuente de solo lectura de mensajes compartidos de Microsoft Teams casi en tiempo real.

Este escenario es un caso de uso no interactivo que se basa en los cambios de datos desencadenados por eventos externos y tiene los siguientes requisitos de arquitectura:

  • Un tipo de integración de datos.
  • Un flujo de datos saliente desde los límites de Microsoft 365 a la aplicación.
  • Un volumen de datos bajo por interacción humana, pero un volumen de datos potencialmente alto en función del número de usuarios.
  • Una latencia de datos casi en tiempo real para generar fuentes actualizadas.

La mejor opción de integración para este escenario es usar las notificaciones de cambio de Microsoft Graph, que pueden entregar notificaciones de eventos, así como el contenido de un mensaje compartido, e implementar webhooks. La aplicación cliente proporciona un secreto de cliente y una clave de cifrado y expone un punto de conexión HTTP donde cambia el servicio de notificaciones de Microsoft Graph. La aplicación cliente puede aceptar y responder rápidamente a solicitudes sincrónicas de Microsoft Graph y puede escalar para controlar los eventos desencadenados por otros clientes que generan mensajes. Este tipo de interacción de la aplicación se denomina modo de inserción.

En el diagrama siguiente se muestra la arquitectura de esta solución.

Diagrama que muestra el servicio de notificación de Microsoft Graph que interactúa con Microsoft Entra ID, puerta de enlace de applicaton, app services, cola de almacenamiento, aplicaciones de funciones y el servicio de destino.

Componentes de la solución

La arquitectura de la solución incluye los siguientes componentes:

  • Azure App Service permite compilar y hospedar aplicaciones web, back-end móviles y API RESTful en el lenguaje de programación preferido, sin administrar la infraestructura. Ofrece escalado automático y alta disponibilidad, admite Windows y Linux y permite implementaciones automatizadas desde GitHub, Azure DevOps o cualquier repositorio de Git.
  • Microsoft Entra ID, que es necesario para administrar la autenticación para las API de Microsoft Graph y admite permisos delegados y de aplicación para habilitar el flujo de OAuth.
  • Aplicación de funciones, que es un componente sin servidor que permite escalar para un gran volumen de notificaciones y tiene lógica de negocios para procesar notificaciones y enviarlas a un servicio de destino.
  • Cola de almacenamiento simple, que le ayuda a descargar la carga del servicio de aplicaciones mediante la conservación de notificaciones antes del procesamiento asincrónico por una instancia de una aplicación de función.
  • Azure Application Gateway, que proporciona capacidades de enrutamiento y seguridad web.
  • Servicio de notificaciones de Microsoft Graph, que administra las suscripciones de notificación y entrega notificaciones de cambios a los clientes.

Consideraciones

Las siguientes consideraciones admiten el uso de este patrón de integración:

  • Disponibilidad: Microsoft Graph llama al webhook de cliente cada vez que se publica un nuevo mensaje en un canal compartido o un chat. El webhook debe tener alta disponibilidad durante todo el día o incluso durante 24 horas.

  • Latencia: el webhook debe confirmar las solicitudes de notificación de Microsoft Graph en un plazo de tres segundos. Si Microsoft Graph no recibe un código de clase 200 dentro de este tiempo, vuelve a enviar la notificación de cambio varias veces, hasta cuatro horas.

  • Escalabilidad: el webhook de cliente debe ser capaz de escalar para un gran volumen de notificaciones en cualquier momento del día. Para ello, agregue más instancias a App Service y cree instancias de más instancias de la aplicación de funciones para actualizar el servicio de destino rápidamente.

  • Complejidad de la solución: la solución de webhook también requiere código personalizado para mantener suscripciones y claves de cifrado para procesar los datos. Esta solución es muy compleja debido al número de componentes implicados y a los requisitos de escalabilidad y disponibilidad.