Una integración con el sistema de información estudiantil es lo que permite que un sitio web universitario muestre catálogos de cursos, horarios de clases y requisitos de los programas sin que nadie tenga que volver a escribirlos. Los datos residen en Banner, PeopleSoft, Workday o en un sistema propio; Drupal los lee, les da forma y los publica. En este artículo exponemos los tres patrones que puede seguir la integración, cómo expone sus datos cada una de las principales plataformas, qué sistema debería ser dueño de qué, y los puntos de fallo que conviene planificar antes del primer cambio de período académico.
La mayoría de las descripciones de este tema se detienen en una sola frase: Drupal se integra con los sistemas de información estudiantil. Eso es cierto, pero poco útil. Las preguntas a las que se enfrenta realmente un equipo web son otras. ¿Los datos de los cursos se copian en Drupal o se leen en tiempo real? ¿Qué ocurre cuando la oficina de registro da de baja una sección a mitad de período? ¿Dónde vive el texto de marketing de un programa si la descripción oficial está en el SIS? ¿Cuál de los dos sistemas tiene razón cuando entran en conflicto? A continuación abordamos esas preguntas con las plataformas que usa la mayoría de las universidades.
Qué hace realmente una integración con el sistema de información estudiantil en un sitio web universitario
El sistema de información estudiantil es el sistema de registro oficial de la institución para los datos académicos. Contiene el catálogo de cursos, el horario de clases, los requisitos de programas y titulaciones, las matrículas, las calificaciones, los expedientes y el calendario académico. Nada en el sitio web público debería contradecirlo.
El sitio web, a su vez, es donde realmente se ve la mayor parte de esos datos. Los estudiantes potenciales leen las páginas de los programas. Los estudiantes actuales comprueban cuándo se imparte una sección. Los tutores académicos consultan los requisitos previos. Cuando el sitio web y el SIS se desalinean, el sitio web es el que está equivocado, y quienes lo notan son precisamente las personas a las que la universidad menos quiere decepcionar.
Una integración elimina la necesidad de volver a escribir los datos entre ambos sistemas. En la práctica cubre una lista bastante breve de tipos de datos, y conviene nombrarlos porque cada uno se comporta de forma distinta:
- Catálogo de cursos: códigos de curso, títulos, valores de crédito, descripciones y requisitos previos. Cambia unas pocas veces al año, ligado a un año de catálogo.
- Horario de clases: secciones, horarios, aulas, docentes y plazas disponibles. Cambia a diario durante el periodo de matrícula.
- Programas y requisitos: titulaciones, especializaciones y las reglas que las vinculan con los cursos. Cambia raramente, pero con aprobación formal.
- Calendario académico y períodos: códigos de período, plazos de alta y baja, festivos. Pequeño, estable y referenciado por todo lo demás.
- Registros específicos del estudiante: el horario de un estudiante en particular, retenciones administrativas, avance en la titulación. Datos personales, que solo se muestran a ese estudiante tras autenticarse.
Los primeros cuatro son datos institucionales y pueden aparecer en páginas públicas. El último son datos personales y sigue reglas distintas, a las que volveremos más adelante.
Tres patrones de integración y cuándo encaja cada uno
Casi toda integración de SIS en un sitio Drupal responde a uno de tres patrones, y elegir el equivocado es la fuente más común de problemas posteriores. Los factores determinantes son la frecuencia con la que cambian los datos, cuánta gente los lee y si pertenecen a una persona concreta.
Importación programada para páginas de catálogo y programas
El SIS exporta los datos de cursos y programas según un calendario, normalmente cada noche, y Drupal los importa como contenido ordinario: un tipo de contenido para cursos, un tipo de contenido para programas, términos de taxonomía para materias y períodos. La API Migrate del núcleo de Drupal se encarga de esto, con los módulos contribuidos Migrate Plus y Migrate Tools añadiendo fuentes JSON, XML y CSV, además de las herramientas para ejecutar y revertir importaciones. El módulo Feeds es la alternativa con menos código para fuentes más sencillas.
Una vez importados, los datos se comportan como cualquier otro contenido de Drupal. Son buscables, cacheables, traducibles y pueden referenciarse desde otras páginas. Los editores pueden añadir campos que el SIS no tiene, como un resumen de marketing, una imagen destacada o testimonios, sin tocar el registro oficial. La Universidad de Dundee construyó así sus páginas de cursos, como entidades personalizadas, las indexó con Search API junto con personas y facultades, y lanzó la sección de cursos de grado como su primera versión en julio de 2019.
Este patrón encaja con datos que cambian según un ciclo conocido y son leídos por muchas personas. No encaja con nada que cambie cada hora, porque una importación nocturna siempre irá con retraso.
Lectura en vivo para disponibilidad y horarios
Aquí no se copia nada. Drupal consulta la API del SIS cuando se solicita una página y muestra el resultado. El módulo External Entities está pensado exactamente para esto: define un tipo de entidad cuyo almacenamiento es un endpoint REST remoto en lugar de la base de datos de Drupal, de modo que los datos remotos se pueden seguir usando con Views, modos de visualización y formateadores de campo. Views Remote Data ofrece una vía más ligera cuando solo se necesita un listado.
La lectura en vivo es la respuesta correcta para el número de plazas, el estado de una sección y cualquier otro dato en el que un valor desactualizado induzca a error. Tiene dos costes. Cada visita a la página se convierte en una llamada a la API a menos que se aplique una caché cuidadosa, y la disponibilidad del sitio web pasa a depender de la disponibilidad de la API del SIS. Una caché corta con un tiempo de vida definido y un mensaje de repliegue adecuado cuando la API no está disponible no son extras opcionales. Sin ellos, el primer día de matrícula tumba el sitio web junto con el SIS.
Consultas autenticadas para datos específicos del estudiante
El tercer patrón cubre el portal del estudiante: mi horario, mis retenciones, mi revisión del avance en la titulación. Los datos se obtienen bajo demanda para la persona que ha iniciado sesión, se muestran una sola vez y no se almacenan en Drupal en absoluto. La identidad proviene del inicio de sesión único del campus; el identificador del estudiante de esa sesión es el que se usa como clave en la consulta al SIS.
Este patrón depende de que la identidad se resuelva primero, porque un identificador incorrecto devuelve el registro del estudiante equivocado. Cubrimos las opciones en integración de SSO con SAML, Shibboleth, LDAP y CAS. Una vez resuelto esto, la llamada al SIS en sí suele ser una única solicitud contra un endpoint de persona o de estudiante, realizada del lado del servidor con las credenciales de API de la institución, nunca con nada expuesto al navegador.
Algunas universidades deciden que esta capa pertenece al propio producto de autoservicio del proveedor del SIS en lugar de al sitio Drupal, y se limitan a enlazar hacia él. Es una opción legítima y a menudo la más económica. Drupal se gana su lugar en el portal cuando la institución quiere combinar los datos del SIS con contenido, noticias, eventos y servicios que el SIS desconoce por completo.
Conectar Drupal con las principales plataformas
Cada proveedor expone sus datos de forma distinta, y esas diferencias determinan qué patrón es práctico en cada caso.
Ellucian Banner y Colleague a través de Ethos
La ruta recomendada por Ellucian para la integración con terceros es Ethos, una capa unificada REST y JSON que se sitúa por encima tanto de Banner como de Colleague. Ethos presenta un modelo de datos común, de modo que un curso, una sección o una persona tienen la misma estructura sea cual sea el producto subyacente, y cada registro lleva un GUID en lugar de un identificador específico del producto. Ethos se aloja de forma regional, con endpoints separados para Estados Unidos, Canadá, Europa y Asia-Pacífico, lo cual es relevante para instituciones con requisitos de residencia de datos.
Para Drupal, esto significa que un único conjunto de definiciones de recursos funciona tanto para los campus con Banner como con Colleague, y el módulo External Entities puede mapear el JSON de Ethos a campos mediante su mapeador JSONPath. El acceso se concede por recurso y por campo en el lado de Ellucian, por lo que la primera tarea del proyecto suele consistir en acordar con la oficina de registro qué recursos necesita el sitio web, y no en escribir código. Los campus con Banner más antiguos que no usan Ethos siguen exponiendo APIs directas y vistas de base de datos; funcionan, pero cada integración se vuelve específica de ese campus.
PeopleSoft Campus Solutions
Campus Solutions de Oracle expone datos a través de Integration Broker, su capa de mensajería y servicios web, usando REST o SOAP. Los datos de catálogo de cursos y horarios provienen del módulo Student Records, y el concepto que sorprende a la mayoría de quienes construyen la integración es la vigencia por fecha efectiva (effective dating): un curso no tiene una sola descripción, sino un historial de descripciones, cada una válida a partir de una fecha determinada, y la consulta debe pedir la correcta para el año de catálogo que se está mostrando.
Por eso la importación programada encaja bien con los datos de catálogo de PeopleSoft. La importación puede resolver las filas con fecha efectiva una sola vez, cada noche, y almacenar la versión vigente. Hacer esa resolución en cada solicitud en vivo sería un despilfarro. La lectura en vivo sigue siendo el patrón correcto para la disponibilidad de secciones, donde el valor es un único número actual.
Workday Student
Workday expone servicios web REST y SOAP y, para extractos con formato de informe, reportes personalizados que pueden publicarse como fuentes de datos. En la práctica, muchas integraciones de Workday Student se construyen sobre esos reportes: la oficina de registro define un reporte que contiene exactamente los campos de cursos y secciones que el sitio web puede ver, y Drupal lo consume según un calendario. Este enfoque mantiene explícito el contrato de datos y pone el control de lo que sale del SIS en manos de quienes son dueños de esos datos.
El modelo de períodos académicos de Workday difiere del de Banner y del de PeopleSoft, por lo que el mapeo de campos merece una sesión de diseño propia en lugar de asumirse a partir de un proyecto anterior.
Sistemas propios y regionales
Muchas universidades operan un sistema propio, una plataforma nacional o el producto de un proveedor regional. El patrón no cambia; solo cambia el medio de transporte. Si el sistema tiene una API, External Entities o un plugin de origen personalizado para Migrate pueden consumirla. Si solo puede producir archivos, un volcado programado de CSV o XML a una ubicación SFTP junto con una importación mediante Migrate es una integración perfectamente respetable, y a menudo más fiable que una API frágil. El punto clave es acordar el contrato de datos y el calendario, y luego mantener ambos estables.
Qué sistema es dueño de los datos
La decisión más importante del proyecto no es técnica. Es una declaración sobre quién es dueño de qué campos.
El SIS es dueño de todo lo académico y oficial: códigos de curso, títulos, créditos, requisitos previos, requisitos de programa, horarios, fechas de período. Drupal nunca edita esos datos; se limita a mostrarlos. Si una descripción de curso en el sitio web es incorrecta, la corrección se hace en el SIS y se propaga en la siguiente importación.
Drupal es dueño de todo aquello para lo que el SIS nunca fue diseñado: el relato de marketing del programa, las citas del profesorado, los resultados profesionales, las imágenes, las llamadas a la acción, las traducciones y los metadatos para motores de búsqueda. Esos campos residen en el lado de Drupal, vinculados al registro importado pero almacenados por separado, de modo que una importación nunca sobrescribe el trabajo de un editor.
Dejar esto por escrito en una tabla campo por campo, acordada por la oficina de registro y el equipo web antes de construir nada, evita las dos discusiones más habituales más adelante: un editor que cambió el valor de créditos en el sitio web y lo vio sobrescrito de la noche a la mañana, y una oficina de registro que no entiende por qué un curso que dio de baja sigue apareciendo en una página de aterrizaje construida a mano.
La escritura inversa desde Drupal hacia el SIS, en la que un formulario web crea o modifica un registro del SIS, es posible mediante Ethos e Integration Broker, pero pertenece a una categoría de riesgo distinta. La mayoría de las instituciones canalizan las acciones de solicitud y matrícula a través de los propios productos del proveedor del SIS o de un CRM de admisiones, y mantienen el sitio web en modo de solo lectura frente al SIS. Esa es la opción por defecto sensata.
Privacidad del estudiante en la capa de integración: FERPA y RGPD
En el momento en que una integración toca registros específicos de un estudiante, está tratando datos regulados. En Estados Unidos, la FERPA distingue entre los registros educativos, cuya divulgación requiere consentimiento, y la información de directorio, como el nombre y el programa, que una institución puede difundir salvo que el estudiante se haya opuesto. En la Unión Europea y en el Reino Unido, el RGPD se aplica a cualquier dato personal, y los principios de limitación de la finalidad y minimización de datos determinan cuánto de ellos puede obtener el sitio web.
Tres reglas mantienen una integración de Drupal dentro de lo permitido por ambos marcos normativos:
- Datos institucionales en páginas públicas, datos personales solo tras autenticación. Los catálogos y horarios son institucionales. El horario propio de un estudiante es personal.
- Obtener los datos personales bajo demanda y no almacenarlos. El patrón de consulta autenticada existe precisamente por este motivo. Ningún registro de estudiante debería residir en una tabla de Drupal ni en una caché de página a la que otro usuario pudiera acceder.
- Solicitar únicamente los campos que usa la página. Tanto Ethos como los reportes de Workday permiten a la institución delimitar el acceso por campo. Delimitarlo de forma estricta es el control de cumplimiento más económico disponible.
Registrar qué cuenta del sistema obtuvo qué dato, y cuándo, cierra el ciclo necesario para las auditorías. Cubrimos las obligaciones más amplias en cómo lograr el cumplimiento del RGPD con Drupal; la capa de integración es donde muchas de ellas se vuelven concretas.
Qué falla en la práctica y cómo planificarlo
Las integraciones rara vez fallan el día del lanzamiento. Fallan en el primer evento que el diseño no anticipó. Estos son los que se repiten.
- Cambio de período académico. El SIS abre un nuevo período mientras el sitio web sigue mostrando el anterior como vigente. Modele los períodos de forma explícita en Drupal y derive la noción de "período actual" a partir del calendario del SIS, no de una fecha fija en el código.
- Cursos dados de baja o fusionados. Un curso desaparece de la exportación, pero su página en Drupal, con sus enlaces entrantes y su posicionamiento en buscadores, sigue activa. Decida de antemano si la importación la despublica, la archiva con un aviso o la redirige a un sucesor.
- Cambios con fecha de vigencia. Una descripción válida a partir del próximo año de catálogo aparece en la página del año en curso porque la consulta no filtró por fecha. Es un caso clásico de PeopleSoft, pero el concepto existe en todas partes.
- Invalidación de caché. Los datos de lectura en vivo se almacenan en caché por rendimiento, y luego el número de plazas se queda en cero durante una hora después de que se liberen plazas. Defina el tiempo de vida por tipo de dato y acórtelo durante las ventanas de matrícula.
- Límites y caídas de la API. Un bloque de la página de inicio que llama al SIS en cada solicitud agotará el límite de peticiones la primera mañana de tráfico intenso. Aplique una caché agresiva, degrade el servicio con elegancia y nunca permita que una caída del SIS produzca una página en blanco.
- Desajustes de identificadores. La identidad del SSO usa un identificador y el SIS otro. Acuerde el mapeo antes de construir el portal y pruébelo con cuentas reales, incluyendo casos límite como el personal que también es estudiante.
Nada de esto es exótico. Un manual operativo de una sola página que cubra estos casos, redactado antes del lanzamiento, vale más que la mayor parte del código.
¿Hasta qué punto debe profundizar la integración?
No todas las universidades necesitan los tres patrones, y construir funcionalidades de portal que nadie usa es una forma habitual de gastar de más.
Un sitio a nivel de folleto solo necesita páginas de programas, y estas pueden mantenerse a mano si la lista de programas es corta y estable. Un sitio a nivel de catálogo necesita la importación programada; ahí es donde reside la mayor parte del valor para la mayoría de las instituciones, porque elimina la reescritura en cientos de páginas. Un sitio a nivel de portal añade consultas autenticadas y solo vale la pena cuando la institución quiere una única puerta de entrada que combine los datos del SIS con todo lo demás que publica el campus. La diferencia de coste entre los niveles es considerable, y nuestro análisis del coste total de propiedad de sistemas de código abierto frente a licenciados explica cómo sopesar el esfuerzo de implementación frente al ahorro en licencias.
También ayuda dejar claro qué no es la integración con el SIS. No es la integración con el sistema de gestión del aprendizaje (LMS). El SIS registra que un estudiante está matriculado en una sección; el LMS es quien imparte esa sección. Las dos integraciones mueven datos distintos, normalmente a través de APIs distintas, y lo mejor es delimitarlas como piezas de trabajo separadas, incluso cuando coincidan en el mismo período.
Planificar tu primera integración
El trabajo técnico de una integración con el SIS es menor de lo que parece. La parte más importante es el acuerdo: qué campos puede leer el sitio web, qué sistema es dueño de cada uno, con qué frecuencia se actualiza cada tipo y qué ocurre en el cambio de período. Las universidades que resuelven primero estas cuestiones con la oficina de registro tienden a construir la integración una sola vez. Las universidades que parten de la documentación de la API tienden a construirla dos veces.
Las plataformas Drupal que el equipo de Drupal4edu en Drupart ha construido para instituciones como la Universidad Sabancı, la METU y la Universidad Técnica Yıldız están diseñadas precisamente en torno a este tipo de capa de integración, donde el sitio web lee de los sistemas de registro de la institución en lugar de duplicarlos. Puedes leer más sobre nuestro enfoque en la página Drupal para educación.
Preguntas frecuentes sobre la integración de Drupal con el SIS
¿Puede Drupal integrarse con Ellucian Banner?
Sí. La vía actual es Ellucian Ethos, una capa REST y JSON que presenta los datos de Banner y Colleague en un modelo común con identificadores GUID. Drupal lee los recursos de Ethos ya sea de forma programada, usando la API Migrate para importar cursos y programas como contenido, o en vivo, usando el módulo External Entities para mostrar los registros remotos sin almacenarlos. El acceso se delimita por recurso y por campo en el lado de Ellucian, de modo que la oficina de registro controla exactamente qué datos puede ver el sitio web. Las instalaciones de Banner más antiguas que no usan Ethos todavía pueden integrarse mediante APIs directas o vistas de base de datos, pero cada una de esas integraciones es específica de ese campus.
¿Drupal almacena datos de estudiantes cuando se integra con un SIS?
Solo si la integración se diseña así, y en el caso de los datos personales no debería hacerlo. Los datos institucionales, como catálogos de cursos y horarios de clases, normalmente se importan a Drupal para que se puedan buscar, cachear y enriquecer con contenido de marketing. Los registros específicos del estudiante, como su horario individual o sus retenciones, deberían obtenerse bajo demanda para el estudiante autenticado, mostrarse y descartarse. Ningún registro de estudiante necesita residir en una tabla de Drupal ni en una caché de página compartida, y mantenerlo fuera de ambos es la forma más sencilla de cumplir con FERPA y con el RGPD al mismo tiempo.
¿Con qué frecuencia deben sincronizarse los datos de cursos entre el SIS y el sitio web?
Depende del tipo de dato. Los datos de catálogo de cursos y de programas cambian unas pocas veces al año, y una importación nocturna es más que suficiente; algunas instituciones la ejecutan semanalmente. Los datos del horario de clases cambian a diario durante la matrícula, por lo que se necesita bien una importación más frecuente, bien una lectura en vivo con una caché corta. El número de plazas y el estado de las secciones deben leerse en vivo durante las ventanas de matrícula. Prometer sincronización en tiempo real para todo es un error: cuesta rendimiento y fiabilidad, y no aporta nada para datos que solo cambian con el calendario académico.
¿Cuál es la diferencia entre la integración del SIS y la del LMS?
Mueven datos distintos. El sistema de información estudiantil es el sistema de registro oficial para matrículas, cursos e historial académico. El sistema de gestión del aprendizaje (LMS), como Moodle o Canvas, es donde ocurre la enseñanza: materiales, tareas y calificaciones en curso. Una integración con el SIS lleva al sitio web los datos de catálogo, horario y matrícula. Una integración con el LMS suele referirse al inicio de sesión único y a enlazar a los estudiantes desde el sitio web hacia su espacio de curso. Describimos el lado del LMS en integración de Moodle y Drupal. Lo mejor es delimitar ambos proyectos por separado, aunque compartan fecha de lanzamiento.
¿Una integración de Drupal con el SIS cumple con FERPA?
El cumplimiento es una propiedad de todo el diseño, no de ningún software en particular. Una integración de Drupal puede construirse para cumplir con las obligaciones de FERPA manteniendo los registros educativos tras autenticación, obteniéndolos bajo demanda en lugar de almacenarlos, solicitando solo los campos que usa cada página y registrando qué cuenta del sistema accedió a qué. La información de directorio, como los listados de cursos y los nombres de los docentes, puede aparecer públicamente salvo que la política de la institución o la oposición de un estudiante indiquen lo contrario. La oficina de registro, no el equipo web, decide qué campos entran en cada categoría, y esa decisión debe documentarse antes de construir la integración.