Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Webhooks de Microsoft Graph explicados: notificaciones en tiempo real en lugar de polling constante (Doblaje IA)

Transcript

Webhooks de Microsoft Graph explicados: notificaciones en tiempo real en lugar de polling constante (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:00
Listo para 10 días de Microsoft 365 Copilot IAE, Azure y las personas que dan forma al futuro del trabajo y del trabajo.
0:07
Este enero M365 con está de vuelta y venimos más grandes.
0:12
Únete a nosotros para cienes en vivo.
0:14
Demostraciones reales y conocimiento práctico de MVP y expertos de la industria.
0:18
Sin diapositivas genéricas, sin palabras de moda interminables.
0:21
Estamos abordando los desafíos reales, Copilot Studio, agentes de IA, Fabric Seguridad, Gobernanza y Automatización.
0:28
Ya seas un profesional de TI, desarrollador o líder empresarial, hay sesiones diseñadas para ti.
0:35
Con 10 días completos, puedes explorar múltiples tecnologías y conectar con una comunidad global.
0:40
Mira en vivo y ve ideas prácticas de regreso a tu organización.
0:45
Enero de 2027. 10 días. Una comunidad Microsoft.
0:49
El registro ya está abierto.
0:51
Ve a m365.com.net y asegura tu lugar hoy mismo.
0:55
Eso es m365.com.net.
0:58
Únete ahora en m365.com.net y nos vemos en vivo en enero.
1:05
Hola a todos y bienvenidos a otro episodio de Píldoras de Conocimiento Microsoft aquí en M365FM.
1:10
Soy su anfitrión Milko Peter.
1:11
El tema de hoy es uno del que casi todos los que desarrollan con Microsoft 365 han oído hablar,
1:15
pero muy pocos pueden explicar claramente.
1:17
¿Qué son exactamente los webhooks de grafo?
1:19
¿Por qué deberían importarte en lugar de hacer las cosas a la vieja usa?
1:22
Imagina que esperas una carta importante.
1:23
¿Caminas hacia tu buzón y está vacío?
1:25
Regresas camino.
1:26
10 minutos después, revisas de nuevo.
1:28
Todavía nada.
1:28
Haces esto del día despreciando tiempo y energía.
1:31
Eso es el sondeo.
1:31
Ahora imagina un mundo diferente.
1:33
El cartero toca el timbre en el momento en que llega una carta.
1:35
Tú no revisas.
1:36
Verás a que son el timbre.
1:37
Eso es un huevo.
1:38
Al final de este episodio, entenderás qué son los webhooks de grafo porque reemplazan
1:42
la revisión constante y cómo encajan las piezas.
1:45
Por medio del sondeo.
1:46
Vamos a analizar esto.
1:48
Para entender por qué los webhooks importan, necesitas entender por qué el sondeo es perjudicial.
1:51
Así es como funcionan la mayoría de las aplicaciones.
1:53
Oye, tu aplicación necesita un error.
1:54
Le pregunta a Microsoft Graph, oye, ¿hay usuarios nuevos?
1:57
Grafo responde, ¿no?
1:58
Entonces tu aplicación espera un poco y vuelve a preguntar.
2:00
¿Hay usuarios nuevos ahora?
2:02
Todavía no.
2:03
Una y otra vez este proceso de sondeo.
2:05
Piensa en ello como llamar constantemente a un amigo para preguntar si tiene noticia.
2:08
Marcas, contesta, preguntas, dice que no cuelgas.
2:11
Luego llamas de nuevo cinco minutos después.
2:13
Y otra vez.
2:13
Estás consumiendo su tiempo y el tuyo.
2:15
Probablemente les esté molestando.
2:17
Ahora imagina miles de aplicaciones haciendo esto Microsoft Graph al mismo tiempo.
2:20
Cada aplicación consultando cada pocos minutos.
2:22
Haciendo las mismas preguntas, obteniendo las mismas respuestas.
2:24
Eso es mucho ruido.
2:25
Microsoft tiene un nombre para cuando consultas demasiado agresivamente.
2:28
Limitación de tasa, o como algunos desarrolladores lo llaman, la cárcel de Graph.
2:32
Cuando envías demasiadas solicitudes, Microsoft dice, bien, has terminado por un tiempo.
2:35
Limitan cuántas llamadas hace tu aplicación.
2:37
Una vez que te limitan, todo se ralentiza.
2:39
La solicitud es legítima sea común.
2:40
Tu aplicación deja de funcionar correctamente.
2:42
No tienes idea de cuándo te dejarán salir.
2:44
¿De cuántas solicitudes estamos hablando?
2:45
Digamos que tu aplicación consulta cada cinco minutos por cambios de usuario.
2:48
Eso equivale a 12 solicitudes por hora.
2:50
En un día completo son 208 solicitudes, y eso es solo por un recurso.
2:54
Si también consultas por grupos, archivos, mensajes y eventos de calendario, acumulas
2:58
miles de solicitudes innecesarias al día.
3:00
La mayoría no devuelve nada.
3:01
Cero cambios, pero aún así hiciste la llamada.
3:03
Y aquí está el punto.
3:04
Incluso si consultas cada cinco minutos, sigues sin obtener actualizaciones en tiempo real.
3:08
Un cambio podría ocurrir un minuto después de tu última consulta.
3:11
No te enterarás hasta dentro de otros cuatro minutos.
3:13
Estás desperdiciando recursos, y aún así perdiendo la oportunidad.
3:16
Ahora, contrasta eso con un enfoque basado en el evento.
3:17
En lugar de llamar a Microsoft Graph cada pocos minutos, esperas a que Microsoft Graph te
3:21
llame a ti.
3:21
Configuras un receptor.
3:23
Cuando algo cambia, Graph te envía una notificación.
3:25
Tú no marcas.
3:26
Contesta cuando suena.
3:27
¿Qué son los webhooks?
3:29
Entonces, ¿qué es exactamente un webhook?
3:31
Aquí está la definición más simple.
3:32
Un webhook es una solicitud HTTP enviada automáticamente cuando sucede algo.
3:36
No la pides el servidor.
3:37
Simplemente te la envía.
3:39
Piénsalo como un timbre de webhook.
3:41
No te quedas afuera revisando cada pocos minutos.
3:43
Instalas un timbre.
3:44
Cuando alguien llega, lo toca.
3:45
Escuchas el timbre y responde.
3:46
El timbre hace la vigilancia a porta.
3:49
A los webhooks a veces se les llama APIs inversas.
3:52
Con una API normal, tu aplicación hace una solicitud y el servidor responde.
3:55
Tu aplicación tiene el control.
3:56
Con un webhook, el servidor envía la solicitud a tu aplicación.
3:59
El servidor tiene el control, pero envía datos en lugar de esperar a que preguntes.
4:02
Ahora, Microsoft Graph también usa webhooks, pero Microsoft los llama notificaciones de
4:06
cambio.
4:07
Es lo mismo, solo que con un nombre diferente.
4:08
Cuando algo cambia a Microsoft 365 Graph, envía un post HTTP a una URL que tú proporcionas.
4:15
Se puede contener información sobre lo que cambió.
4:17
Hay muchas cosas sobre las que puedes recibir notificación.
4:20
Se crea un nuevo usuario en su inquilino.
4:22
Se actualiza un archivo en SharePoint.
4:24
Se envía un mensaje en Teams.
4:25
Un evento de calendario cambia.
4:26
O un grupo recibe un nuevo miembro.
4:29
Todo esto puede activar una notificación.
4:30
Aquí hay un ejemplo real.
4:32
Pongamos que dirige una empresa con un sistema de registro de tiempo.
4:33
Cuando un nuevo empleado se une, usted desea crear una cuenta automáticamente.
4:37
Sin webhooks, consulta el punto de conexión de usuarios cada pocos minutos buscando persona
4:40
nueva.
4:41
Con webhooks, se suscribe a los eventos de creación de usuarios.
4:44
Cuando alguien se une, Graph envía una notificación a su aplicación.
4:47
Su aplicación la recibe, la valida y crea la cuenta.
4:50
Todo en cuestión de segundos, sin sondeos, sin solicitudes de experiencia.
4:54
Otro ejemplo.
4:55
Tiene una biblioteca de documentos de SharePoint donde se cargan recibos.
4:57
Sin webhooks, consulta a la biblioteca constantemente.
5:00
Con webhooks, Graph le avisa en el momento en que se añade un archivo.
5:02
Su aplicación lo toma, comprueba si es un recibo y lo procesa automáticamente.
5:07
Ese es el poder de los webhooks.
5:08
En lugar de que su aplicación pregunte constantemente algo nuevo,
5:11
deja que el sistema le avise cuando algo sucede.
5:13
Es más eficiente, más confiable y mucho más rápido.
5:16
¿Cómo funcionan los webhooks de Microsoft Graph?
5:18
Ahora sabe qué son los webhooks y por qué el sondeo es el problema.
5:21
Veamos cómo funcionan realmente los webhooks de Microsoft Graph,
5:24
porque el flujo es más sencillo de lo que cree.
5:26
Se reduce a tres cosas.
5:27
Una suscripción, una notificación y su punto de conexión.
5:31
Primero, crea una suscripción.
5:32
Le dice a Microsoft Graph,
5:33
oye, quiero saber cuándo cambia esto en específico.
5:36
Le da a Graph los detalles de qué observar y a dónde enviar las novedades.
5:39
Piénselo como suscribirse a un alerta.
5:41
Le dice al sistema lo que le interese y le da su información de contacto.
5:44
Segundo, Microsoft Graph observa ese recurso.
5:46
Monitura los cambios.
5:47
Cuando algo sucede, como la creación de un usuario,
5:49
la actualización de un archivo o la llegada del mensaje,
5:51
Graph lo nota.
5:52
Tercero, Graph envía una notificación.
5:54
Envía un HTTP post a la URL que usted proporciona.
5:57
Ese post contiene información sobre lo que cambió.
6:00
Su punto de conexión lo recibe y su aplicación lo procesa.
6:02
Por lo tanto, el flujo de alto nivel es igual.
6:04
Usted se suscribe, Graph observa,
6:06
Graph envía un post cuando algo cambia.
6:08
Analicemos un poco más esos tres bloques de construcción.
6:10
La suscripción es su solicitud para ser adaptado.
6:13
Es como decir,
6:14
quiero saber cuándo se agrega un nuevo usuario a mi inquilino.
6:17
Usted envía esa solicitud a Microsoft Graph y Graph lo almacena.
6:19
A partir de ese momento, Graph observa en su nombre.
6:22
La notificación es la alerta en sí.
6:24
Un HTTP post que Graph envía a su punto de conexión.
6:26
El cuerpo del post contiene detalles sobre el cambio,
6:29
como qué recurso cambió, qué tipo de cambio ocurrió y cuándo sucedió.
6:32
Su punto de conexión es la puerta que usted deja ver.
6:34
Es una URL en su servidor configurada para recibir estas solicitudes post.
6:37
Solo necesita escuchar y rápidamente.
6:39
Eso es todo.
6:40
No se requiere lógica compleja en el extremo receptor.
6:42
Solo capture la notificación, reconozcala y procésela.
6:45
Ahora compare eso con el sondeo.
6:46
Con el sondeo usted realiza cientos de solicitudes,
6:48
cada una preguntando, ¿hay algo nuevo?
6:50
La mayor parte del tiempo la respuesta no.
6:52
Con los webhooks solo hay un post, la notificación.
6:55
Eso es todo.
6:56
Un mensaje en lugar de cientos.
6:57
La diferencia de eficiencia es enorme.
6:59
Y su punto de conexión no necesita ser complicado.
7:01
Solo necesita ser accesible públicamente,
7:03
usar HTTPS y responder con rapidez.
7:05
Hablaremos de lo que significa rapidez en un momento.
7:07
Pero la idea central es sencilla.
7:09
Su punto de conexión escucha, Graph llama,
7:11
usted responde y listo.
7:14
Haciendo la suscripción.
7:15
Entonces, ¿cómo se configura realmente uno de estos?
7:17
Veamos paso a paso cómo crear una suscripción.
7:20
Comienza enviando una solicitud HTTP Proposed
7:22
a una URL específica en Microsoft Graph.
7:24
Esa URL es https.darkraph.microsoft.com.davo.0
7:28
para las subscriptions.
7:29
Está enviando directamente al punto de conexión de suscripción.
7:31
Dentro del cuerpo de esa solicitud,
7:33
usted incluye los detalles de a qué desea suscribirse.
7:35
Hay cuatro campos clave que debe proporcionar.
7:37
El primero es la URL de notificación.
7:39
Esta es la URL de su punto de conexión,
7:41
el lugar donde Microsoft Graph enviará las notificaciones.
7:43
Debe ser https y accesible públicamente
7:45
porque Graph necesita llegar a ella desde internet.
7:47
El segundo es el recurso.
7:49
Esto le indica a Graph qué es lo que desea observar.
7:51
Usted especifica la ruta al recurso de Microsoft Graph.
7:53
Por ejemplo, users si desea observar cambios de usuarios
7:55
o mail folders para la inbox para la messages
7:58
si desea observar nuevos correos en su bandeja dentro.
8:00
El recurso le indica a Graph exactamente qué es lo que le interesa.
8:03
Tercero es el tipo de cambio.
8:04
Esto le indica a Graph qué tipo de cambios debe notificar.
8:07
Puede especificar creado, actualizado, eliminado o cualquier combinación.
8:10
Entonces, si solo le interesa la creación de nuevos usuarios,
8:13
configura el tipo de cambio como Creative.
8:14
Si también le interesan las actualizaciones,
8:16
lo configura como Creative, Update.
8:17
El cuarto es la fecha y hora de expiración.
8:19
Es el momento en que expira la suscripción
8:21
porque las suscripciones no duran para siempre.
8:23
Te establece una fecha y hora
8:24
y Graph deja de enviar notificaciones después de ese punto.
8:27
La duración máxima depende del recurso que esté observando.
8:29
Para usuarios y grupos, el máximo es de unos 3 días.
8:32
Para elementos de unidad en SharePoint o OneDrive,
8:34
puede ser hasta 30 días.
8:36
Debes consultar la documentación para cada tipo de recurso.
8:38
También hay un campo opcional que vale la pena mencionar.
8:40
El estado del cliente.
8:42
Es una cadena secreta que tú creas.
8:43
Puede ser cualquier cosa que haces.
8:45
Una cadena aleatoria, un ruido que tú elijas.
8:47
Microsoft Graph incluye este valor en cada notificación
8:49
que envía a tu punto de conexión
8:51
y tú lo usas para verificar que la notificación proviene de tu suscripción.
8:55
Si alguien intenta enviar notificaciones falsas hasta tu punto de conexión,
8:58
el estado del cliente no coincidirá y podrás rechazarlo de inmediato.
9:01
Es una medida de seguridad sencilla pero importante.
9:03
Crear una suscripción es como registrarse para la entrega de un periódico.
9:07
Le das al periódico tu dirección.
9:08
Ese es tu URL de notificación.
9:10
Les dices qué secciones quieres, eso es tu recurso y tipo de cambio
9:13
y les indicas cuánto tiempo deseas que continúe la entrega.
9:16
Ese es tu fecha y hora de vencimiento.
9:17
El periódico se encarga del resto.
9:19
Pero aquí está el detalle, las suscripciones caducan.
9:21
No puedes crear una y olvidarte de ella.
9:24
Después de que pasa la fecha y hora de vencimiento,
9:26
Graph deja de enviar notificaciones y tu suscripción desaparece.
9:28
Si deseas seguir recibiendo notificaciones,
9:31
debes renovar la suscripción antes de que caduque enviando una solicitud
9:33
para el punto de conexión de la suscripción con una nueva fecha y hora de vencimiento.
9:36
Entonces, crear una suscripción es el primer paso, pero no el último.
9:39
Necesitas administrar el ciclo de vida.
9:41
Hablaremos sobre eso más adelante.
9:43
El protocolo de validación.
9:44
Antes de que tu suscripción esté activa, hay un paso que no puedes omitir.
9:47
Microsoft Graph no solo acepta tu solicitud de suscripción y comienza a enviar notificaciones.
9:52
Primero debe confirmar que tu punto de conexión es real y está listo para recibirlas.
9:55
Así es como funciona.
9:56
Cuando envías tu solicitud post para crear una suscripción,
9:58
Microsoft Graph envía inmediatamente un post de prueba a tu URL de notificación.
10:03
Ese post de prueba incluye un parámetro de consulta llamado token de validación.
10:06
Es solo una cadena aleatoria.
10:07
Tu punto de conexión debe tomar ese token y enviarlo de vuelta como una respuesta de texto sin formato
10:11
y tienes que hacerlo en un plazo de 10 segundos.
10:13
Piensa en ello como un mensajero entregando un paquete.
10:15
Llegan a tu puerta y preguntan, ¿es esta la dirección correcta?
10:17
Puedes confirmar.
10:18
Tienes que firmar los de excepción.
10:20
Si no lo haces, se van.
10:21
El mensajero no deja el paquete.
10:23
Simplemente se va.
10:24
Eso es exactamente lo que está sucediendo.
10:25
Microsoft Graph está diciendo, estoy a punto de enviarte notificaciones importantes.
10:29
Demuestra que eres la persona correcta en la dirección correcta.
10:33
Tu punto de conexión responde devolviendo el token de validación,
10:36
lo cual le dice a Graph, sí, estoy aquí.
10:38
Estoy escuchando.
10:39
Envíame la notificación.
10:40
Ahora, aquí es donde muchos desarrolladores se equivocan.
10:43
El token de validación debe devolverse como texto plano.
10:45
No JSON, no HTML, texto plano.
10:48
La respuesta debe incluir una cabecera de tipo de contenido establecida en TextBatterPlay.
10:51
Si lo envías envuelto en JSON o codificado de cualquier forma, la validación fallará.
10:55
Tu suscripción no será creada.
10:57
Microsoft Graph devuelve un error y pequea sin saber que salió mal.
10:59
Hay otro detalle técnico que vale la pena conocer.
11:02
El servicio de validación de Microsoft Graph no admite TLS 1.3 de forma confiable.
11:06
Negocia mediante TLS 1.2.
11:07
Por lo tanto, si tu punto de conexión solo acepta conexiones TLS 1.3, el protocolo de
11:11
enlace de validación falla antes de que tu código se ejecute.
11:14
Debes asegurarte de que tu punto de conexión admita TLS 1.2, al menos para el paso de validación.
11:19
Después, puedes aplicar la versión de TLS que desees para las notificaciones reales.
11:23
La buena noticia es que este protocolo de enlace de validación solo ocurre una vez por
11:26
suscripción.
11:27
No es algo que tu punto de conexión deba gestionar cada vez que llega una notificación,
11:30
solo la primera vez.
11:31
Una vez que Graph confirma que tu punto de conexión es real, confía en él durante la
11:34
vigencia de esa suscripción.
11:36
Así que solo necesitas hacer esto bien una vez.
11:39
Manejo de notificaciones y seguridad.
11:40
Una vez que el protocolo de enlace de validación se completa y la suscripción está activa,
11:43
Microsoft Graph comienza en explicaciones Microsoft Notificación.
11:46
Entonces, ¿cómo se ven realmente en la práctica?
11:48
Cuando algo cambia, Graph envía un HTTP post a tu punto de conexión con un objeto JSON
11:53
en el cuerpo.
11:54
Ese objeto contiene el recurso que cambió, el tipo de cambio, creación, actualización
11:58
o eliminación y una marca de tiempo.
12:00
También incluye el valor de estado del cliente que estableciste al crear la suscripción.
12:04
Esa es tu cadena secreta, tu forma de saber que el mensaje está auténtico.
12:07
Así que esto es lo primero que debes hacer cuando llega una notificación.
12:10
Valida ese estado del cliente.
12:11
Compara el valor en la notificación con el secreto que guardaste al crear la suscripción.
12:15
Si no coinciden, descártala de inmediato ya que podría ser falsa.
12:18
Alguien tratando de engañar a tu sistema para procesar datos incorrectos, incorrectos.
12:21
Esto es importante porque tu punto de conexión reside en la internet pública.
12:24
¿Cualquiera que conozca tu URL podría enviarle un post?
12:27
Sin la validación del estado del cliente, no tendrías forma de distinguir entre una
12:30
notificación real de Microsoft Graph y una falsa y una falsa.
12:33
Es una comprobación simple, pero es tu primera línea.
12:35
Una vez que hayas confirmado que la notificación es legítima, debes responder rápidamente.
12:39
Microsoft Graph espera una respuesta HTTP de nivel 200 en menos de 3 segundos.
12:43
Si tardas más, Graph lo nota.
12:44
Si sucede con demasiada frecuencia, Graph empieza a tratarte de forma distinta.
12:48
Así es como funciona la imitación.
12:49
Si más del 10% de tus respuestas exceden el margen de 3 segundos en cualquier periodo
12:53
de 10 minutos, Microsoft Graph marca tu punto de conexión como lento.
12:57
Cuando eso ocurre, las notificaciones nuevas se retrasan 10 minutos.
13:00
Siguen llegando eventualmente, pero pierdes la entrega en tiempo real.
13:03
Y si las cosas empeoran, con más del 15% de tus respuestas superando los 10 segundos,
13:07
Graph marca tu punto de conexión como descartado.
13:09
En ese estado, las notificaciones se eliminan por completo durante 10 minutos.
13:12
Aquí viene la parte de abajo.
13:13
Las notificaciones descartadas no pueden recuperar.
13:15
Se han ido y nunca las volverás a obtener.
13:17
Piénsalo como una línea telefónica ocupada.
13:19
Si no contesta rápido, quien llama lo intenta de nuevo más tarde.
13:21
Pero si nunca contestas, eventualmente quien llama se rinde.
13:24
Microsoft Graph es quien llama y tu punto de conexión es el teléfono.
13:28
Contesta rápido o arrésgate a perder el mensaje.
13:30
Entonces, ¿cuál es la mejor práctica aquí?
13:32
Reconoce de inmediato y procesa de forma síncrona.
13:34
Tu punto de conexión debe validar el estado del cliente,
13:36
aceptar la notificación y devolver una respuesta 200 o 200 o son más rápido posible.
13:40
Luego, enviar la notificación a una cola para procesamiento en segundo plano,
13:44
una cola de Azure, un bus de servicio, incluso una tabla de base de datos simple.
13:47
El objetivo es salir del ciclo de respuesta rápidamente
13:49
y dejar que tus trabajadores en segundo plano manejen el trabajo pesado.
13:52
Y un recordatorio de seguridad más.
13:53
Tu punto de conexión debe ser HTTPS sin excepciones.
13:56
Microsoft Graph no enviará notificaciones a un punto de conexión HTTP.
14:00
Y tu punto de conexión debe ser accesible.
14:01
Si está detrás de un firewall o una VPN, el Graph no puede adentro.
14:04
Para el desarrollo, puedes usar herramientas como un Grock
14:06
para crear un túnel público hacia tu máquina local.
14:09
Pero en producción, tu punto de conexión debe vivir donde Graph pueda encontrarlo.
14:13
Mantener vivo el ciclo de vida de las notificaciones.
14:16
Entonces, ya tienes configurada tu suscripción,
14:17
las notificaciones están fluyendo y todo parece estar bien.
14:20
Pero aquí hay algo que toma a mucha gente por sorpresa.
14:22
Tu suscripción tiene una fecha de vencimiento.
14:24
No dura para siempre.
14:25
Dependiendo del recurso que estés observando,
14:27
la duración máxima de la suscripción suele ser de entre 3 y 7 días.
14:30
Para algunos recursos como elementos de unidad en SharePoint,
14:32
puedes obtener hasta 30 días.
14:34
Pero el punto es que no es permanente.
14:35
No puedes crear una suscripción y olvidarte de ella.
14:38
Piénsalo como una suscripción nerviosa.
14:40
Te suscribes y empiezas a recibir los números y todo es genial.
14:43
Pero si no renuevas antes de que expire la suscripción,
14:45
los números dejan de llegar.
14:46
Lo mismo sucede.
14:47
Si su suscripción caduca, Microsoft Graph deja de enviar notificaciones.
14:50
Y puede que no se dé cuenta hasta que se pregunte por qué no sucede nada.
14:53
Por lo tanto, en Estrategia de Renovación,
14:55
la forma de renovar es en sí.
14:56
Envía una solicitud de parche al punto de conexión de suscripción
14:58
usando el ID de suscripción
15:00
y actualice la fecha y hora de expiración a una nueva fecha futura.
15:02
Eso extiende la vida útil de la suscripción.
15:04
Puede hacer esto tantas veces como quiera,
15:06
siempre que lo haga, antes de que pase la expiración actual.
15:09
Ahora bien, Microsoft Graph le ayuda en esto
15:10
con algo llamado notificaciones de ciclo de vida.
15:13
Cuando crea una suscripción,
15:14
puede proporcionar una URL separada
15:15
llamada URL Notificación de Ciclo de Vida.
15:18
Microsoft Graph envía alertas a esa URL
15:20
cuando ocurren ciertas cosas,
15:22
como cuando su suscripción está por expirar,
15:24
cuando su token de acceso está por agotarse
15:25
o cuando cambian los permisos de su aplicación.
15:28
Estas notificaciones de ciclo de vida le dan un aviso previo.
15:30
No tienen que adivinar cuándo va a terminar su suscripción.
15:32
Clafléese.
15:33
Oye, tu suscripción expira en unas pocas horas.
15:35
Tal vez quieras renovar.
15:37
Es como recibir un recordatorio de su editor de revistas
15:39
de que su suscripción está por terminar.
15:41
Oye, utiliza, está prestando atención.
15:43
Pero, ¿qué sucede si las cosas salen mal de todo modo?
15:45
Tal vez su punto de conexión se caiga por un tiempo
15:46
o las notificaciones se pierdan porque fue demasiado lento.
15:50
Ahí es donde entra la consulta Delta.
15:51
La consulta Delta es una función separada de Microsoft Graph
15:53
que le permite preguntar qué ha cambiado desde la última vez que verifiqué
15:56
y devuelve solo los cambios nada más.
15:59
Así es como funciona.
16:00
La primera vez que ejecuta una consulta Delta en un recurso,
16:02
digamos usuarios,
16:03
Graph devuelve a todos los usuarios de su inquilino.
16:05
Pero también devuelve algo extra a un enlace especial
16:06
llamado enlace Delta.
16:08
Guarda ese enlace.
16:09
La próxima vez que ejecute la misma consulta,
16:11
utiliza ese enlace Delta.
16:12
Y en lugar de obtener todos los usuarios nuevamente,
16:14
obtiene solo los que cambiaron desde su última solicitud.
16:16
Usuarios nuevos, usuarios actualizados, usuarios eliminados.
16:19
Eso.
16:19
Piensa en ello como leer una lista de novedades
16:22
en lugar de leer toda la enciclopedia cada vez.
16:25
Mucho más rápido, mucho menos dato.
16:26
Ahora, aquí está el patrón de teléfono.
16:27
Combine webhooks con consulta Delta.
16:29
Use webhooks para que le avisen cuando algo cambió.
16:32
Luego use la consulta Delta para averiguar exactamente qué cambió.
16:34
Déjeme explicarle por qué es importante.
16:35
Los webhooks son rápidos, pero no son perfectos.
16:37
Las notificaciones pueden perderse,
16:39
las exclusiones pueden expirar
16:40
y su punto de conexión puede caerse.
16:41
Pero la consulta Delta es confiable.
16:42
Puedes ejecutarlo cuando quieras
16:43
y te dará una lista completa de los cambios desde tu última revisión.
16:46
Si aunque te pierdas una notificación, podrás ponerte al día.
16:49
Este es el flujo típico.
16:51
Configura una suscripción a webhooks para los cambios de usuario.
16:53
Ejecuta una consulta Delta inicial para obtener estado base
16:55
y guarda el enlace Delta.
16:57
Cuando llegue un webhook indicando que un usuario cambió,
16:59
ejecuta una consulta Delta usando el enlace guardado.
17:02
Eso te dará el cambio exacto.
17:03
Procesalo y guarda el nuevo enlace Delta de esa respuesta.
17:06
La próxima vez que llegue un webhook, repite el proceso.
17:08
Y si alguna vez pierdes una notificación
17:10
o tu suscripción expira,
17:11
simplemente puedes ejecutar la consulta Delta.
17:14
Tendrás todo lo que te perdéis.
17:15
Es una red segura.
17:16
Los webhooks te dan velocidad
17:17
y las consultas Delta te dan fiabilidad.
17:19
Juntos, una combinación poderosa.
17:22
Ejemplo del mundo real y próximos pasos.
17:24
Imagina que un nuevo empleado se une a tu empresa mañana.
17:26
Alguien en MRR.
17:28
Crea su cuenta Microsoft, entra a AD
17:29
y esa simple acción inicia una reacción en cadena.
17:33
Si has configurado una suscripción de webhook
17:35
para cambios de usuario,
17:35
Microsoft Graph lo anota al instante
17:37
y envía un post a tu endpoint.
17:39
Esto es lo que sucede después.
17:40
Tu endpoint recibe la notificación,
17:42
valida el estado del cliente
17:43
y, si coincide con tu secreto, sabes que es legítimo.
17:46
Devuelves una respuesta 202 aceptada en 3 segundos,
17:49
confirmando la notificación y tu proceso,
17:50
en segundo plano, la toma.
17:53
El proceso ve que se crea un usuario,
17:54
pero la notificación incluye todos los detalles,
17:56
así que ejecuta una consulta Delta con tu enlace guardado.
17:58
Eso devuelve toda la información del nuevo usuario,
18:01
nombre, correo, departamento, cargo, gerente,
18:03
todo lo que necesitas.
18:05
Ahora tu proceso toma esa información
18:06
y crea una cuenta para el nuevo empleado
18:08
en tu sistema de control de tiempo externo.
18:10
Bien, correo bienvenido.
18:12
Los añade a las listas de distribución correspondientes.
18:14
Todo esto ocurre a los pocos segundos
18:15
de que RRP cree la cuenta en Entraide
18:18
sin sondeos, sin pasos manuales, sin retraso.
18:21
Piensa en la alternativa.
18:23
Sin Webhooks tendrías que consultar el endpoint de usuario
18:25
cada pocos minutos,
18:26
cientos de solicitudes al día,
18:27
y aún así podrías tardar minutos
18:28
en detectar al nuevo usuario
18:30
con Webhooks instantáneo.
18:32
Una notificación, una consulta Delta, listo.
18:34
Ese es el verdadero valor.
18:35
Tu sistema se vuelve más rápido, eficiente
18:36
y con menos probabilidades de alcanzar límites de limitación.
18:39
En lugar de preguntar constantemente a Graph por actualizaciones,
18:41
dejas que Graph te avise cuando ocurre algo.
18:42
Es un cambio fundamental en cómo construir integraciones.
18:45
Así que esto es lo que quiero que intentes.
18:47
Piensa en un proceso para el que estés realizando sondeos.
18:49
Tal vez estés buscando nuevos correos en un buzón compartido.
18:52
Tal vez estés vigilando cambios de archivos
18:53
en una biblioteca de SharePoint.
18:55
Tal vez estés monitoreando actualizaciones de usuarios
18:56
para tu sistema de RR.
18:57
¿Podrían Webhooks reemplazar ese sondeo?
18:59
En la mayoría de los casos, la respuesta es sí.
19:01
Y no necesitas construir todo.