Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Delta Queries de Microsoft Graph: delta link, caducidad del token, error 410 y enfoque híbrido con notificaciones (Doblaje IA)

Transcript

Delta Queries de Microsoft Graph: delta link, caducidad del token, error 410 y enfoque híbrido con notificaciones (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:00
Speaker 2: Preparado para 10 días de Microsoft 365 Copilot EA, Azure
0:04
Speaker 2: y las personas que están dando forma al futuro del trabajo,
0:06
Speaker 2: este enero, M365 con regresa y lo hace a lo grande.
0:12
Speaker 2: Únase a nuestras sesiones en vivo, demostraciones reales y conocimientos
0:15
Speaker 2: prácticos de MVP y expertos del sector en todo el mundo.
0:18
Speaker 2: Sin diapositivas genéricas ni palabras de moda interminable. Estamos abordando
0:22
Speaker 2: los desafíos reales Copilot Studio, agentes de IA, estructura, seguridad,
0:27
Speaker 2: gobernanza y automatización. Ya seas un profesional de TI, un
0:31
Speaker 2: desarrollador o un líder empresarial, hay sesiones diseñadas para ti.
0:35
Speaker 2: Con 10 días completos, puedes explorar múltiples tecnologías y conectar
0:39
Speaker 2: con una comunidad global. Míralo en vivo y aplica conocimientos
0:43
Speaker 2: prácticos a tu organización. Enero de 2027. 10 días. Una
0:48
Speaker 2: comunidad de Microsoft. La inscripción ya está abierta. Ve a
0:53
Speaker 2: tu sitio hoy mismo. sm365com.net Únete ahora en m365con.net y
1:02
Speaker 2: nos vemos en vivo en enero. Déjame hacerte una idea.
1:06
Speaker 2: Tienes una aplicación de calendario en tu teléfono que muestra
1:08
Speaker 2: tus reuniones del día, pero también tienes reuniones en tu
1:10
Speaker 2: computadora portátil y a veces alguien cambia la hora de
1:12
Speaker 2: una reunión mientras no estás en tu escritorio. Cuando abres
1:15
Speaker 2: la aplicación en tu teléfono, esperas ver el cambio ahora mismo,
1:18
Speaker 2: no mañana. Entonces,¿ cómo gestionan esto? Descargan todos los eventos
1:21
Speaker 2: cada pocos minutos, haya cambiado algo o no. Piensa en
1:24
Speaker 2: eso por un segundo. Si tienes mil eventos de calendario
1:27
Speaker 2: y solo uno de ellos cambia, La aplicación aún así
1:29
Speaker 2: descarga los miles, como ir al supermercado y comprar todo
1:32
Speaker 2: lo que hay en la tienda solo porque necesitas leche.
1:33
Speaker 2: Un desperdicio. Sí se hacen las cosas antes. Y empeora.
1:37
Speaker 2: Con una conexión lenta, esa descarga completa lleva tiempo. Te
1:40
Speaker 2: quedas sentado mirando una ruleta. La aplicación parece lenta. La
1:42
Speaker 2: batería se agota más rápido. Y el servidor tiene que
1:45
Speaker 2: gestionar todas las solicitudes, incluso cuando no ha cambiado nada.
1:47
Speaker 2: Ahora imagina que estás creando una aplicación que sincroniza usuarios
1:49
Speaker 2: de Microsoft EntryD o correos electrónicos de Exchange o archivos
1:53
Speaker 2: de SharePoint. El problema se multiplica. Estás moviendo gigabytes de
1:56
Speaker 2: datos sin ninguna buena razón. Las consultas Delta resuelven este
1:59
Speaker 2: problema exacto. En lugar de preguntar por todo, solo preguntas
2:01
Speaker 2: por lo que ha cambiado desde tu última comprobación.¿ Qué
2:04
Speaker 2: pasaría si pudiera obtener solo las novedades? Esa es la
2:09
Speaker 2: pregunta que responden las consultas Delta. Si alguna vez has
2:12
Speaker 2: esperado a que terminara una sincronización en la conexión lenta
2:14
Speaker 2: o has creado una aplicación que extrae una aplicada a
2:16
Speaker 2: pocos minutos y te has preguntado si era una forma mejor,
2:18
Speaker 2: esto es para ti. Lo que viene es un sencillo
2:20
Speaker 2: mecanismo de seguimiento de cambios. Nada de magia. Solo cálculos
2:24
Speaker 2: de tokens que permiten preguntar a Microsoft Graph que hay
2:27
Speaker 2: De nuevo, desde ayer.¿ Es una consulta Delta? Entonces,¿ qué
2:31
Speaker 2: es exactamente una consulta Delta? Esta es la definición máxima.
2:34
Speaker 2: Una consulta Delta solicita a Microsoft Graph solo los cambios
2:36
Speaker 2: desde tu última comprobación. No todo, solo los elementos nuevos,
2:40
Speaker 2: actualizados o eliminados. Piensa en tu bandeja de entrada actual.
2:43
Speaker 2: Cuando la abres por la mañana, no relees todos los
2:45
Speaker 2: correos electrónicos, solo miras los nuevos, los que han llegado
2:48
Speaker 2: desde la última vez que la revisaste. Eso es exactamente
2:50
Speaker 2: lo que hace una consulta Delta, pero para tus datos
2:51
Speaker 2: de Microsoft 365, compáralo con una sincronización completa. Una sincronización
2:55
Speaker 2: completa es como hacer una copia de seguridad de toda
2:57
Speaker 2: tu bandeja al revisar el correo. Tendrías miles de copias
3:00
Speaker 2: de los mismos mensajes. Es un desperdicio y lento. Una
3:03
Speaker 2: consulta Delta es más como un registro de cambios que
3:05
Speaker 2: dice esto es lo que ha pasado desde la última vez.
3:07
Speaker 2: Nada más. Esto funciona en muchos recursos de Microsoft Graph. Usuarios, grupos, correo,
3:12
Speaker 2: eventos de calendario, contactos y archivos. Si reside en Microsoft
3:15
Speaker 2: 365 es probable que haya un punto de conexión Delta
3:17
Speaker 2: para ella. La primera vez que amas a un punto
3:19
Speaker 2: de conexión Delta devuelve todo. Esa es tu unidad básica.
3:21
Speaker 2: Obtienes todos los datos más un vínculo especial llamado vínculo Delta.
3:24
Speaker 2: Guarda ese vínculo. Luego, en las llamadas posteriores, usas ese
3:27
Speaker 2: vínculo guardado y Microsoft Graph devuelve solo los cambios, adiciones,
3:30
Speaker 2: actualizaciones y eliminaciones. Eso es todo.¿ Por qué es importante?
3:33
Speaker 2: Menos datos movidos significa sincronizaciones más rápidas. Sincronizaciones más rápidas
3:36
Speaker 2: mejoran la experiencia. Tu aplicación se siente ágil en lugar
3:39
Speaker 2: de lenta. Y como estás moviendo menos datos, usas menos
3:41
Speaker 2: ancho de banda y menos potencia de procesamiento en ambos extremos.
3:44
Speaker 2: Menor coste, mejor rendimiento. Microsoft diseñó Consultas Delta para aplicaciones
3:48
Speaker 2: que necesitan mantenerse actualizadas sin sobrecargar la app. Si alguna
3:51
Speaker 2: vez llegaste a un límite por consultar de forma demasiado agresiva,
3:54
Speaker 2: Sabes por qué es importante. Las consultas Delta te permiten
3:56
Speaker 2: sincronizar de forma eficiente sin que te limiten. Así es
3:59
Speaker 2: como funciona el sistema de token. Entonces,¿ cómo recuerda el
4:01
Speaker 2: sistema donde lo dejaste? Ahí es donde entran los top.
4:04
Speaker 2: Cuando realizas esa primera consulta Delta, Microsoft Graph no solo
4:07
Speaker 2: te envía los datos y se olvida de ellos. Te
4:10
Speaker 2: proporciona algo llamado enlace Delta. Piensa en ello como un marcador.
4:12
Speaker 2: Un marcador que le dice a Graph exactamente dónde dejaste
4:14
Speaker 2: de leer. Así es como funciona. Realizas tu primera solicitud
4:18
Speaker 2: y Graph te devuelve todos los datos. Tu conjunto completo
4:21
Speaker 2: de usuarios, eventos o lo que sea que estés rastreando.
4:23
Speaker 2: En la parte inferior de esa respuesta hay una URL
4:25
Speaker 2: que contiene algo llamado token delta. Guardas esa URL y
4:28
Speaker 2: la almacenas en un lugar seguro. La próxima vez que
4:30
Speaker 2: quieras sincronizar, no haces una nueva solicitud. En su lugar,
4:32
Speaker 2: llamas a esa guardada. Graph dice, oh, te recuerdo, te
4:35
Speaker 2: detuviste aquí. Luego envías solo los cambios desde ese punto.
4:40
Speaker 2: Se agregó un nuevo usuario, se eliminó un evento, se
4:42
Speaker 2: actualizó el número de teléfono de un contacto. Eso es
4:44
Speaker 2: todo lo que obtiene. Además, un nuevo enlace delta para
4:46
Speaker 2: la próxima. Ahora bien,¿ qué pasa si hay muchos cambios?
4:48
Speaker 2: Digamos que no has sincronizado en tres días y han
4:50
Speaker 2: cambiado cientos de cosas. Y ahora podrían enviarlos todos en
4:52
Speaker 2: una sola repuesta. Envía una página de cambios y en
4:54
Speaker 2: la parte inferior de esa página ves algo llamado enlace siguiente.
4:58
Speaker 2: Eso significa que si adelante hay más. Llamas a ese
5:00
Speaker 2: enlace siguiente, obtienes la página siguiente y repites hasta que
5:02
Speaker 2: finalmente ves un enlace delta. Así es como sabes si
5:05
Speaker 2: estás al día. El enlace siguiente significa que hay más.
5:07
Speaker 2: El enlace delta significa que has terminado por algo. Aquí
5:09
Speaker 2: tienes una forma de ver. Imagina que vas a hacer
5:11
Speaker 2: la compra. Compras un carrito lleno de cosas y el
5:13
Speaker 2: cajero te da un recibo. Y ese recibo es la
5:16
Speaker 2: prueba de lo que has comprado. La próxima vez que
5:18
Speaker 2: vayas de compra no lleves toda la dinamita. Solo llevas
5:20
Speaker 2: el recibo. El cajero lo mira y dice bien. Ya
5:22
Speaker 2: tienes leche y huevos. Solo necesitas las cosas que han
5:25
Speaker 2: cambiado desde entonces. Ese recibo es tu enlace Delta. No
5:28
Speaker 2: necesitas recordar lo que ya tienes. El recibo lo recuerda
5:31
Speaker 2: por ti y ese es el punto claro. No tienes
5:32
Speaker 2: que almacenar marcas de tiempo ni números de versión tú mismo.
5:35
Speaker 2: No tienes que averiguar qué ha cambiado y qué no.
5:37
Speaker 2: Microsoft se encarga de todo ese seguimiento. Simplemente guarda el enlace,
5:40
Speaker 2: llámalo más tarde y deja que grafague el trabajo. No
5:43
Speaker 2: puedes ignorar la limitación. Suena elegante, ¿verdad? Pero como cualquier
5:46
Speaker 2: sistema inteligente, hay trampas que debes conocer. Primero, la caducidad
5:49
Speaker 2: del token. Si sincronizas objetos de directorio, usuarios, grupos y dispositivos,
5:53
Speaker 2: tu token Delta solo es válido durante 7 días. Eso
5:55
Speaker 2: es todo. Si tu aplicación no se sincroniza al menos
5:57
Speaker 2: una vez cada 7 días, ese token caduca. Y cuando caduca,
6:00
Speaker 2: no puedes retomarlo donde lo dejaste. Tienes que empezar de
6:03
Speaker 2: nuevo una sincronización. Esto es más importante de lo que parece.
6:06
Speaker 2: Imagina crear una app que sincroniza perfiles de usuarios. Funciona
6:08
Speaker 2: bien durante meses, pero alguien se toma las vacaciones de
6:10
Speaker 2: dos semanas. Cuando regresa, el token de la aplicación está muerto.
6:13
Speaker 2: Tiene que descargar todo desde cero. Eso supone muchos datos
6:16
Speaker 2: y mucho tiempo. En segundo lugar está el temido error 410Gone.
6:19
Speaker 2: Incluso si tu token no ha caducado de forma natural,
6:21
Speaker 2: Microsoft Graph puede invalidarlo. Esto ocurre durante el mantenimiento interno,
6:25
Speaker 2: las migraciones de inquilinos u otros cambios en segundo plano
6:27
Speaker 2: que no puedes controlar. Cuando lo hace, Graph devuelve un
6:29
Speaker 2: estado HTTP 4.10. Esa es la forma que tiene Microsoft
6:32
Speaker 2: de decir, no recuerdo ese token, no recuerdo ese token.
6:34
Speaker 2: Piensa en EO. De nuevo, necesitas una resincronización completa. En
6:37
Speaker 2: tercer lugar, los retrasamientos. Aquí hay algo que sorprende a
6:40
Speaker 2: mucha gente. Cuando alguien actualiza a un usuario en Microsoft,
6:43
Speaker 2: entra ID, se cambia o no aparece en las consultas
6:45
Speaker 2: del tal instante. Hay un retraso. A veces segundos, a
6:48
Speaker 2: veces minutos. El cambio tiene que propagarse a través de
6:50
Speaker 2: los sistemas internos de Microsoft antes de aparecer en la
6:52
Speaker 2: fuente Delta. Si creas una app que requiere actualizaciones en
6:55
Speaker 2: tiempo real, la consulta Delta por sí sola no bastará.¿
6:57
Speaker 2: Pensarás que no ha cambiado nada cuando en realidad algo
6:59
Speaker 2: todavía no ha aparecido? Cuarto, propiedades sin seguimiento. No todas
7:02
Speaker 2: las propiedades de un recurso son rastreadas por la consulta Delta.
7:05
Speaker 2: Toma la propiedad de skills de un objeto de usuario.
7:07
Speaker 2: Esos datos residen en SharePoint, no en el almacén del
7:09
Speaker 2: directorio principal. Por lo tanto, si alguien actualiza las habilidades
7:11
Speaker 2: de un usuario, ese cambio no activa una respuesta Delta.
7:14
Speaker 2: Tu aplicación nunca lo ve. Tendrías que leer toda esa
7:16
Speaker 2: propiedad por completo para hallar la actualización. Esto pilla desprevenidos
7:19
Speaker 2: a los desarrolladores todo. Quinto, repeticiones. Microsoft Graph hace todo
7:23
Speaker 2: lo posible para evitar duplicados, pero no lo garantiza. El
7:26
Speaker 2: mismo cambio podría aparecer en dos respuestas delta consecutivas. Eso
7:29
Speaker 2: significa que tu aplicación debe ser idempotente. Debe gestionar la
7:31
Speaker 2: misma actualización dos veces sin interrumpirse. Si estás insertando registros
7:35
Speaker 2: en una base de datos, debes comprobar si el registro
7:37
Speaker 2: ya existe antes de añadirlo. Si estás actualizando un campo,
7:39
Speaker 2: debes asegurarte de que aplicar la misma actualización dos veces
7:42
Speaker 2: no corrompa los datos. Y sexto, restricciones de parámetros de consulta.
7:45
Speaker 2: En los puntos de conexión Delta de usuario y grupo,¿
7:47
Speaker 2: no es posible usar Expand y Order?¿ Quieres incluir la
7:49
Speaker 2: propiedad Manager en tu sincronización de usuarios? Puedes, pero solo
7:52
Speaker 2: si usas Seleccionar de una forma específica.¿ Quieres ordenar usuarios
7:55
Speaker 2: por nombre? No es posible en el punto de conexión Delta.
7:58
Speaker 2: Tienes que sortear esas limitaciones con solicitudes adicionales. Bueno, este
8:01
Speaker 2: es el resumen. La consulta Delta es potente, es potente,
8:03
Speaker 2: ahorra ancho de banda, reduce la latencia y hace que
8:04
Speaker 2: tu aplicación parezca rápida. Pero no es un sistema perfecto.
8:07
Speaker 2: Los tokens caducan, los cambios se retrasan, algunas propiedades son invisibles,
8:10
Speaker 2: se producen duplicados. Y no puedes usar todas las funciones
8:13
Speaker 2: de consulta a las que estás acostumbrado. Debes planificar estos
8:15
Speaker 2: casos extremos. Crear una lógica de reintento. Gestionar el error 410.
8:19
Speaker 2: Esperar repeticiones. Y lo más importante, no dar por sentado
8:21
Speaker 2: que lo que muestra la consulta delta es la imagen completa.
8:23
Speaker 2: Porque a veces no lo es. Consulta delta frente a
8:26
Speaker 2: notificaciones de cambios. Entonces, si la consulta delta tiene estas lagunas,
8:29
Speaker 2: caducidad de tokens, retrasos y propiedades sin seguimiento,¿ por qué
8:32
Speaker 2: no usar notificaciones push? Comparemos funciones. Las notificaciones de cambio
8:36
Speaker 2: se basan en notificaciones push. Microsoft llama a tu punto
8:38
Speaker 2: de conexión cuando algo cambia. Hablamos de segundos, no de minutos.
8:41
Speaker 2: casi en tiempo real. Si alguien actualiza a un usuario
8:44
Speaker 2: en EntryD, tu aplicación lo sabe casi al instante. No
8:47
Speaker 2: se requiere sondeo. La consulta Delta, por otro lado, se
8:50
Speaker 2: basa en acción. Solicitas cambios según tu programación. Quizás cada hora,
8:53
Speaker 2: quizás cada seis horas, quizás una vez al día. La
8:55
Speaker 2: latencia se mide en minutos u horas, no en segundos.
8:58
Speaker 2: Tú decides cuándo comprobarlo y obtienes todo lo que ha
9:00
Speaker 2: cambiado desde la última comprobación, los cuales son las ventajas
9:02
Speaker 2: en Sputnik. La baja latencia es la principal. Si desarrollas
9:05
Speaker 2: una app que debe reaccionar rápido, cómo enviar un correo
9:07
Speaker 2: urgente al modificar un documento crítico, las notificaciones de cambio
9:11
Speaker 2: son tu mejor aliado. Recibes una notificación en el momento
9:13
Speaker 2: en que ocurre. Sin embargo, con las aplicaciones presenciales, primero
9:16
Speaker 2: necesitas un punto de conexión HTTPS de acceso público. Eso
9:19
Speaker 2: significa que tu aplicación debe ser accesible desde Internet. Para
9:21
Speaker 2: apps dentro de una red corporativa, esto supone un problema
9:24
Speaker 2: de seguridad. Debes abrir puertos, gestionar certificados y gestionar el
9:27
Speaker 2: tráfico entrante. En segundo lugar, debes gestionar la validación. Cuando
9:30
Speaker 2: creas una suscripción, Microsoft Graph envía un token de validación
9:33
Speaker 2: a tu punto de conexión. este debe devolver ese token
9:36
Speaker 2: en texto sin formato en un plazo de 10 segundos.
9:38
Speaker 2: Si no lo hace, la suscripción falla. En tercer lugar,
9:40
Speaker 2: las suscripciones caducan. Debes renovarlas antes de que caduquen o
9:43
Speaker 2: dejarás de recibir notificaciones. En cuarto lugar, los rindes. Si
9:47
Speaker 2: tu punto de conexión no responde en un plazo de
9:48
Speaker 2: 3 segundos, Microsoft Graph vuelve a intentarlo con un retraso
9:51
Speaker 2: exponencial de hasta 4 horas. Si tu punto de conexión
9:53
Speaker 2: es lento, las notificaciones podrían perderse. Para la extracción, la
9:57
Speaker 2: ventaja de la consulta Delta es una infraestructura más sencilla.
9:59
Speaker 2: Sin puntos de conexión públicos ni tráfico de entrantes que gestionar.
10:02
Speaker 2: Simplemente realiza solicitudes salientes de tu aplicación. Eso es todo.
10:05
Speaker 2: También tienes más control sobre cuándo suceden las cosas. Puedes
10:08
Speaker 2: programarlas para horas de menor actividad. Puedes procesarlas por lotes
10:11
Speaker 2: y puedes procesar los cambios a tu propio orden. Pero
10:13
Speaker 2: la extracción también tiene ideas de venta. Nuevamente, mayor la cantidad.
10:15
Speaker 2: Solo tendrás de los cambios cuando lo solicites. Si extraes
10:18
Speaker 2: cada hora, podrías llegar a retrasarte hasta una hora. La
10:20
Speaker 2: caducidad del token es otro río. Si no sincronizas con
10:22
Speaker 2: la frecuencia suficiente, tu token muere y tienes que empezar
10:24
Speaker 2: de nuevo. Y está el esfuerzo desperdiciado de sondear incluso
10:27
Speaker 2: cuando nada ha cambiado. Realizas la solicitud, obtienes una respuesta
10:30
Speaker 2: vacía y tienes que volver a hacerlo en el siguiente ciclo.¿
10:32
Speaker 2: Cuál deberías elegir? Depende. Si requieres baja latencia, para alertas
10:36
Speaker 2: de correo urgentes o colaboración en tiempo real, usa notificaciones
10:39
Speaker 2: de cambios. Si realizas una sincronización masiva, mantienes una base
10:42
Speaker 2: de datos local o creas una aplicación que funcione sin conexión,
10:45
Speaker 2: usa Delta Query. Cada uno en su lugar. El enfoque
10:48
Speaker 2: híbrido es lo mejor de ambos mundos. En realidad no
10:51
Speaker 2: tienes que elegir uno u otro. El enfoque más inteligente
10:53
Speaker 2: es usar ambos a la vez. Este es el patrón.
10:56
Speaker 2: Configuras notificaciones de cambios para que te avisen cuando algo cambia.
10:59
Speaker 2: Esto te da información casi en tiempo real. Sabes que
11:01
Speaker 2: algo ha sucedido, pero no sabes necesariamente qué ha cambiado exactamente.
11:04
Speaker 2: O no quieres procesar la carga útil completa en cada notificación.
11:06
Speaker 2: Así que en su lugar usas esa notificación como disparador.
11:10
Speaker 2: Cuando recibes una notificación push que indica que algo ha cambiado,
11:12
Speaker 2: llamas a la consulta Delta para obtener exactamente qué ha cambiado.
11:15
Speaker 2: Piensa en lo que esto te ofrece. Solo extraes datos
11:17
Speaker 2: cuando hay un cambio real, sin sondeos desperdiciados. Obtienes la
11:20
Speaker 2: confiabilidad de los tokens. Puedes rastrear cambios con el tiempo,
11:23
Speaker 2: gestionar la paginación y recuperar de fallos. Y evitas la
11:26
Speaker 2: complejidad de gestionar cargas útiles de cambios completas en cada notificación.
11:30
Speaker 2: La notificación solo dice, oye, mira aquí. La consulta Delta
11:33
Speaker 2: se encarga del trabajo pasado. Este es un escenario real.
11:36
Speaker 2: Imagina una aplicación que sincronice perfiles de usuario desde Microsoft Entrails.
11:39
Speaker 2: Te suscribes a las notificaciones de cambios para el recurso
11:41
Speaker 2: del usuario. Cuando alguien actualiza su puesto de trabajo, Microsoft
11:45
Speaker 2: Graph envía una notificación a tu punto de conexión. Tu
11:47
Speaker 2: aplicación recibe esa notificación y dice, bien, algo cambió con
11:49
Speaker 2: ese usuario. Luego llama al punto de conexión de la
11:52
Speaker 2: consulta Delta con su token guardado. La consulta Delta devuelve
11:55
Speaker 2: los detalles actualizados del usuario. Tu aplicación procesa el cambio
11:58
Speaker 2: y actualiza su base de datos local. Listo. Este patrón
12:00
Speaker 2: es compatible de forma nativa con Microsoft Graph. Creas una
12:03
Speaker 2: suscripción para las notificaciones de cambios. Mantienes un enlace Delta
12:06
Speaker 2: para el mismo recurso. Cuando llega una notificación, activas un
12:09
Speaker 2: ciclo de consulta Delta. Es el enfoque recomendado para aplicaciones
12:12
Speaker 2: de producción. La propia documentación de Microsoft lo menciona como
12:15
Speaker 2: la forma de eliminar casi por completo el sonido frecuente.
12:17
Speaker 2: Esta es una forma sencilla de imaginarlo. Te toca el timbre.
12:20
Speaker 2: Indica que hay alguien en la puerta. No tienes que
12:22
Speaker 2: quedarte fuera esperando que llegue visitando. Pero el timbre no
12:24
Speaker 2: te dice quién es. Entonces revisas la cámara. Eso es pool.
12:27
Speaker 2: Miras el feed para ver quién está ahí. Timbre más cámara.
12:30
Speaker 2: Push más pool. Eficiente y receptivo. Ese es el patrón híbrido.
12:34
Speaker 2: Para la mayoría de las aplicaciones reales, este es el
12:36
Speaker 2: estándar de oro. Obtienes la inmediatez de las notificaciones push
12:39
Speaker 2: con la minuciosidad de la consulta delta. Y evitas las
12:41
Speaker 2: debilidades de cada enfoque cuando se usa por separado. Reglas
12:45
Speaker 2: prácticas para compilar con el consultorio. Hola a todos y
12:47
Speaker 2: bienvenidos a otro episodio de Microsoft Knowledge Nuggets en M365FM.
12:50
Speaker 2: Soy su presentador Milkoop. Hoy hablaremos sobre la compilación con
12:54
Speaker 2: la consulta Delta en producción. Se reducen unas cuantas reglas estrictas.
12:56
Speaker 2: Los que evitan que tu sincronización falle en silencio un
12:59
Speaker 2: domingo a las 12. Sigue estas seis reglas y tu
13:01
Speaker 2: implementación será sólida. Si te saltas una, estarás buscando problemas.
13:05
Speaker 2: Regla número uno. Guarda tu enlace Delta en un lugar seguro.
13:07
Speaker 2: No en un archivo de texto en tu escritorio. No
13:09
Speaker 2: codificado en tu código. Usa una base de datos o
13:11
Speaker 2: un keystone. Piensa en este enlace como la llave de
13:14
Speaker 2: tu edificio. Si lo pierdes, quedarás bloqueado. Volverás al punto
13:16
Speaker 2: de partida con la sincronización completa. Es posible que tengas
13:19
Speaker 2: que volver a descargar gigabytes de datos. Regla 2. Ejecuta
13:22
Speaker 2: tu bucle de sincronización cada seis días. Los tokens de
13:24
Speaker 2: directorio caducan a los siete. Si programas la sincronización para
13:27
Speaker 2: siete días en punto, no tendrás margen de error. Un
13:29
Speaker 2: fallo de red, un fin de semana festivo, un reinicio
13:32
Speaker 2: del servidor y tu token estará inactivo. Seis días te
13:34
Speaker 2: dan un día completo de buffer. Regla 3. Espera el
13:36
Speaker 2: error cuatro días. Va a ocurrir. Microsoft Graph invalidará tu
13:39
Speaker 2: token durante el mantenimiento de una migración de inquilinos. Cuando
13:42
Speaker 2: lo haga, tu código deberá detectarlo, activar una resincronización completa
13:45
Speaker 2: y obtener una bomba. No lo trates como un error,
13:47
Speaker 2: trátalo como una parte normal del ciclo de vida. Regla 4.
13:50
Speaker 2: Diseña tu aplicación para gestionar duplicado. Las repeticiones son reales.
13:53
Speaker 2: El mismo cambio puede aparecer en dos respuestas consecutivas. Si
13:56
Speaker 2: estás insertando registros, comprueba primero si existe. Si actualizas campos,
14:00
Speaker 2: asegúrate de que sea seguro repetir la actualización. Quinta regla.
14:04
Speaker 2: Empieza poco a poco. No apuntes tu código a un
14:07
Speaker 2: inquilino con 10.0 usuarios en tu primer intento. Usa Graph Explorer.
14:11
Speaker 2: Elige un intervalo de fechas corto. Verifica que tu enlace
14:13
Speaker 2: de delta funcione. Haz un cambio, comprueba si aparece y
14:15
Speaker 2: familiarízate con el flujo antes de ampliarlo. Sexta regla, vigila
14:19
Speaker 2: tus límites de velocidad. Microsoft Graph te limitará si llamas
14:21
Speaker 2: demasiado rápido. Piensa en ello como en autopista. Si aceleras demasiado,
14:25
Speaker 2: te bloquearán. Las consultas delta ayudan a reducir el volumen
14:28
Speaker 2: de llamadas, pero aún así debe respetar los límites. Pase
14:31
Speaker 2: a tus solicitudes. Usa la reducción exponencial cuando veas un 409.
14:34
Speaker 2: Tu velocidad de sincronización no importa si estás bloqueado. Un
14:38
Speaker 2: ejemplo real, sincronizar eventos de calendario.¿ Cómo funciona esto realmente?
14:42
Speaker 2: Supongamos que creas una aplicación que sincronice eventos de calendario.
14:45
Speaker 2: Este es el flujo de principio a fin. Paso 1.
14:47
Speaker 2: Haces tu primera solicitud al endpoint delta de vista de calendario.
14:50
Speaker 2: Algo como obtener la vista delta con una hora de
14:52
Speaker 2: inicio y de finalización. Esta es tu línea básica. Microsoft
14:56
Speaker 2: Graph devuelve todos los eventos en este rango. Quizás sean
14:59
Speaker 2: 100 eventos, quizás sean 1000 en la parte inferior. De
15:01
Speaker 2: esa respuesta obtienes un enlace delta. Lo guardas. Paso 2.
15:04
Speaker 2: Ciclo de sincronización siguiente. Una hora después, un día después,
15:07
Speaker 2: llamas al enlace delta guardado. Esta vez Graph no devuelve todo.
15:10
Speaker 2: Son los cambios. Piensa en ello como un bibliotecario. Solicitas
15:14
Speaker 2: los libros que han cambiado desde tu última visita, mucho
15:16
Speaker 2: más rápido que volver a leer toda la biblioteca. Una
15:18
Speaker 2: nueva reunión, una existente movida, una hora diferente. Y si
15:21
Speaker 2: se eliminó algo, aparece con una propiedad arroba remove para
15:24
Speaker 2: que sepas que debes eliminarlo de tu tienda local. Paso 3.
15:27
Speaker 2: Si hay muchos cambios, es posible que obtengas un enlace
15:29
Speaker 2: siguiente en lugar de un enlace delta. Eso significa que
15:31
Speaker 2: hay más cambios que procesar. llamas a ese siguiente enlace
15:34
Speaker 2: obtienes el siguiente lote y sigues hasta que finalmente ves
15:36
Speaker 2: un enlace delta así como sabes que estás al día
15:38
Speaker 2: piensa en lo que esto te ahorra con el tiempo
15:40
Speaker 2: quiero decir piensa realmente