Eine Integration des Student Information Systems ermöglicht es einer Universitätswebsite, Vorlesungsverzeichnisse, Stundenpläne und Studiengangsanforderungen anzuzeigen, ohne dass jemand sie erneut eintippen muss. Die Daten liegen in Banner, PeopleSoft, Workday oder einem hausinternen System; Drupal liest sie, bringt sie in Form und veröffentlicht sie. In diesem Artikel stellen wir die drei Muster vor, denen eine solche Integration folgen kann, wie jede der großen Plattformen ihre Daten bereitstellt, welches System wofür zuständig sein sollte, und die Fehlerquellen, die man vor dem ersten Semesterwechsel einplanen sollte.

Die meisten Beschreibungen dieses Themas beschränken sich auf einen einzigen Satz: Drupal integriert sich mit Student-Information-Systemen. Das stimmt, ist aber wenig hilfreich. Die Fragen, mit denen ein Web-Team tatsächlich konfrontiert ist, sind anders. Werden Kursdaten in Drupal kopiert oder live gelesen? Was passiert, wenn das Prüfungsamt eine Lehrveranstaltung mitten im Semester streicht? Wo liegt der Marketingtext für einen Studiengang, wenn die offizielle Beschreibung im SIS steht? Welches der beiden Systeme hat recht, wenn sie sich widersprechen? Im Folgenden arbeiten wir diese Fragen anhand der Plattformen durch, die die meisten Universitäten einsetzen.

Was eine Student-Information-System-Integration auf einer Universitätswebsite tatsächlich leistet

Das Student Information System ist das führende System der Institution für akademische Daten. Es enthält das Vorlesungsverzeichnis, den Stundenplan, Studiengangs- und Abschlussanforderungen, Einschreibungen, Noten, Zeugnisse und den akademischen Kalender. Nichts auf der öffentlichen Website sollte ihm widersprechen.

Die Website wiederum ist der Ort, an dem der Großteil dieser Daten tatsächlich gesehen wird. Studieninteressierte lesen Studiengangsseiten. Aktuelle Studierende prüfen, wann eine Lehrveranstaltung stattfindet. Studienberater schauen Voraussetzungen nach. Wenn Website und SIS auseinanderdriften, ist die Website im Unrecht – und diejenigen, die es bemerken, sind genau die Personen, die die Universität am wenigsten enttäuschen möchte.

Eine Integration erspart das doppelte Eintippen zwischen beiden Systemen. In der Praxis deckt sie eine recht kurze Liste von Datentypen ab, und es lohnt sich, diese zu benennen, da sich jeder anders verhält:

  • Vorlesungsverzeichnis: Kurscodes, Titel, Leistungspunkte, Beschreibungen und Voraussetzungen. Ändert sich ein paar Mal im Jahr, gebunden an ein Katalogjahr.
  • Stundenplan: Lehrveranstaltungen, Termine, Räume, Lehrende und Platzzahlen. Ändert sich während der Einschreibung täglich.
  • Studiengänge und Anforderungen: Abschlüsse, Schwerpunkte und die Regeln, die Kurse mit ihnen verknüpfen. Ändert sich selten, aber mit formaler Genehmigung.
  • Akademischer Kalender und Semester: Semestercodes, Fristen für An- und Abmeldung, Feiertage. Klein, stabil und wird von allem anderen referenziert.
  • Studierendenspezifische Daten: der Stundenplan, Sperrvermerke und Studienfortschritt eines bestimmten Studierenden. Personenbezogene Daten, die diesem Studierenden erst nach Authentifizierung angezeigt werden.

Die ersten vier sind institutionelle Daten und können auf öffentlichen Seiten erscheinen. Der letzte Punkt sind personenbezogene Daten, für die andere Regeln gelten, auf die wir weiter unten zurückkommen.

Drei Integrationsmuster und wann welches passt

Fast jede SIS-Integration auf einer Drupal-Website folgt einem von drei Mustern, und das falsche zu wählen, ist die häufigste Ursache für spätere Probleme. Die entscheidenden Faktoren sind, wie oft sich die Daten ändern, wie viele Personen sie lesen, und ob sie einer Einzelperson zuzuordnen sind.

Geplanter Import für Katalog- und Studiengangsseiten

Das SIS exportiert Kurs- und Studiengangsdaten nach einem Zeitplan, typischerweise nächtlich, und Drupal importiert sie in gewöhnliche Inhalte: einen Kurs-Inhaltstyp, einen Studiengangs-Inhaltstyp, Taxonomiebegriffe für Fächer und Semester. Die Migrate API im Drupal-Core übernimmt dies, wobei die beigesteuerten Module Migrate Plus und Migrate Tools JSON-, XML- und CSV-Quellen sowie die Werkzeuge zum Ausführen und Zurücksetzen von Importen hinzufügen. Das Feeds-Modul ist die Low-Code-Alternative für einfachere Feeds.

Einmal importiert, verhalten sich die Daten wie jeder andere Drupal-Inhalt. Sie sind durchsuchbar, cachefähig, übersetzbar und können von anderen Seiten aus referenziert werden. Redakteure können Felder hinzufügen, die das SIS nicht kennt, etwa eine Marketing-Zusammenfassung, ein Titelbild oder Testimonials, ohne den offiziellen Datensatz anzutasten. Die University of Dundee hat ihre Kursseiten auf diese Weise als benutzerdefinierte Entitäten gebaut, sie mit der Search API zusammen mit Personen und Fakultäten indiziert und den Bereich für grundständige Studiengänge im Juli 2019 als erste Version ausgeliefert.

Dieses Muster passt zu Daten, die sich in einem bekannten Zyklus ändern und von vielen Personen gelesen werden. Es passt nicht zu allem, was sich stündlich ändert, da ein nächtlicher Import immer hinterherhinkt.

Live-Abfrage für Verfügbarkeit und Stundenpläne

Hier wird nichts kopiert. Drupal fragt die SIS-API beim Aufruf einer Seite ab und stellt das Ergebnis dar. Das External-Entities-Modul ist genau dafür gebaut: Es definiert einen Entitätstyp, dessen Speicher ein entfernter REST-Endpunkt statt der Drupal-Datenbank ist, sodass die entfernten Daten dennoch mit Views, Anzeigemodi und Feld-Formatierern verwendet werden können. Views Remote Data bietet einen leichteren Weg, wenn nur eine Auflistung benötigt wird.

Die Live-Abfrage ist die richtige Antwort für Platzzahlen, den Status einer Lehrveranstaltung und alles andere, bei dem ein veralteter Wert in die Irre führt. Sie bringt zwei Kosten mit sich. Jeder Seitenaufruf wird zu einem API-Aufruf, sofern nicht sorgfältig zwischengespeichert wird, und die Verfügbarkeit der Website hängt nun von der Verfügbarkeit der SIS-API ab. Ein kurzer Cache mit definierter Gültigkeitsdauer und eine sanfte Ausweichmeldung, wenn die API nicht erreichbar ist, sind keine optionalen Extras. Ohne sie legt der erste Einschreibungstag die Website zusammen mit dem SIS lahm.

Authentifizierte Abfragen für studierendenspezifische Daten

Das dritte Muster betrifft das Studierendenportal: mein Stundenplan, meine Sperrvermerke, meine Abschlussprüfungsübersicht. Die Daten werden für die eingeloggte Person bei Bedarf abgerufen, einmal angezeigt und überhaupt nicht in Drupal gespeichert. Die Identität stammt aus dem campusweiten Single Sign-on; die Kennung der Studierenden aus dieser Sitzung ist das, worauf sich die SIS-Abfrage stützt.

Dieses Muster setzt voraus, dass die Identität zuerst geklärt ist, denn eine falsche Kennung liefert den Datensatz des falschen Studierenden zurück. Wir haben die Optionen in SSO-Integration mit SAML, Shibboleth, LDAP und CAS behandelt. Ist das geklärt, handelt es sich beim SIS-Aufruf selbst in der Regel um eine einzelne Anfrage an einen Personen- oder Studierenden-Endpunkt, die serverseitig mit den API-Zugangsdaten der Institution erfolgt – nie mit etwas, das im Browser sichtbar wird.

Manche Universitäten entscheiden, dass diese Ebene besser im hauseigenen Self-Service-Produkt des SIS-Anbieters aufgehoben ist als auf der Drupal-Website, und verlinken stattdessen dorthin. Das ist eine legitime Wahl und oft die günstigere. Drupal verdient sich seinen Platz im Portal, wenn die Institution SIS-Daten mit Inhalten, News, Veranstaltungen und Diensten kombinieren möchte, von denen das SIS nichts weiß.

Drupal mit den großen Plattformen verbinden

Jeder Anbieter stellt seine Daten unterschiedlich bereit, und diese Unterschiede bestimmen, welches Muster praktikabel ist.

Ellucian Banner und Colleague über Ethos

Ellucians empfohlener Weg für Drittanbieter-Integrationen ist Ethos, eine einheitliche REST- und JSON-Schicht, die sowohl über Banner als auch über Colleague liegt. Ethos präsentiert ein gemeinsames Datenmodell, sodass ein Kurs, eine Lehrveranstaltung oder eine Person unabhängig vom zugrunde liegenden Produkt dieselbe Struktur hat, und jeder Datensatz trägt eine GUID statt einer produktspezifischen ID. Ethos wird regional gehostet, mit separaten Endpunkten für die USA, Kanada, Europa und den asiatisch-pazifischen Raum, was für Institutionen mit Anforderungen an den Datenspeicherort relevant ist.

Für Drupal bedeutet dies, dass ein einziger Satz von Ressourcendefinitionen sowohl für Banner- als auch für Colleague-Campusse funktioniert, und das External-Entities-Modul kann Ethos-JSON mit seinem JSONPath-Mapper auf Felder abbilden. Der Zugriff wird auf Ellucian-Seite pro Ressource und pro Feld gewährt, sodass die erste Aufgabe des Projekts in der Regel darin besteht, sich mit dem Prüfungsamt darüber zu einigen, welche Ressourcen die Website benötigt – nicht Code zu schreiben. Ältere Banner-Campusse ohne Ethos stellen weiterhin direkte APIs und Datenbankansichten bereit; diese funktionieren, aber jede Integration wird campusspezifisch.

PeopleSoft Campus Solutions

Oracles Campus Solutions stellt Daten über Integration Broker bereit, seine Nachrichten- und Webdienste-Schicht, per REST oder SOAP. Vorlesungsverzeichnis- und Stundenplandaten stammen aus dem Student-Records-Modul, und das Konzept, das die meisten, die eine Integration bauen, überrascht, ist das Effective Dating (zeitliche Gültigkeit): Ein Kurs hat nicht eine Beschreibung, sondern eine Historie von Beschreibungen, jede gültig ab einem bestimmten Datum, und die Abfrage muss die richtige für das angezeigte Katalogjahr anfordern.

Deshalb eignet sich der geplante Import gut für PeopleSoft-Katalogdaten. Der Import kann Zeilen mit zeitlicher Gültigkeit einmal, nächtlich, auflösen und die aktuelle Version speichern. Diese Auflösung bei jeder Live-Anfrage vorzunehmen, wäre verschwenderisch. Die Live-Abfrage bleibt das richtige Muster für die Verfügbarkeit von Lehrveranstaltungen, wo der Wert eine einzelne aktuelle Zahl ist.

Workday Student

Workday stellt REST- und SOAP-Webdienste bereit sowie, für berichtsartige Extrakte, benutzerdefinierte Berichte, die als Datenfeeds veröffentlicht werden können. In der Praxis basieren viele Workday-Student-Integrationen auf diesen Berichtsfeeds: Das Prüfungsamt definiert einen Bericht, der genau die Kurs- und Lehrveranstaltungsfelder enthält, die die Website sehen darf, und Drupal konsumiert ihn nach Zeitplan. Dieser Ansatz hält den Datenvertrag explizit und legt die Kontrolle darüber, was das SIS verlässt, in die Hände derer, denen die Daten gehören.

Workdays Modell für Semester und akademische Zeiträume unterscheidet sich von dem von Banner und PeopleSoft, sodass die Feldzuordnung eine eigene Design-Sitzung verdient, statt aus einem früheren Projekt übernommen zu werden.

Hausinterne und regionale Systeme

Viele Universitäten betreiben ein eigenes System, eine nationale Plattform oder ein regionales Anbieterprodukt. Das Muster ändert sich nicht; nur der Transportweg. Wenn das System über eine API verfügt, kann External Entities oder ein benutzerdefiniertes Migrate-Quell-Plugin sie konsumieren. Kann es nur Dateien erzeugen, ist ein geplanter CSV- oder XML-Export auf einen SFTP-Speicherort und ein Migrate-Import eine durchaus respektable Integration – und oft zuverlässiger als eine fragile API. Der Punkt ist, den Datenvertrag und den Zeitplan zu vereinbaren und dann beides stabil zu halten.

Welches System die Datenhoheit hat

Die wichtigste Entscheidung im Projekt ist nicht technischer Natur. Es ist eine Festlegung, wem welche Felder gehören.

Dem SIS gehört alles Akademische und Offizielle: Kurscodes, Titel, Leistungspunkte, Voraussetzungen, Anforderungen, Termine, Semesterdaten. Drupal bearbeitet diese nie, sondern zeigt sie nur an. Ist eine Kursbeschreibung auf der Website falsch, erfolgt die Korrektur im SIS und wird beim nächsten Import übernommen.

Drupal gehört alles, wofür das SIS nie ausgelegt war: die Marketing-Erzählung des Studiengangs, Zitate von Lehrenden, Karriereergebnisse, Bildmaterial, Handlungsaufforderungen, Übersetzungen und Metadaten für Suchmaschinen. Diese Felder liegen auf der Drupal-Seite, an den importierten Datensatz angehängt, aber getrennt von ihm gespeichert, sodass ein Import nie die Arbeit eines Redakteurs überschreibt.

Dies als Feld-für-Feld-Tabelle festzuhalten, vereinbart zwischen Prüfungsamt und Web-Team, bevor irgendetwas gebaut wird, verhindert die beiden häufigsten späteren Streitpunkte: einen Redakteur, der einen Leistungspunktwert auf der Website geändert hat und über Nacht überschrieben wurde, und ein Prüfungsamt, das nicht versteht, warum ein von ihm gestrichener Kurs immer noch auf einer handgebauten Landingpage erscheint.

Ein Rückschreiben von Drupal ins SIS, bei dem ein Webformular einen SIS-Datensatz anlegt oder ändert, ist über Ethos und Integration Broker möglich, gehört jedoch einer anderen Risikokategorie an. Die meisten Institutionen leiten Bewerbungs- und Einschreibungsvorgänge über die eigenen Produkte des SIS-Anbieters oder ein Zulassungs-CRM und halten die Website gegenüber dem SIS nur lesend. Das ist der sinnvolle Standardfall.

Studierenden-Datenschutz in der Integrationsschicht: FERPA und DSGVO

In dem Moment, in dem eine Integration studierendenspezifische Datensätze berührt, verarbeitet sie regulierte Daten. In den USA unterscheidet FERPA zwischen Education Records, deren Weitergabe eine Einwilligung erfordert, und Directory Information wie Name und Studiengang, die eine Institution veröffentlichen darf, sofern der Studierende nicht widersprochen hat. In der Europäischen Union und im Vereinigten Königreich gilt die DSGVO für alle personenbezogenen Daten, und die Grundsätze der Zweckbindung und Datenminimierung regeln, wie viel davon die Website abrufen darf.

Drei Regeln halten eine Drupal-Integration auf der richtigen Seite beider Regelwerke:

  • Institutionelle Daten auf öffentlichen Seiten, personenbezogene Daten nur hinter Authentifizierung. Kataloge und Stundenpläne sind institutionell. Der eigene Stundenplan eines Studierenden ist personenbezogen.
  • Personenbezogene Daten bei Bedarf abrufen und nicht speichern. Das Muster der authentifizierten Abfrage existiert aus genau diesem Grund. Kein Studierendendatensatz sollte in einer Drupal-Tabelle oder in einem Seiten-Cache liegen, auf den ein anderer Nutzer stoßen könnte.
  • Nur die Felder anfordern, die die Seite verwendet. Sowohl Ethos als auch Workday-Berichtsfeeds erlauben es der Institution, den Zugriff pro Feld einzugrenzen. Eine enge Eingrenzung ist die günstigste verfügbare Compliance-Maßnahme.

Zu protokollieren, welches Systemkonto was und wann abgerufen hat, schließt die Lücke für die Prüfbarkeit. Die weiter gefassten Pflichten haben wir in DSGVO-Konformität mit Drupal erreichen behandelt; die Integrationsschicht ist der Ort, an dem viele davon konkret werden.

Was in der Praxis nicht funktioniert und wie man darauf vorbereitet

Integrationen scheitern selten am Tag des Launches. Sie scheitern beim ersten Ereignis, das das Design nicht vorausgesehen hat. Dies sind die wiederkehrenden Fälle.

  • Semesterwechsel. Das SIS eröffnet ein neues Semester, während die Website das alte noch als aktuell anzeigt. Modellieren Sie Semester explizit in Drupal und leiten Sie den Begriff „aktuelles Semester" aus dem SIS-Kalender ab, nicht aus einem fest codierten Datum.
  • Gestrichene und zusammengelegte Kurse. Ein Kurs verschwindet aus dem Export, seine Drupal-Seite mit eingehenden Links und Suchranking ist aber weiterhin live. Legen Sie im Voraus fest, ob der Import sie depubliziert, mit einem Hinweis archiviert oder auf einen Nachfolger umleitet.
  • Änderungen mit zeitlicher Gültigkeit. Eine ab dem nächsten Katalogjahr gültige Beschreibung erscheint auf der Seite des laufenden Jahres, weil die Abfrage nicht nach Datum gefiltert hat. Das ist ein PeopleSoft-Klassiker, aber das Konzept gibt es überall.
  • Cache-Invalidierung. Live-gelesene Daten werden aus Performancegründen gecacht, dann bleibt eine Platzzahl eine Stunde lang bei null, nachdem die Plätze freigegeben wurden. Legen Sie die Gültigkeitsdauer pro Datentyp fest und verkürzen Sie sie während der Einschreibungsfenster.
  • API-Limits und Ausfälle. Ein Startseiten-Block, der bei jeder Anfrage das SIS aufruft, wird am ersten stark frequentierten Morgen ein Rate-Limit ausschöpfen. Cachen Sie aggressiv, degradieren Sie sanft, und lassen Sie einen SIS-Ausfall nie zu einer leeren Seite führen.
  • Nicht übereinstimmende Kennungen. Die SSO-Identität verwendet eine Kennung, das SIS eine andere. Einigen Sie sich vor dem Bau des Portals auf die Zuordnung und testen Sie sie mit echten Konten, einschließlich Grenzfällen wie Mitarbeitenden, die zugleich Studierende sind.

Nichts davon ist exotisch. Ein einseitiges Runbook, das diese Fälle abdeckt und vor dem Launch geschrieben wird, ist mehr wert als der meiste Code.

Wie tief sollte die Integration gehen?

Nicht jede Universität benötigt alle drei Muster, und Portal-Funktionalität zu bauen, die niemand nutzt, ist eine gängige Art, zu viel auszugeben.

Eine Website auf Broschüren-Niveau braucht nur Studiengangsseiten, und diese können von Hand gepflegt werden, wenn die Studiengangsliste kurz und stabil ist. Eine Website auf Katalog-Niveau braucht den geplanten Import; dort liegt für die meisten Institutionen der größte Mehrwert, weil er das erneute Eintippen über Hunderte von Seiten hinweg erspart. Eine Website auf Portal-Niveau fügt authentifizierte Abfragen hinzu und lohnt sich nur, wenn die Institution eine einzige Eingangstür wünscht, die SIS-Daten mit allem anderen kombiniert, was der Campus veröffentlicht. Der Kostenunterschied zwischen den Stufen ist erheblich, und unsere TCO-Analyse von Open-Source- gegenüber lizenzierten Systemen zeigt, wie man den Implementierungsaufwand gegen Lizenzeinsparungen abwägt.

Es hilft auch, klarzustellen, was die SIS-Integration nicht ist. Sie ist nicht die Integration des Learning-Management-Systems. Das SIS verzeichnet, dass ein Studierender in einer Lehrveranstaltung eingeschrieben ist; das LMS liefert diese Lehrveranstaltung aus. Die beiden Integrationen bewegen unterschiedliche Daten, meist über unterschiedliche APIs, und werden am besten als separate Arbeitspakete abgegrenzt, auch wenn sie auf dasselbe Semester fallen.

Die erste Integration planen

Die technische Arbeit bei einer SIS-Integration ist kleiner, als sie aussieht. Der größere Teil ist die Verständigung: welche Felder die Website lesen darf, wem jedes einzelne gehört, wie oft jeder Typ aktualisiert wird und was beim Semesterwechsel passiert. Universitäten, die diese Fragen zuerst mit dem Prüfungsamt klären, neigen dazu, die Integration nur einmal zu bauen. Universitäten, die bei der API-Dokumentation beginnen, neigen dazu, sie zweimal zu bauen.

Die Drupal-Plattformen, die das Drupal4edu-Team bei Drupart für Institutionen wie die Sabancı-Universität, die METU und die Yıldız Technical University gebaut hat, sind genau um diese Art von Integrationsschicht herum konzipiert, bei der die Website aus den führenden Systemen der Institution liest, statt sie zu duplizieren. Mehr über unseren Ansatz erfahren Sie auf der Seite Drupal für Bildungseinrichtungen.

Häufig gestellte Fragen zur Drupal-SIS-Integration

Kann sich Drupal mit Ellucian Banner integrieren?

Ja. Der aktuelle Weg ist Ellucian Ethos, eine REST- und JSON-Schicht, die Banner- und Colleague-Daten in einem gemeinsamen Modell mit GUID-Kennungen präsentiert. Drupal liest Ethos-Ressourcen entweder geplant, mithilfe der Migrate API, um Kurse und Studiengänge als Inhalte zu importieren, oder live, mithilfe des External-Entities-Moduls, um entfernte Datensätze darzustellen, ohne sie zu speichern. Der Zugriff wird auf Ellucian-Seite pro Ressource und pro Feld eingegrenzt, sodass das Prüfungsamt genau kontrolliert, welche Daten die Website sehen kann. Ältere Banner-Installationen ohne Ethos lassen sich weiterhin über direkte APIs oder Datenbankansichten integrieren, aber jede solche Integration ist campusspezifisch.

Speichert Drupal Studierendendaten, wenn es sich mit einem SIS integriert?

Nur, wenn die Integration so konzipiert wurde, und bei personenbezogenen Daten sollte sie das nicht sein. Institutionelle Daten wie Vorlesungsverzeichnisse und Stundenpläne werden normalerweise in Drupal importiert, damit sie durchsucht, gecacht und mit Marketinginhalten angereichert werden können. Studierendenspezifische Daten wie der individuelle Stundenplan oder Sperrvermerke sollten für den authentifizierten Studierenden bei Bedarf abgerufen, angezeigt und wieder verworfen werden. Kein Studierendendatensatz muss in einer Drupal-Tabelle oder einem gemeinsam genutzten Seiten-Cache liegen, und ihn aus beidem herauszuhalten, ist die einfachste Möglichkeit, FERPA und DSGVO gleichzeitig zu erfüllen.

Wie oft sollten sich Kursdaten zwischen SIS und Website synchronisieren?

Das hängt vom Datentyp ab. Vorlesungsverzeichnis- und Studiengangsdaten ändern sich ein paar Mal im Jahr, und ein nächtlicher Import reicht mehr als aus; manche Institutionen führen ihn wöchentlich aus. Stundenplandaten ändern sich während der Einschreibung täglich, sodass entweder ein häufigerer Import oder eine Live-Abfrage mit kurzem Cache nötig ist. Platzzahlen und der Status von Lehrveranstaltungen sollten während der Einschreibungsfenster live gelesen werden. Für alles Echtzeit-Synchronisation zu versprechen, ist ein Fehler: Es kostet Performance und Zuverlässigkeit und bringt nichts für Daten, die sich nur mit dem akademischen Kalender ändern.

Was ist der Unterschied zwischen SIS-Integration und LMS-Integration?

Sie bewegen unterschiedliche Daten. Das Student Information System ist das führende System für Einschreibungen, Kurse und akademische Historie. Das Learning Management System, etwa Moodle oder Canvas, ist der Ort, an dem das Lehren stattfindet: Materialien, Aufgaben und Noten in Bearbeitung. Eine SIS-Integration bringt Katalog-, Stundenplan- und Einschreibungsdaten auf die Website. Eine LMS-Integration betrifft meist Single Sign-on und die Verknüpfung von Studierenden von der Website in ihren Kursbereich. Wir beschreiben die LMS-Seite in Moodle- und Drupal-Integration. Die beiden Projekte werden am besten separat abgegrenzt, auch wenn sie sich ein Launch-Datum teilen.

Ist eine Drupal-SIS-Integration FERPA-konform?

Konformität ist eine Eigenschaft des gesamten Designs, nicht irgendeiner Software. Eine Drupal-Integration kann so gebaut werden, dass sie FERPA-Pflichten erfüllt, indem Education Records hinter Authentifizierung gehalten, bei Bedarf statt gespeichert abgerufen, nur die von einer Seite verwendeten Felder angefordert und protokolliert werden, welches Systemkonto worauf zugegriffen hat. Directory Information wie Kurslisten und Namen von Lehrenden darf öffentlich erscheinen, sofern die Richtlinie der Institution oder ein Widerspruch eines Studierenden nichts anderes vorsieht. Das Prüfungsamt, nicht das Web-Team, entscheidet, welche Felder in welche Kategorie fallen, und diese Entscheidung sollte dokumentiert werden, bevor die Integration gebaut wird.

Letzte Aktualisierung: 15.09.2026 13:41