Интеграция со студенческой информационной системой позволяет сайту университета показывать каталоги курсов, расписания занятий и требования к программам без необходимости повторного ввода этих данных вручную. Данные хранятся в Banner, PeopleSoft, Workday или собственной внутренней системе; Drupal считывает их, преобразует и публикует. В этой статье мы рассмотрим три модели, по которым может строиться такая интеграция, способы предоставления данных каждой из основных платформ, какая система должна владеть какими данными, и точки отказа, которые стоит предусмотреть заранее, до первой смены семестра.
Большинство описаний этой темы ограничиваются одной фразой: Drupal интегрируется со студенческими информационными системами. Это верно, но не особо полезно. Вопросы, с которыми реально сталкивается веб-команда, звучат иначе. Копируются ли данные о курсах в Drupal или считываются в реальном времени? Что происходит, когда деканат отменяет секцию в середине семестра? Где хранится маркетинговый текст программы, если официальное описание находится в SIS? Какая из двух систем права, если они расходятся во мнениях? Ниже мы разбираем эти вопросы на примере платформ, которые используют большинство университетов.
Что интеграция со студенческой информационной системой реально делает на сайте университета
Студенческая информационная система — это основной источник достоверных академических данных для учебного заведения. В ней хранятся каталог курсов, расписание занятий, требования к программам и степеням, данные о зачислении, оценки, академические справки и академический календарь. Ничто на публичном сайте не должно противоречить этим данным.
Сайт, в свою очередь, — это место, где большинство этих данных реально просматривается. Абитуриенты читают страницы программ. Действующие студенты проверяют, когда проходит та или иная секция. Кураторы уточняют предварительные требования. Когда сайт и SIS расходятся, ошибка на стороне сайта, и замечают это как раз те люди, которых университет меньше всего хочет разочаровать.
Интеграция устраняет необходимость повторного ввода данных между двумя системами. На практике она охватывает довольно короткий список типов данных, и их стоит назвать по отдельности, поскольку каждый ведёт себя по-своему:
- Каталог курсов: коды курсов, названия, количество кредитов, описания и предварительные требования. Меняется несколько раз в год, привязан к году каталога.
- Расписание занятий: секции, время проведения, аудитории, преподаватели и количество свободных мест. Меняется ежедневно в период записи на курсы.
- Программы и требования: степени, специализации и правила, связывающие их с курсами. Меняется редко, но с формальным утверждением.
- Академический календарь и семестры: коды семестров, сроки добавления и отмены курсов, праздничные дни. Небольшой, стабильный набор данных, на который ссылается всё остальное.
- Данные конкретного студента: расписание конкретного студента, блокировки на его учётной записи, прогресс по степени. Персональные данные, отображаемые этому студенту только после аутентификации.
Первые четыре типа — это институциональные данные, которые могут появляться на публичных страницах. Последний тип — персональные данные, для которых действуют другие правила; мы вернёмся к ним ниже.
Три модели интеграции и когда какая подходит
Почти любая интеграция SIS на сайте Drupal строится по одной из трёх моделей, и выбор неверной из них — самая частая причина проблем в дальнейшем. Определяющие факторы — как часто меняются данные, сколько людей их читает и относятся ли они к конкретному человеку.
Плановый импорт для страниц каталога и программ
SIS экспортирует данные о курсах и программах по расписанию, как правило, каждую ночь, а Drupal импортирует их в виде обычного контента: тип материала для курса, тип материала для программы, термины таксономии для дисциплин и семестров. За это отвечает Migrate API из ядра Drupal, а модули сообщества Migrate Plus и Migrate Tools добавляют источники JSON, XML и CSV, а также инструменты для запуска и отката импорта. Модуль Feeds — менее требовательная к программированию альтернатива для более простых источников данных.
После импорта данные ведут себя как любой другой контент Drupal. Их можно искать, кешировать, переводить и ссылаться на них с других страниц. Редакторы могут добавлять поля, которых нет в SIS — например, маркетинговое резюме, заглавное изображение или отзывы — не затрагивая официальную запись. University of Dundee именно так построил страницы курсов, оформив их как собственные сущности, проиндексировал с помощью Search API вместе с данными о людях и факультетах и выпустил раздел бакалаврских курсов как первую версию в июле 2019 года.
Эта модель подходит для данных, которые меняются по известному циклу и которые читает много людей. Она не подходит для всего, что меняется каждый час, поскольку ночной импорт всегда будет отставать.
Чтение в реальном времени для доступности и расписаний
Здесь ничего не копируется. Drupal обращается к API SIS в момент запроса страницы и выводит результат. Модуль External Entities создан именно для этого: он определяет тип сущности, хранилищем которой служит удалённая конечная точка REST, а не база данных Drupal, благодаря чему удалённые данные всё равно можно использовать с Views, режимами отображения и форматировщиками полей. Views Remote Data предлагает более лёгкий путь, когда нужен только список.
Чтение в реальном времени — правильное решение для количества свободных мест, статуса секции и всего прочего, где устаревшее значение вводит в заблуждение. Это влечёт два вида затрат. Без тщательного кеширования каждый просмотр страницы превращается в вызов API, и доступность сайта начинает зависеть от доступности API SIS. Короткий кеш с заданным временем жизни и корректное запасное сообщение при недоступности API — не опциональные дополнения. Без них первый день записи на курсы «уложит» сайт вместе с SIS.
Авторизованные запросы для данных конкретного студента
Третья модель охватывает студенческий портал: мое расписание, мои блокировки, мой прогресс по степени. Данные запрашиваются по требованию для вошедшего в систему пользователя, показываются один раз и вообще не сохраняются в Drupal. Личность определяется через единую систему входа кампуса; идентификатор студента из этой сессии — то, на чём строится запрос к SIS.
Эта модель зависит от того, что вопрос идентификации решён заранее, поскольку неверный идентификатор вернёт запись другого студента. Варианты решения этой задачи мы рассмотрели в статье Интеграция SSO с SAML, Shibboleth, LDAP и CAS. Когда это решено, сам вызов SIS обычно представляет собой единичный запрос к конечной точке персоны или студента, выполняемый на стороне сервера с учётными данными API учреждения — никогда не раскрываемыми в браузере.
Некоторые университеты решают, что этот уровень лучше реализовать в собственном продукте самообслуживания от поставщика SIS, а не на сайте Drupal, и вместо этого просто дают на него ссылку. Это законный выбор, зачастую более дешёвый. Drupal заслуживает своего места в портале, когда учреждение хочет объединить данные SIS с контентом, новостями, событиями и сервисами, о которых SIS ничего не знает.
Подключение Drupal к основным платформам
Каждый поставщик предоставляет свои данные по-разному, и эти различия определяют, какая модель практически применима.
Ellucian Banner и Colleague через Ethos
Рекомендуемый Ellucian способ интеграции со сторонними системами — Ethos, единый слой REST и JSON, расположенный поверх Banner и Colleague. Ethos представляет общую модель данных, так что курс, секция или персона имеют одинаковую структуру независимо от того, какой продукт находится в основе, и каждая запись несёт GUID вместо идентификатора, специфичного для конкретного продукта. Ethos размещается регионально, с отдельными конечными точками для США, Канады, Европы и Азиатско-Тихоокеанского региона, что важно для учреждений с требованиями к месту хранения данных.
Для Drupal это означает, что один набор определений ресурсов работает как для кампусов на Banner, так и на Colleague, а модуль External Entities может сопоставлять JSON из Ethos с полями с помощью своего маппера JSONPath. Доступ предоставляется на стороне Ellucian по ресурсам и по полям, поэтому первой задачей проекта обычно становится согласование с деканатом того, какие ресурсы нужны сайту, а не написание кода. Более старые кампусы на Banner без Ethos по-прежнему предоставляют прямые API и представления базы данных; они работают, но каждая такая интеграция становится специфичной для конкретного кампуса.
PeopleSoft Campus Solutions
Campus Solutions от Oracle предоставляет данные через Integration Broker, свой слой обмена сообщениями и веб-сервисов, используя REST или SOAP. Данные каталога курсов и расписания поступают из модуля Student Records, а концепция, которая ставит в тупик большинство разработчиков интеграций, — это действие с определённой даты (effective dating): у курса нет одного описания, у него есть история описаний, каждое из которых действует с определённой даты, и запрос должен спрашивать именно то, которое соответствует отображаемому году каталога.
Именно поэтому плановый импорт хорошо подходит для данных каталога PeopleSoft. Импорт может один раз, ночью, разрешить строки с датами действия и сохранить актуальную версию. Выполнять это разрешение при каждом живом запросе было бы расточительно. Чтение в реальном времени остаётся правильной моделью для доступности секций, где значение представляет собой единственное актуальное число.
Workday Student
Workday предоставляет веб-сервисы REST и SOAP, а для выгрузок в формате отчётов — пользовательские отчёты, которые можно публиковать как информационные каналы данных. На практике многие интеграции Workday Student строятся именно на этих потоках отчётов: деканат определяет отчёт, содержащий ровно те поля курсов и секций, которые может видеть сайт, а Drupal получает его по расписанию. Такой подход делает контракт данных явным и передаёт контроль над тем, что покидает SIS, в руки тех, кому эти данные принадлежат.
Модель семестров и академических периодов в Workday отличается от моделей Banner и PeopleSoft, поэтому сопоставление полей заслуживает отдельной сессии по проектированию, а не переноса решений из предыдущего проекта.
Собственные и региональные системы
Многие университеты используют собственную систему, национальную платформу или продукт регионального поставщика. Модель при этом не меняется; меняется только способ передачи данных. Если у системы есть API, его может использовать модуль External Entities или собственный плагин источника для Migrate. Если система может только генерировать файлы, плановая выгрузка CSV или XML на SFTP-хранилище с последующим импортом через Migrate — вполне достойная интеграция, часто более надёжная, чем хрупкое API. Главное — договориться о контракте данных и расписании, а затем поддерживать оба стабильными.
Какая система владеет данными
Самое важное решение в проекте — не техническое. Это заявление о том, кто владеет какими полями.
SIS владеет всем академическим и официальным: кодами курсов, названиями, кредитами, предварительными требованиями, требованиями программы, временем проведения, датами семестров. Drupal никогда не редактирует эти данные, а только отображает их. Если описание курса на сайте неверно, исправление вносится в SIS и попадает на сайт при следующем импорте.
Drupal владеет всем тем, для чего SIS никогда не был предназначен: маркетинговым описанием программы, цитатами преподавателей, карьерными результатами, изображениями, призывами к действию, переводами и метаданными для поисковых систем. Эти поля находятся на стороне Drupal, привязаны к импортированной записи, но хранятся отдельно от неё, поэтому импорт никогда не перезаписывает работу редактора.
Фиксация этого разделения в виде таблицы «поле за полем», согласованной деканатом и веб-командой ещё до начала разработки, предотвращает два самых частых спора в дальнейшем: редактор, изменивший значение кредитов на сайте и увидевший его перезаписанным за ночь, и деканат, не понимающий, почему отменённый им курс по-прежнему отображается на вручную созданной посадочной странице.
Обратная запись из Drupal в SIS, при которой веб-форма создаёт или изменяет запись в SIS, возможна через Ethos и Integration Broker, но относится к другой категории риска. Большинство учреждений направляют действия по подаче заявок и зачислению через собственные продукты поставщика SIS или CRM для приёмной комиссии, а сайт по отношению к SIS оставляют только для чтения. Это разумное решение по умолчанию.
Конфиденциальность данных студентов на уровне интеграции: FERPA и GDPR
В тот момент, когда интеграция затрагивает данные конкретного студента, она начинает работать с регулируемыми данными. В США закон FERPA различает образовательные записи, для раскрытия которых требуется согласие, и справочную информацию, такую как имя и программа, которую учреждение может публиковать, если студент не отказался от этого. В Европейском союзе и Великобритании GDPR распространяется на любые персональные данные, а принципы ограничения цели и минимизации данных определяют, сколько таких данных сайт может получать.
Три правила удерживают интеграцию на Drupal в правовом поле обоих режимов:
- Институциональные данные — на публичных страницах, персональные данные — только за аутентификацией. Каталоги и расписания являются институциональными. Собственное расписание студента — персональные данные.
- Получать персональные данные по требованию и не сохранять их. Именно поэтому существует модель авторизованного запроса. Ни одна запись студента не должна находиться в таблице Drupal или в кеше страницы, до которого мог бы добраться другой пользователь.
- Запрашивать только те поля, которые использует страница. И Ethos, и потоки отчётов Workday позволяют учреждению ограничивать доступ по каждому полю. Узкое ограничение доступа — самый дешёвый из доступных инструментов соблюдения требований.
Ведение журнала о том, какая системная учётная запись что и когда получила, замыкает цепочку для аудита. Более широкий круг обязательств мы рассмотрели в статье достижение соответствия GDPR с помощью Drupal; уровень интеграции — это место, где многие из этих обязательств становятся конкретными.
Что ломается на практике и как к этому подготовиться
Интеграции редко дают сбой в день запуска. Они дают сбой при первом событии, которое не было предусмотрено проектом. Вот те, что повторяются чаще всего.
- Смена семестра. SIS открывает новый семестр, пока сайт всё ещё показывает старый как текущий. Явно моделируйте семестры в Drupal и определяйте понятие «текущий семестр» на основе календаря SIS, а не жёстко заданной даты.
- Отменённые и объединённые курсы. Курс исчезает из выгрузки, но его страница в Drupal, с входящими ссылками и позицией в поиске, по-прежнему активна. Заранее решите, будет ли импорт снимать её с публикации, архивировать с пометкой или перенаправлять на курс-преемник.
- Изменения с датой вступления в силу. Описание, действующее с следующего года каталога, появляется на странице текущего года, поскольку запрос не фильтровал по дате. Это классическая проблема PeopleSoft, но сам принцип встречается повсюду.
- Инвалидация кеша. Данные, читаемые в реальном времени, кешируются ради производительности, а затем количество свободных мест целый час остаётся нулевым после того, как места освободились. Задавайте время жизни кеша отдельно для каждого типа данных и сокращайте его в периоды записи на курсы.
- Ограничения и сбои API. Блок на главной странице, обращающийся к SIS при каждом запросе, исчерпает лимит запросов уже в первое загруженное утро. Кешируйте агрессивно, деградируйте плавно и никогда не допускайте, чтобы сбой SIS приводил к пустой странице.
- Несовпадение идентификаторов. Идентификация SSO использует один идентификатор, а SIS — другой. Согласуйте сопоставление до построения портала и протестируйте его на реальных учётных записях, включая пограничные случаи, например сотрудников, которые одновременно являются студентами.
Ничего из этого не является чем-то экзотическим. Однострочный план действий на одну страницу, охватывающий эти случаи и написанный до запуска, стоит больше, чем большая часть кода.
Насколько глубокой должна быть интеграция?
Не каждому университету нужны все три модели, и создание функциональности портала, которой никто не пользуется, — распространённый способ перерасходовать бюджет.
Сайт уровня буклета нуждается только в страницах программ, и их можно поддерживать вручную, если список программ короткий и стабильный. Сайту уровня каталога нужен плановый импорт; именно там сосредоточена основная ценность для большинства учреждений, поскольку он устраняет повторный ввод данных на сотнях страниц. Сайт уровня портала добавляет авторизованные запросы и оправдан только тогда, когда учреждению нужна единая точка входа, объединяющая данные SIS со всем остальным, что публикует кампус. Разница в стоимости между этими уровнями существенна, и наш анализ совокупной стоимости владения для открытых и лицензионных систем показывает, как соотнести затраты на внедрение с экономией на лицензиях.
Также полезно чётко понимать, чем интеграция SIS не является. Это не интеграция с системой управления обучением (LMS). SIS фиксирует, что студент зачислен на секцию; LMS обеспечивает проведение этой секции. Обе интеграции перемещают разные данные, обычно через разные API, и их лучше рассматривать как отдельные проекты, даже если сроки их запуска совпадают.
Планирование вашей первой интеграции
Техническая часть работы над интеграцией SIS меньше, чем кажется. Основная часть — это договорённости: какие поля может читать сайт, какая система владеет каждым из них, как часто обновляется каждый тип данных и что происходит при смене семестра. Университеты, которые сначала согласуют эти вопросы с деканатом, как правило, строят интеграцию только один раз. Университеты, начинающие с документации по API, как правило, строят её дважды.
Платформы на Drupal, которые команда Drupal4edu в компании Drupart построила для таких учреждений, как Sabancı University, METU и Yıldız Technical University, спроектированы именно вокруг такого уровня интеграции, где сайт считывает данные из основных источников учреждения, а не дублирует их. Подробнее о нашем подходе можно прочитать на странице Drupal для образования.
Часто задаваемые вопросы об интеграции Drupal с SIS
Может ли Drupal интегрироваться с Ellucian Banner?
Да. Актуальный способ — Ellucian Ethos, слой REST и JSON, представляющий данные Banner и Colleague в единой модели с идентификаторами GUID. Drupal считывает ресурсы Ethos либо по расписанию, используя Migrate API для импорта курсов и программ в виде контента, либо в реальном времени, используя модуль External Entities для отображения удалённых записей без их сохранения. Доступ на стороне Ellucian ограничивается по ресурсам и по полям, поэтому деканат точно контролирует, какие данные может видеть сайт. Более старые установки Banner без Ethos по-прежнему можно интегрировать через прямые API или представления базы данных, но каждая такая интеграция специфична для конкретного кампуса.
Сохраняет ли Drupal данные студентов при интеграции с SIS?
Только если интеграция спроектирована именно так, а для персональных данных этого быть не должно. Институциональные данные, такие как каталоги курсов и расписания занятий, обычно импортируются в Drupal, чтобы их можно было искать, кешировать и дополнять маркетинговым контентом. Данные конкретного студента, такие как его индивидуальное расписание или блокировки, должны запрашиваться по требованию для аутентифицированного студента, отображаться и затем удаляться. Ни одна запись студента не обязана храниться в таблице Drupal или в общем кеше страниц, и удержание её за пределами обоих этих мест — самый простой способ одновременно удовлетворить требованиям FERPA и GDPR.
Как часто должны синхронизироваться данные о курсах между SIS и сайтом?
Это зависит от типа данных. Данные каталога курсов и программ меняются несколько раз в год, и ночного импорта более чем достаточно; некоторые учреждения запускают его еженедельно. Данные расписания занятий меняются ежедневно в период записи, поэтому нужен либо более частый импорт, либо чтение в реальном времени с коротким кешем. Количество свободных мест и статус секций следует читать в реальном времени в периоды записи. Обещать синхронизацию в реальном времени для всего — ошибка: это снижает производительность и надёжность и не даёт ничего для данных, которые меняются только вместе с академическим календарём.
В чём разница между интеграцией SIS и интеграцией LMS?
Они перемещают разные данные. Студенческая информационная система — это основной источник данных для зачисления, курсов и академической истории. Система управления обучением (LMS), такая как Moodle или Canvas, — это место, где непосредственно проходит обучение: материалы, задания и текущие оценки. Интеграция SIS передаёт на сайт данные каталога, расписания и зачисления. Интеграция LMS обычно касается единого входа и связывания студентов с сайта с их учебным пространством. Сторону LMS мы описываем в статье интеграция Moodle и Drupal. Оба проекта лучше рассматривать раздельно, даже если у них общая дата запуска.
Соответствует ли интеграция Drupal с SIS требованиям FERPA?
Соответствие требованиям — это свойство всего проекта в целом, а не какого-либо отдельного программного обеспечения. Интеграцию на Drupal можно построить так, чтобы она соответствовала требованиям FERPA: держать образовательные записи за аутентификацией, получать их по требованию, а не хранить, запрашивать только те поля, которые использует страница, и фиксировать в журнале, какая системная учётная запись к чему обращалась. Справочная информация, такая как списки курсов и имена преподавателей, может отображаться публично, если политика учреждения или отказ студента не предписывают иное. Именно деканат, а не веб-команда, решает, какие поля относятся к какой категории, и это решение должно быть задокументировано до построения интеграции.