Integrace studijního informačního systému umožňuje univerzitnímu webu zobrazovat katalogy kurzů, rozvrhy hodin a požadavky studijních programů, aniž by je někdo musel znovu ručně přepisovat. Data žijí v systému Banner, PeopleSoft, Workday nebo ve vlastním interním systému; Drupal je čte, upravuje jejich podobu a publikuje je. V tomto článku představujeme tři vzory, které může taková integrace sledovat, způsob, jakým každá z hlavních platforem zpřístupňuje svá data, který systém by měl vlastnit co, a body selhání, na které je třeba myslet ještě před prvním přechodem semestru.
Většina popisů tohoto tématu se zastaví u jedné jediné věty: Drupal se integruje se studijními informačními systémy. To je pravda, ale příliš to nepomůže. Otázky, kterým webový tým skutečně čelí, jsou jiné. Kopírují se data o kurzech do Drupalu, nebo se čtou přímo v reálném čase? Co se stane, když studijní oddělení zruší předmět uprostřed semestru? Kde žije marketingový text pro studijní program, pokud oficiální popis je uložen v SIS? Který ze dvou systémů má pravdu, když si odporují? Níže si tyto otázky projdeme na platformách, které provozuje většina univerzit.
Co integrace studijního informačního systému skutečně dělá na univerzitním webu
Studijní informační systém je pro instituci hlavním zdrojem pravdy pro akademická data. Obsahuje katalog kurzů, rozvrh hodin, požadavky studijních programů a titulů, zápisy, známky, výpisy studijních výsledků a akademický kalendář. Nic na veřejném webu by mu nemělo odporovat.
Web je naopak místem, kde je většina těchto dat skutečně vidět. Uchazeči o studium čtou stránky studijních programů. Současní studenti kontrolují, kdy se koná daná výuková skupina. Studijní poradci vyhledávají předpoklady pro zápis. Když se web a SIS rozejdou, chybu má web – a lidé, kteří si toho všimnou, jsou přesně ti, koho si univerzita nejméně přeje zklamat.
Integrace odstraňuje nutnost přepisovat data mezi oběma systémy. V praxi pokrývá poměrně krátký seznam typů dat a vyplatí se je pojmenovat, protože každý se chová jinak:
- Katalog kurzů: kódy kurzů, názvy, hodnoty kreditů, popisy a předpoklady pro zápis. Mění se několikrát ročně, vázán na rok katalogu.
- Rozvrh hodin: výukové skupiny, časy konání, místnosti, vyučující a počty volných míst. Během zápisu se mění denně.
- Studijní programy a požadavky: tituly, zaměření a pravidla, která s nimi propojují jednotlivé kurzy. Mění se zřídka, ale vždy s formálním schválením.
- Akademický kalendář a semestry: kódy semestrů, termíny pro zápis a odhlášení předmětů, svátky. Malá a stabilní množina dat, na kterou odkazuje vše ostatní.
- Data konkrétního studenta: rozvrh konkrétního studenta, blokace na jeho účtu, postup ve studiu. Osobní údaje, zobrazované danému studentovi pouze po ověření totožnosti.
První čtyři kategorie jsou institucionální data a mohou se objevit na veřejných stránkách. Poslední kategorie jsou osobní údaje, které se řídí odlišnými pravidly, k nimž se vrátíme níže.
Tři vzory integrace a kdy se který hodí
Téměř každá integrace SIS na webu postaveném na Drupalu odpovídá jednomu ze tří vzorů, a volba nesprávného z nich je nejčastějším zdrojem pozdějších problémů. Rozhodujícími faktory jsou, jak často se data mění, kolik lidí je čte a zda patří konkrétní osobě.
Plánovaný import pro stránky katalogu a studijních programů
SIS exportuje data o kurzech a programech podle harmonogramu, typicky každou noc, a Drupal je importuje jako běžný obsah: typ obsahu pro kurz, typ obsahu pro studijní program, taxonomické termíny pro obory a semestry. Tuto úlohu zajišťuje Migrate API v jádru Drupalu, přičemž přispívané moduly Migrate Plus a Migrate Tools přidávají zdroje ve formátu JSON, XML a CSV a nástroje pro spouštění a vracení importů zpět. Nižší úroveň programování nabízí modul Feeds pro jednodušší zdroje dat.
Jakmile jsou data importována, chovají se jako jakýkoli jiný obsah v Drupalu. Lze je vyhledávat, ukládat do mezipaměti, překládat a odkazovat na ně z jiných stránek. Redaktoři mohou přidat pole, která SIS nemá, například marketingové shrnutí, úvodní obrázek nebo reference studentů, aniž by zasahovali do oficiálního záznamu. University of Dundee takto postavila své stránky s kurzy jako vlastní entity, indexovala je pomocí Search API společně s údaji o lidech a školách a v červenci 2019 vydala jako první verzi sekci bakalářských kurzů.
Tento vzor se hodí pro data, která se mění podle známého cyklu a čte je mnoho lidí. Nehodí se pro nic, co se mění po hodinách, protože noční import bude vždy zaostávat.
Čtení v reálném čase pro dostupnost a rozvrhy
Zde se nic nekopíruje. Drupal se při zobrazení stránky dotáže API systému SIS a výsledek vykreslí. Modul External Entities je postaven přesně pro tento účel: definuje typ entity, jehož úložištěm je vzdálený REST endpoint namísto databáze Drupalu, takže vzdálená data lze i tak používat s Views, zobrazovacími režimy a formátovači polí. Modul Views Remote Data nabízí odlehčenější cestu, pokud je potřeba pouze výpis.
Čtení v reálném čase je správnou odpovědí pro počty volných míst, stav výukové skupiny a cokoli dalšího, kde by zastaralá hodnota mátla. Nese s sebou dvě nákladové položky. Bez pečlivého ukládání do mezipaměti se každé zobrazení stránky stane voláním API a dostupnost webu je nyní závislá na dostupnosti API systému SIS. Krátká mezipaměť s definovanou dobou platnosti a elegantní záložní zpráva, když API není dostupné, nejsou volitelné doplňky navíc. Bez nich by první den zápisu srazil web dolů společně se SIS.
Ověřené dotazy pro data konkrétního studenta
Třetí vzor pokrývá studentský portál: můj rozvrh, mé blokace, kontrolu mého postupu ve studiu. Data se načítají na vyžádání pro přihlášenou osobu, zobrazí se jednou a v Drupalu se vůbec neukládají. Identita pochází z jednotného přihlašování kampusu; identifikátor studenta z dané relace je to, podle čeho se řídí dotaz do SIS.
Tento vzor závisí na tom, že je identita vyřešena jako první, protože nesprávný identifikátor vrátí záznam jiného studenta. Možnosti jsme popsali v článku integrace SSO se SAML, Shibboleth, LDAP a CAS. Jakmile je toto vyřešeno, samotné volání SIS bývá obvykle jediným požadavkem na endpoint osoby nebo studenta, provedeným na straně serveru s přístupovými údaji API instituce, nikdy s ničím zveřejněným v prohlížeči.
Některé univerzity se rozhodnou, že tato vrstva patří spíše do vlastního produktu pro samoobsluhu od dodavatele SIS než na web postavený na Drupalu, a místo toho na něj pouze odkazují. Je to legitimní volba a často i ta levnější. Drupal si své místo v portálu vydobude, když instituce chce spojit data ze SIS s obsahem, novinkami, akcemi a službami, o kterých SIS nic neví.
Propojení Drupalu s hlavními platformami
Každý dodavatel zpřístupňuje svá data jiným způsobem a tyto rozdíly určují, který vzor je prakticky použitelný.
Ellucian Banner a Colleague prostřednictvím Ethos
Doporučenou cestou Ellucianu pro integraci s třetími stranami je Ethos, jednotná vrstva REST a JSON, která stojí nad Bannerem i Colleague. Ethos nabízí společný datový model, takže kurz, výuková skupina nebo osoba mají stejnou strukturu bez ohledu na to, jaký produkt je za tím ukrytý, a každý záznam nese GUID namísto ID specifického pro daný produkt. Ethos je hostován regionálně, se samostatnými endpointy pro Spojené státy, Kanadu, Evropu a asijsko-pacifický region, což je důležité pro instituce s požadavky na umístění dat.
Pro Drupal to znamená, že jedna sada definic zdrojů funguje jak pro kampusy s Bannerem, tak pro kampusy s Colleague, a modul External Entities dokáže pomocí svého mapovače JSONPath přiřadit JSON z Ethosu k jednotlivým polím. Přístup je na straně Ellucianu udělován po jednotlivých zdrojích i polích, takže prvním úkolem projektu bývá spíše dohodnout se se studijním oddělením, jaké zdroje web potřebuje, než psát kód. Starší kampusy s Bannerem bez Ethosu stále nabízejí přímá API a databázové pohledy; ty fungují, ale každá taková integrace je vázaná na konkrétní kampus.
PeopleSoft Campus Solutions
Oracle Campus Solutions zpřístupňuje data prostřednictvím Integration Broker, své vrstvy pro zasílání zpráv a webové služby, pomocí REST nebo SOAP. Data katalogu kurzů a rozvrhu pocházejí z modulu Student Records a koncept, který zaskočí většinu tvůrců integrací, je časová platnost záznamů (effective dating): kurz nemá jeden popis, ale historii popisů, z nichž každý platí od určitého data, a dotaz musí požádat o ten správný pro zobrazovaný rok katalogu.
Právě proto se plánovaný import dobře hodí pro data katalogu z PeopleSoft. Import může jednou, každou noc, vyřešit řádky s časovou platností a uložit aktuální verzi. Provádět toto řešení při každém živém požadavku by bylo plýtváním zdroji. Čtení v reálném čase zůstává správným vzorem pro dostupnost výukových skupin, kde je hodnota jediným aktuálním číslem.
Workday Student
Workday zpřístupňuje webové služby REST a SOAP a pro výstupy ve stylu reportů také vlastní sestavy, které lze publikovat jako datové zdroje. V praxi je mnoho integrací Workday Student postaveno právě na těchto sestavách: studijní oddělení definuje sestavu obsahující přesně ta pole kurzů a výukových skupin, která web smí vidět, a Drupal ji podle harmonogramu zpracovává. Tento přístup udržuje datovou smlouvu jasnou a svěřuje kontrolu nad tím, co opouští SIS, do rukou těch, kdo tato data vlastní.
Model semestrů a akademických období ve Workday se liší od modelů v Banneru a PeopleSoft, takže mapování polí si zaslouží vlastní návrhové jednání, místo aby se přebíralo z předchozího projektu.
Vlastní a regionální systémy
Řada univerzit provozuje vlastní systém, národní platformu nebo produkt regionálního dodavatele. Vzor se nemění; mění se pouze způsob přenosu. Pokud má systém API, dokáže jej zpracovat modul External Entities nebo vlastní zdrojový plugin pro Migrate. Pokud dokáže produkovat pouze soubory, je plánované ukládání CSV nebo XML na umístění SFTP spolu s importem pomocí Migrate zcela důstojnou integrací a často spolehlivější než křehké API. Podstatné je dohodnout se na datové smlouvě a harmonogramu a poté oboje udržovat stabilní.
Který systém vlastní data
Nejdůležitější rozhodnutí v projektu není technické. Je to prohlášení o tom, kdo vlastní která pole.
SIS vlastní vše akademické a oficiální: kódy kurzů, názvy, kredity, předpoklady pro zápis, požadavky, časy konání, data semestrů. Drupal je nikdy needituje, pouze je zobrazuje. Pokud je popis kurzu na webu chybný, oprava se provede v SIS a promítne se při dalším importu.
Drupal vlastní vše, pro co SIS nikdy nebyl navržen: marketingové vyprávění o programu, citace vyučujících, kariérní výsledky, obrazový materiál, výzvy k akci, překlady a metadata pro vyhledávače. Tato pole žijí na straně Drupalu, jsou připojena k importovanému záznamu, ale uložena odděleně od něj, takže import nikdy nepřepíše práci redaktora.
Zapsání tohoto rozdělení do tabulky pole po poli, odsouhlasené studijním oddělením a webovým týmem ještě předtím, než se cokoli začne stavět, předchází dvěma nejčastějším pozdějším sporům: redaktorovi, který na webu změnil hodnotu kreditů a přes noc mu ji import přepsal, a studijnímu oddělení, které nechápe, proč se kurz, který zrušilo, stále objevuje na ručně vytvořené vstupní stránce.
Zpětný zápis z Drupalu do SIS, kdy webový formulář vytváří nebo mění záznam v SIS, je možný prostřednictvím Ethosu a Integration Broker, ale patří do jiné kategorie rizika. Většina institucí směruje přihlášky a zápisy přes vlastní produkty dodavatele SIS nebo CRM systém pro přijímací řízení a udržuje web vůči SIS pouze pro čtení. To je rozumné výchozí nastavení.
Soukromí studentů ve vrstvě integrace: FERPA a GDPR
Ve chvíli, kdy se integrace dotkne dat konkrétního studenta, pracuje s regulovanými údaji. Ve Spojených státech zákon FERPA rozlišuje mezi vzdělávacími záznamy, jejichž zveřejnění vyžaduje souhlas, a adresářovými informacemi, jako jsou jméno a studijní program, které instituce smí zveřejnit, pokud si to student nezakázal. V Evropské unii a ve Spojeném království se na jakékoli osobní údaje vztahuje GDPR a zásady účelového omezení a minimalizace údajů určují, kolik z nich smí web získávat.
Tři pravidla udržují integraci v Drupalu na správné straně obou právních režimů:
- Institucionální data na veřejných stránkách, osobní údaje pouze za ověřením totožnosti. Katalogy a rozvrhy jsou institucionální. Vlastní rozvrh studenta je osobní údaj.
- Osobní údaje načítat na vyžádání a neukládat je. Vzor ověřeného vyhledávání existuje právě z tohoto důvodu. Žádný záznam studenta by neměl ležet v tabulce Drupalu ani v mezipaměti stránky, na kterou by mohl narazit jiný uživatel.
- Požadovat pouze pole, která stránka skutečně používá. Ethos i sestavy Workday umožňují instituci omezit přístup po jednotlivých polích. Úzké vymezení rozsahu je nejlevnější dostupnou kontrolou souladu s předpisy.
Zaznamenávání toho, který systémový účet co a kdy načetl, uzavírá kruh pro účely auditu. Širší povinnosti jsme popsali v článku dosažení souladu s GDPR pomocí Drupalu; vrstva integrace je místem, kde se řada z nich stává konkrétní.
Co v praxi selhává a jak se na to připravit
Integrace zřídkakdy selžou v den spuštění. Selžou při první události, kterou návrh nepředvídal. Toto jsou ty, které se opakují.
- Přechod semestru. SIS otevře nový semestr, zatímco web stále zobrazuje jako aktuální ten starý. Modelujte semestry v Drupalu explicitně a odvozujte pojem „aktuální semestr“ z kalendáře SIS, ne z pevně zapsaného data.
- Zrušené a sloučené kurzy. Kurz zmizí z exportu, ale jeho stránka v Drupalu, s příchozími odkazy a pozicí ve vyhledávání, je stále živá. Předem se rozhodněte, zda import stránku zruší publikaci, zařadí ji do archivu s upozorněním, nebo přesměruje na nástupce.
- Změny s časovou platností. Popis platný od příštího roku katalogu se objeví na stránce letošního roku, protože dotaz nefiltroval podle data. Toto je klasický problém PeopleSoft, ale koncept existuje všude.
- Neplatnost mezipaměti. Data čtená v reálném čase jsou z výkonnostních důvodů uložena do mezipaměti, a pak počet volných míst zůstává hodinu na nule i poté, co se místa uvolnila. Nastavte dobu platnosti podle typu dat a zkraťte ji během období zápisu.
- Limity a výpadky API. Blok na hlavní stránce, který volá SIS při každém požadavku, vyčerpá limit počtu volání hned první rušné ráno. Ukládejte agresivně do mezipaměti, degradujte elegantně a nikdy nenechte výpadek SIS vyústit v prázdnou stránku.
- Neshoda identifikátorů. Identita v SSO používá jeden identifikátor a SIS jiný. Dohodněte mapování ještě před stavbou portálu a otestujte je se skutečnými účty včetně okrajových případů, jako jsou zaměstnanci, kteří jsou zároveň studenty.
Nic z toho není exotické. Jednostránková provozní příručka, která tyto případy pokrývá a je napsaná před spuštěním, má větší hodnotu než většina kódu.
Jak hluboko by měla integrace jít?
Ne každá univerzita potřebuje všechny tři vzory a stavba funkcí portálu, které nikdo nepoužívá, je běžným způsobem, jak zbytečně utratit peníze navíc.
Web na úrovni brožury potřebuje pouze stránky studijních programů a ty lze udržovat ručně, pokud je seznam programů krátký a stabilní. Web na úrovni katalogu potřebuje plánovaný import; právě tam se pro většinu institucí nachází nejvíce přidané hodnoty, protože odstraňuje přepisování napříč stovkami stránek. Web na úrovni portálu přidává ověřené vyhledávání a vyplatí se pouze tehdy, když instituce chce jednotný vstupní bod kombinující data ze SIS se vším ostatním, co kampus publikuje. Rozdíl v nákladech mezi jednotlivými úrovněmi je značný a naše analýza celkových nákladů vlastnictví open-source versus licencovaných systémů vysvětluje, jak zvážit implementační úsilí proti úsporám na licencích.
Pomáhá také ujasnit si, čím integrace SIS není. Není to integrace systému pro řízení výuky (LMS). SIS zaznamenává, že je student zapsán do výukové skupiny; LMS tuto výukovou skupinu dodává. Obě integrace přenášejí odlišná data, obvykle přes odlišná API, a je vhodné je vymezit jako samostatné části práce, i když skončí ve stejném semestru.
Plánování první integrace
Technická práce na integraci SIS je menší, než se zdá. Větší část tvoří dohoda: která pole web smí číst, kdo z nich každé vlastní, jak často se každý typ dat obnovuje a co se stane při přechodu semestru. Univerzity, které si tyto otázky vyjasní se studijním oddělením nejprve, mají tendenci stavět integraci jen jednou. Univerzity, které začnou od dokumentace API, ji mívají tendenci stavět dvakrát.
Platformy postavené na Drupalu, které tým Drupal4edu ve společnosti Drupart vybudoval pro instituce jako Sabancı University, METU a Yıldız Technical University, jsou navrženy přesně kolem tohoto typu integrační vrstvy, kde web čte z hlavních zdrojů pravdy dané instituce namísto jejich duplikování. Více o našem přístupu si můžete přečíst na stránce Drupal pro vzdělávání.
Často kladené otázky o integraci Drupalu se SIS
Může se Drupal integrovat s Ellucian Banner?
Ano. Aktuální cestou je Ellucian Ethos, vrstva REST a JSON, která prezentuje data z Banneru a Colleague ve společném modelu s identifikátory GUID. Drupal čte zdroje Ethosu buď podle harmonogramu, pomocí Migrate API pro import kurzů a programů jako obsahu, nebo v reálném čase, pomocí modulu External Entities, který vzdálené záznamy vykresluje bez jejich ukládání. Přístup je na straně Ellucianu omezen po jednotlivých zdrojích a polích, takže studijní oddělení přesně řídí, jaká data web může vidět. Starší instalace Banneru bez Ethosu lze stále integrovat prostřednictvím přímých API nebo databázových pohledů, ale každá taková integrace je specifická pro daný kampus.
Ukládá Drupal data studentů, když se integruje se SIS?
Pouze pokud je integrace takto navržena, a u osobních údajů by tomu tak být nemělo. Institucionální data, jako jsou katalogy kurzů a rozvrhy hodin, se běžně importují do Drupalu, aby je bylo možné vyhledávat, ukládat do mezipaměti a obohacovat o marketingový obsah. Data konkrétního studenta, jako jeho individuální rozvrh nebo blokace, by měla být pro ověřeného studenta načítána na vyžádání, zobrazena a poté zahozena. Žádný záznam studenta nemusí ležet v tabulce Drupalu ani ve sdílené mezipaměti stránek, a udržet jej mimo oboje je nejjednodušší způsob, jak zároveň splnit požadavky FERPA i GDPR.
Jak často by se měla data o kurzech synchronizovat mezi SIS a webem?
Záleží na typu dat. Data katalogu kurzů a studijních programů se mění jen několikrát ročně a noční import je více než dostačující; některé instituce jej spouštějí týdně. Data rozvrhu hodin se během zápisu mění denně, takže je potřeba buď častější import, nebo čtení v reálném čase s krátkou mezipamětí. Počty volných míst a stav výukových skupin by se měly během období zápisu číst přímo v reálném čase. Slibovat synchronizaci v reálném čase pro úplně vše je chyba: stojí to výkon a spolehlivost a nepřináší to nic pro data, která se mění pouze podle akademického kalendáře.
Jaký je rozdíl mezi integrací SIS a integrací LMS?
Přenášejí odlišná data. Studijní informační systém je hlavním zdrojem pravdy pro zápisy, kurzy a akademickou historii. Systém pro řízení výuky (LMS), jako je Moodle nebo Canvas, je místem, kde probíhá samotná výuka: studijní materiály, zadání a průběžně vznikající známky. Integrace SIS přináší na web data katalogu, rozvrhu a zápisů. Integrace LMS se obvykle týká jednotného přihlašování a propojení studentů z webu do jejich prostoru pro daný kurz. Stránku LMS popisujeme v článku integrace Moodle a Drupalu. Oba projekty je nejlepší vymezit odděleně, i když sdílejí datum spuštění.
Je integrace Drupalu se SIS v souladu s FERPA?
Soulad s předpisy je vlastností celého návrhu, ne nějakého konkrétního softwaru. Integraci v Drupalu lze postavit tak, aby splňovala povinnosti FERPA tím, že vzdělávací záznamy zůstávají za ověřením totožnosti, načítají se na vyžádání místo ukládání, požadují se pouze pole, která stránka skutečně využívá, a zaznamenává se, který systémový účet k čemu přistupoval. Adresářové informace, jako jsou seznamy kurzů a jména vyučujících, se mohou zobrazovat veřejně, pokud politika instituce nebo nesouhlas studenta nestanoví jinak. O tom, která pole spadají do jaké kategorie, rozhoduje studijní oddělení, nikoli webový tým, a toto rozhodnutí by mělo být zdokumentováno ještě před vytvořením integrace.