Saltar al contenido
Alberto LaraAnálisis y arquitectura EdTech
Ir a la web
Dos registros de matrículas se comparan para preparar una revisión de diferencias, conservando accesos de otros orígenes. Ilustración conceptual.

Arquitectura de softwareOperación y automatización· 6 min

Reconciliar matrículas entre Moodle y el sistema académico

Cómo comparar registros con el mismo alcance, conservar matrículas de otros orígenes y revisar diferencias antes de aplicar cambios.

AL

Un informe encuentra a una estudiante matriculada en Moodle que no aparece en la última extracción del sistema académico. La respuesta rápida sería darla de baja para que ambos listados coincidan. Pero todavía falta saber si la extracción está completa y de dónde procede esa matrícula.

La relación puede haberla creado la integración académica, una cohorte o una intervención manual autorizada. También puede corresponder a otra edición del curso. Comparar dos listas sin conservar esas diferencias puede retirar un acceso válido o esconder un fallo del intercambio.

Reconciliar consiste en comparar estados que representan el mismo ámbito, explicar sus diferencias y decidir cuáles deben corregirse. El caso de este artículo es hipotético; el laboratorio utiliza identificadores y matrículas ficticios.

El ámbito se fija antes de comparar personas

Primero delimitaría qué edición, colectivos, métodos y periodos cubre la ejecución. «Todas las matrículas» resulta ambiguo si una fuente exporta estudiantes activos y la otra incluye también docentes, participantes suspendidos o personas de convocatorias anteriores.

La extracción debe conservar su origen, alcance, momento y señal de finalización. Una ejecución sin errores de transporte puede contener solo la primera página de resultados. El receptor necesita comprobar la integridad que permita el contrato de esa fuente, además de conocer cómo se representa una extracción vacía.

Una marca de completitud declarada por el productor ayuda a decidir, pero no demuestra por sí sola que los filtros sean correctos. Si cambia el alcance del fichero, se pierden páginas o aparece una caída anómala del número de registros, hay que revisar la comparación antes de proponer retiradas.

Los identificadores también tienen que estar relacionados. El nombre del curso no identifica necesariamente su edición y el correo de una persona puede cambiar. Un registro que no puede vincularse de manera inequívoca debe quedar como incidencia; elegir la coincidencia más parecida no resuelve el contrato de identidad.

La integración no gobierna todas las matrículas del curso

Moodle admite distintos métodos de matriculación. Una persona puede tener más de una relación de acceso con el mismo curso. Para reconciliar hace falta identificar cuáles mantiene esta integración y qué significa el estado de cada una.

Compartir el método manual tampoco demuestra compartir el origen. Si una persona y la integración utilizan la misma instancia, hace falta un registro fiable de qué relaciones administra el conector. El método, por sí solo, no identifica al responsable de cada alta.

Si el sistema académico deja de justificar una matrícula gestionada por él, puede proceder revisar esa relación. Eso no autoriza automáticamente a eliminar otra matrícula que tenga un origen distinto, ni demuestra que deba desactivarse la cuenta de la persona.

La integración con sistemas académicos explica el reparto de autoridad entre identidad, oferta, matrícula y calificaciones. En la reconciliación ese reparto debe convertirse en reglas que permitan clasificar cada diferencia.

Dos extracciones con el mismo alcance se relacionan por identidad, edición y origen. Las diferencias se clasifican en coincidencias, propuestas revisables, relaciones de otro origen que se conservan e incidencias que bloquean cambios.

La comparación produce decisiones revisables. Una ausencia en una extracción incompleta no se interpreta como una baja, y una matrícula de otro origen queda fuera de la corrección automática.

La comparación produce decisiones revisables. Una ausencia en una extracción incompleta no se interpreta como una baja, y una matrícula de otro origen queda fuera de la corrección automática.

Clasificar antes de construir una lista de cambios

Prepararía al menos estas salidas, ajustadas al método de matrícula y al procedimiento académico:

DiferenciaDecisión que debe quedar visible
La relación coincide en ambos sistemasNo necesita cambios por esta comparación.
La fuente justifica un alta que falta en destinoProponer el alta con la edición y el rol acordados.
La relación gestionada existe con un estado diferenteRevisar qué transición corresponde y cuándo debe hacerse efectiva.
Aparece solo en destino y la extracción de referencia está completaInvestigar una posible retirada dentro del ámbito gestionado.
Aparece solo en destino y la extracción está incompletaBloquear la interpretación de esa ausencia como baja.
La relación de destino procede de otro origenConservarla fuera del conjunto que modifica esta integración.
Falta una correspondencia o hay una clave repetida sin resolverSeparar la incidencia antes de proponer cambios sobre ese caso.

Una clave repetida puede representar dos matrículas legítimas que el modelo de comparación ha simplificado demasiado. Antes de eliminar duplicados hay que comprobar si faltaba una edición, un grupo, un método o un identificador de relación. La clasificación debe mostrar el problema en lugar de decidir qué fila sobra por su posición en el fichero.

La propuesta de retirada merece atención específica. Suspender una matrícula, desmatricular y eliminar una cuenta son operaciones diferentes. El método utilizado y la configuración determinan sus efectos; el responsable académico debe acordar qué transición corresponde y qué información debe conservarse. Un listado de diferencias no toma esa decisión por él.

Un laboratorio que solo produce un plan

El laboratorio de reconciliación contiene dos conjuntos sintéticos y genera una clasificación. Incluye un alta pendiente, un cambio de estado, una relación ausente en la fuente, una matrícula de otro origen, una identidad sin correspondencia y una clave repetida.

La misma entrada se compara después como extracción incompleta. La relación que aparecía solo en destino deja de ser candidata a retirada por ausencia y queda bloqueada para esa decisión. Puedes consultar el resultado ejecutado y la plantilla para preparar una comparación.

El programa no se conecta a Moodle ni al sistema académico y no aplica altas o bajas. Su utilidad es hacer discutibles las reglas antes de darles permisos para modificar una instalación. La correspondencia entre los estados sintéticos y las operaciones reales debe definirse para cada integración.

Un plan revisado también puede quedarse antiguo

Entre extraer los datos y aprobar los cambios puede modificarse una matrícula. Por eso el plan debe conservar las versiones o huellas de las entradas, las correspondencias, las reglas y la decisión que justificó cada propuesta. El laboratorio muestra una comprobación de vigencia sobre sus datos sintéticos de entrada: si cambian los registros, las correspondencias o la versión de las reglas, el plan anterior no se acepta como vigente.

En una integración real hay que volver a comprobar el estado relevante antes de aplicar la operación. Esa lectura previa, por sí sola, no elimina una carrera si otra tarea puede modificar el mismo registro inmediatamente después. Cuando el destino no ofrece una actualización condicionada a la versión, hacen falta una coordinación efectiva o un procedimiento que resuelva esos conflictos.

Los eventos duplicados o fuera de orden son una de las causas de discrepancia que conviene investigar. La reconciliación puede detectar el resultado, pero no sustituye la reparación del receptor que sigue introduciendo el mismo error.

Cerrar la diferencia exige otra comprobación

Tras aplicar una corrección autorizada, el proceso vuelve a leer la relación y registra si se alcanzó el resultado esperado. Si la operación queda incierta, se conserva ese estado para investigar o recuperar; no se cierra la incidencia porque se haya enviado la petición.

El responsable de la integración necesita distinguir diferencias resueltas, casos que esperan una decisión académica y fallos de datos que deben corregirse en origen. La finalidad es que cada relación tenga una explicación y un tratamiento coherente. Conseguir dos listados idénticos a costa de borrar relaciones que la integración no gobierna sería un mal resultado.

Conversar y compartir

¿Comentamos el artículo?

Escríbeme directamente para comentar cualquier punto técnico, compártelo si te ha parecido interesante o ábrelo en ChatGPT para contrastar ideas.

AL
Alberto Lara Hernández
Director tecnológico y arquitecto de sistemas de aprendizaje

Más de 22 años construyendo y evolucionando plataformas de aprendizaje en producción.

Sobre Alberto Lara y su trayectoria profesional →

Seguir leyendo