Personas duplicadas
Encuentro a la misma persona dos veces porque cambió de correo o de departamento y la sincronización la trató como nueva. A partir de ahí, veo su historial partido en dos.
Moodle · Integraciones
Integraciones de Moodle: referencias, responsables, errores y reconciliación
No atribuyo automáticamente a un fallo aislado de programación los usuarios duplicados, las matrículas que desaparecen, las finalizaciones que no coinciden ni las jerarquías caducadas. También compruebo decisiones que pudieron quedar sin definir al conectar los dos sistemas: cuál sirve de referencia para cada dato, qué equipo responde de su calidad, qué ocurre cuando el otro sistema no responde y cómo detectar las divergencias. Trato cada integración como un contrato entre dos equipos que evolucionan por separado. Documento ese contrato porque cualquier cambio en uno de los sistemas puede provocar un incidente. Sin ese registro, puedo descubrirlo semanas después, al encontrar una discrepancia sin explicación registrada.
- Cada dato necesita un sistema de referencia y un equipo responsable. Cada persona o entidad sincronizada necesita, además, un identificador estable que no cambie con el nombre o el correo.
- La operación debe poder repetirse sin cambiar el resultado efectivo después de la primera aplicación, aunque la respuesta técnica pueda variar.
- Sin un mecanismo de reconciliación o detección equivalente, una divergencia puede pasar inadvertida hasta que alguien se queje.
- Una integración síncrona sin límite de espera traslada la caída del otro sistema a las peticiones que dependen de ella y, bajo carga, puede degradar o llegar a tumbar Moodle.
Experiencia en integraciones
Defino qué sistema actúa como referencia para cada dato, qué identificador une los registros y qué equipo responde de su calidad. Diseño operaciones idempotentes, elijo entre eventos y sincronización periódica y añado reconciliación para detectar duplicados, matrículas desaparecidas y divergencias entre sistemas.
Mi trayectoriaCuándo se nota
Reconozco el patrón: todo funcionó durante meses y, de pronto, los números dejan de cuadrar.
Matrículas que desaparecen
He visto a alguien perder el acceso a un curso a mitad de convocatoria porque una sincronización le retiró la matrícula. Casi siempre encuentro la causa en un dato que cambió en el otro sistema.
Los informes no coinciden
Recursos humanos dice que hay ochocientas personas formadas y la plataforma dice setecientas cuarenta. Comparo los registros uno a uno. Sin esa comparación, no puedo determinar cuál es la cifra correcta.
Un sistema externo se cae y Moodle se cae con él
He visto llamadas síncronas sin límite de espera que bloquean peticiones hasta agotar el servidor. Desde fuera, parece que «el campus no va».
Las seis decisiones que forman el contrato de la integración
Ninguna es técnica del todo. Las acuerdo con el equipo del otro sistema antes de escribir una línea de código.
- 01
Qué sistema es la referencia de cada dato y qué equipo responde de su calidad
Para cada campo —nombre, correo, departamento, matrícula, calificación— decido qué sistema actúa como referencia y qué equipo responde de su calidad. Cuando dos sistemas pueden modificar el mismo campo, los cambios pueden pisarse y la reconciliación queda sin un criterio fiable.
- 02
Qué identificador une los registros
Uso un identificador interno diseñado para mantenerse estable: no el correo, que cambia, ni el nombre, que se repite. Si alguna vez debo sustituirlo, conservo en la integración una correspondencia explícita entre el identificador anterior y el nuevo para seguir reconociendo a la misma persona entre entornos.
- 03
Cómo elijo entre eventos y sincronización periódica
Con los eventos reduzco la latencia, pero necesito garantizar la entrega, asegurar la idempotencia, reintentar los envíos y vigilar los mensajes que quedan sin procesar. La sincronización periódica simplifica algunos intercambios y facilita la reconciliación, aunque añade retraso y también debe poder reanudarse. En muchos casos combino los eventos con una comparación periódica.
- 04
Cómo gestiono una operación repetida
Diseño la operación para que recibir dos veces el mismo mensaje no duplique el efecto. Los reintentos son habituales; si el primer intento aplicó el cambio pero se perdió la confirmación, repetir una operación sin esa propiedad puede crear un duplicado.
- 05
Qué hago cuando el otro sistema no responde
Defino el límite de espera, el número de reintentos, una espera creciente entre ellos y un lugar para los mensajes que no se han podido procesar. Con estas medidas evito que un fallo temporal del origen cause una pérdida silenciosa de datos.
- 06
Cómo detecto una divergencia
Comparo periódicamente los registros de ambos lados: cuento cuántos hay y señalo las diferencias. Así detecto una discrepancia mediante una alerta, en lugar de enterarme por una reclamación.
Cómo decidir el diseño
Cinco preguntas que respondo junto al equipo responsable del otro sistema.
- 01
¿Qué sistema manda sobre cada dato?
Si no puedo decir qué sistema manda en cada campo, no considero diseñada la integración. Insisto en esa conversación porque es la que más se evita y la que más incidentes ahorra.
- 02
¿Qué identificador está diseñado para mantenerse estable?
El correo cambia y no lo uso como clave estable. Si empleo un documento de identidad, justifico su necesidad, alcance, ciclo de vida y garantías. Siempre que puedo, uso un identificador interno e inmutable que sobreviva a los cambios de nombre, correo o unidad.
- 03
¿Con cuánto retraso es aceptable que llegue el dato?
Si basta con recibir el dato media hora más tarde, uso un proceso periódico para simplificar la operación, aunque su coste crece con el volumen. Si necesito menos latencia, uso eventos con entrega duradera, idempotencia y reanudación. En ambos diseños añado reconciliación cuando el riesgo de divergencia lo exige.
- 04
¿Qué debe ocurrir si el otro sistema no responde?
Elijo entre reintentar, encolar, avisar o seguir sin ese dato. Tomo la decisión antes para que no la imponga el comportamiento por defecto, que suele perder la información en silencio.
- 05
¿Cómo sabremos que han divergido?
Sin reconciliación periódica u otro mecanismo automático equivalente, una divergencia puede permanecer oculta hasta que alguien se queje. Para entonces, la discrepancia puede haberse convertido en una incidencia con usuarios afectados.
Lo que suele romperse
He detectado siete fallos en integraciones que llevaban tiempo funcionando.
Usar el correo como identificador
He visto cambiar una dirección de correo por una corrección o por un cambio de nombre, de dominio o de política interna. Si una integración usa el correo como identificador estable, cada cambio puede crear una persona nueva y partir su historial.
Sincronización sin control de duplicados
He visto cómo un reintento tras un fallo de red crea dos veces el mismo registro. Sin idempotencia, no puedo asegurar la fiabilidad sin generar duplicados.
Borrados en cascada desde el origen
Un fallo en el sistema de personal que devuelve una lista vacía desmatricula a toda la plantilla. Pongo límites de seguridad al porcentaje de cambios que una sincronización puede aplicar sin confirmación.
Llamadas síncronas sin límite de espera
He visto cómo la lentitud de otro sistema ralentiza Moodle y cómo su caída derriba también la plataforma.
Tokens de acceso sin protección ni rotación
Detecto tokens de acceso con permisos amplios, sin caducidad y compartidos entre integraciones. También detecto que falta un inventario de los procesos que podrían verse afectados al revocar uno.
Sin registro de lo que hizo la integración
Cuando detecto una discrepancia, no puedo reconstruir qué se envió, cuándo ni qué respuesta recibió. Acabo investigando como un arqueólogo.
Cambios de versión sin avisar
Si el otro equipo cambia un campo sin avisar, descubro el cambio cuando algo falla. Versiono el contrato de integración para que sus despliegues no introduzcan riesgos en mi sistema.
Qué cambia con el volumen
Compruebo si el diseño que funciona con cien personas sigue sirviendo con cincuenta mil.
- Cientos de registros
Elijo una sincronización completa y periódica cuando basta y puedo prever bien su comportamiento. Mido su tiempo, las consultas y la carga antes de fijar la frecuencia.
- Decenas de miles
Si la sincronización completa deja de caber en la ventana, paso a cambios incrementales. Añado una reconciliación para detectar mensajes perdidos, mensajes que llegan fuera de orden o cambios que el flujo incremental no haya procesado.
- Picos de altas masivas
El inicio de curso o una campaña concentran miles de matrículas de golpe. Evito que la integración compita con las personas por la base de datos justo en el peor día: pongo una cola y controlo el ritmo.
- Varios sistemas conectados a la vez
Con cuatro o cinco integraciones, ya no me pregunto cómo funciona cada una. Decido en qué orden aplico los cambios y qué integración prevalece cuando dos escriben lo mismo.
Diez comprobaciones sobre vuestras integraciones
Las tres primeras explican la mayoría de las discrepancias que he visto.
- Puedo decir, campo a campo, qué sistema es la referencia del dato y qué equipo responde de su calidad.
- El identificador que une los registros está diseñado para permanecer estable; si debe sustituirse, existe una correspondencia explícita y trazable entre el anterior y el nuevo.
- Enviar dos veces la misma operación no crea dos registros.
- Hay límite de espera en todas las llamadas a sistemas externos.
- Los mensajes que fallan acaban en algún sitio donde alguien los ve.
- Existe una comparación periódica que detecta divergencias sola.
- Una sincronización no puede borrar masivamente sin confirmación.
- Puedo reconstruir qué envió la integración un día concreto.
- Los tokens de acceso se asocian a un usuario y a un servicio; su alcance efectivo depende de las funciones del servicio y de las capacidades del usuario.
- Sé qué pasa si el otro equipo cambia su interfaz mañana.
Qué exigir sobre integraciones en un pliego
Cómo distingo una integración entregada de otra mantenible.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Contrato de integración documentado | Campos, sistema de referencia, equipo responsable, dirección del intercambio y frecuencia | Acordar el documento entre los dos equipos antes de desarrollar la integración |
| Identificador estable acordado | Campo elegido y justificación de su estabilidad | Probar el cambio de correo y de unidad sin crear un duplicado de la persona |
| Comportamiento ante errores | Tiempos máximos de espera, reintentos y destino de los mensajes fallidos | Probar el funcionamiento con el sistema externo caído y comprobar que no se pierdan datos |
| Reconciliación periódica | Informe automático de diferencias entre los dos sistemas | Informe generado y revisado con periodicidad acordada |
| Registro de operaciones | Registro de lo enviado, el momento del envío y la respuesta recibida | Reconstruir un caso concreto a partir del registro |
| Versionado del contrato | Política de cambios y preaviso entre equipos | Un cambio de versión no rompe la integración en producción |
Los arreglos que agravan el problema
Ante una discrepancia, distingo tres reacciones habituales. Todas son comprensibles y contraproducentes.
Corregir a mano el registro que no cuadra
Si corrijo a mano el registro que no cuadra, recupero la coherencia esta tarde. Como no he tocado la causa, mañana vuelve a descuadrarse y ahora, además, nadie recuerda qué cambié a mano ni por qué.
Sincronizar más a menudo
Si ejecuto la sincronización cada quince minutos en vez de una vez al día, multiplico la carga y no arreglo la lógica. Si la sincronización duplica registros, ahora los duplica noventa y seis veces al día.
Volcar todo cada noche
Si borro y recargo, parece una solución limpia, pero destruyo lo que solo existía en Moodle, pierdo los cambios locales y convierto cualquier fallo del origen en un borrado masivo.
Referencias
Fuentes y límites
- Documentación oficialServicios web — documentación oficial de Moodle
Funcionamiento general y autenticación mediante tokens de acceso. Consultado el 1 de agosto de 2026.
- Documentación oficialDocumentación para desarrolladores de servicios web
Definición de funciones externas, parámetros y control de permisos. Consultado el 1 de agosto de 2026.
- EstándarLearning Tools Interoperability — 1EdTech
Especificación del estándar de interoperabilidad para herramientas de aprendizaje. Consultado el 1 de agosto de 2026.
Las seis decisiones del contrato son criterio propio, formado diseñando y reparando integraciones concretas: no proceden de una norma publicada, aunque coinciden con prácticas habituales de integración de sistemas. Lo relativo a servicios web y estándares está en las fuentes enlazadas y hay que comprobarlo allí, porque cambia entre versiones. No publico detalles de integraciones de organizaciones concretas.
Blog
Casos, pruebas y fuentes.
En el blog desarrollo casos particulares, pruebas y fuentes que amplían esta página de referencia.
Ir a blog.albertolarah.comContacto
Cuando los datos de Moodle y los del otro sistema dejan de coincidir
Empiezo por el mapa: qué sistemas están conectados, en qué dirección va cada dato, cada cuánto se sincroniza y desde cuándo aparece la discrepancia. Primero compruebo cuál es el sistema de referencia y quién responde de cada dato; después reviso el contrato, la entrega y los cambios recientes.
hola@albertolarah.comLinkedIn ↗