OneRoster (1.2 und erweiterte Gruppen)
OneRoster ist ein internationaler Standard für den Austausch von Schulverzeichnissen (herausgegeben von 1EdTech): Er beschreibt in einem gemeinsamen Format die Einrichtungen, die Schuljahre, die Kurse, die Klassen, die Einschreibungen und die Benutzer einer Schule. Er dient dazu, ein SIS, ein Schulportal oder ein LMS ohne erneute Erfassung und ohne proprietäres Format an ein anderes Werkzeug anzubinden.
Diese Seite richtet sich an die IT-Abteilung der Einrichtung. Sie beschreibt, was Omniscol in OneRoster bereitstellt und einliest, die erwartete Authentifizierung und den tatsächlichen Umfang jeder Austauschrichtung.
Unterstützte Versionen
Omniscol unterstützt OneRoster 1.2 Rostering — den Grundstock (Org, AcademicSession, Course, Class, Enrollment, User, Demographics) — sowie die Schicht OR-Groups (Advanced Groups Service), den additiven Gruppenstandard, der drei Entitäten (Group, GroupMembership, GroupAssociation) auf 1.2 aufsetzt.
Die Schicht OR-Groups ist ein Standard in der Veröffentlichungsphase. Sie ist streng additiv zu 1.2: Eine Group verweist lediglich auf die Entitäten Class / User / Org / AcademicSession von 1.2, schreibgeschützt. Die Version 1.3 von OneRoster ist angekündigt, um Class zu einer Spezialisierung von Group zu machen — eine Ausrichtung, mit der die Implementierung von Omniscol bereits konvergiert.
Omniscol als Produzent (Omniscol → Schulportal / LMS)
Als Produzent stellt Omniscol das Verzeichnis der Einrichtung schreibgeschützt über eine OneRoster-konforme REST-API bereit, damit ein Schulportal oder ein LMS es einliest.
- Der Grundstock Rostering 1.2 wird unter
/ims/oneroster/rostering/v1p2/…ausgeliefert (zum Beispiel/orgs,/schools,/academicSessions,/courses,/classes,/enrollments,/users,/teachers,/students,/demographics, jeweils mit seinen verschachtelten Varianten). - Die Gruppenschicht wird unter
/ims/oneroster/groups/v1p0/…ausgeliefert (/groups,/groupMemberships,/groupAssociationsund ihren verschachtelten Varianten). - Der Umfang ist standardmäßig das laufende Schuljahr; ein Parameter erlaubt es, ein anderes Jahr zu adressieren oder alle Jahre abzudecken.
Die Daten spiegeln die konsolidierte Planung von Omniscol wider (aktive / veröffentlichte Stundenpläne). Der Produzent ist schreibgeschützt nach Wahl: Es wird kein Schreibzugriff (PUT / DELETE) bereitgestellt — ein entferntes System steuert nicht die Erstellung oder Löschung von Entitäten in Omniscol.
Authentifizierung des Produzenten
Die Zugangspunkte des Produzenten sind durch OAuth2 im Flow
client_credentials geschützt (Maschine-zu-Maschine-Token, ohne
Benutzer), ausgestellt vom OAuth2-Server von Omniscol. Sie sind nicht
den Premium-Konten vorbehalten: Der Zugriff wird durch die OAuth2-Scopes
gesteuert, nicht durch das Angebot. Jeder Scope ist spezifisch für einen
Dienst, und der Zugriff auf demografische Daten ist innerhalb der 1.2
abgeschottet:
| Zugangspunkte | Akzeptierte Scopes |
|---|---|
| Rostering 1.2 (ohne Demografie) | https://purl.imsglobal.org/spec/or/v1p2/scope/roster-core.readonly, https://purl.imsglobal.org/spec/or/v1p2/scope/roster.readonly |
Rostering 1.2 /demographics |
https://purl.imsglobal.org/spec/or/v1p2/scope/roster.readonly, https://purl.imsglobal.org/spec/or/v1p2/scope/roster-demographics.readonly |
| OR-Groups (alle) | https://purl.imsglobal.org/spec/or-groups/v1p0/scope/roster-group.readonly |
Ein OR-Groups-Token gewährt keinen Zugriff auf den Grundstock Rostering, und umgekehrt. Es wird kein Schreib-Scope angekündigt. Die privilegierten Scopes werden von der Omniscol-Verwaltung zum Zeitpunkt der Registrierung des OAuth2-Clients zugeteilt; ein Client kann sie sich nicht selbst zuweisen. Die Verwaltung der OAuth2-Clients und der Token ist auf OAuth2 / OIDC (Anbieter) und Omniscol-API beschrieben.
Der Umfang der Schüler wird von der Gruppenschicht getragen
Strukturierende Wahl: Die Liste der Schüler einer Klasse oder einer Gruppe wird über OR-Groups (GroupMembership) bereitgestellt, nicht allein durch den Grundstock 1.2. Ein Konsument, der nur Rostering 1.2 liest, erhält den Katalog (Courses, Classes), die Einschreibungen Lehrkraft → Kurs und das Benutzerverzeichnis, aber nicht die Zugehörigkeit der Schüler. Um zu erfahren, wer in welcher Klasse oder welcher Gruppe ist, muss der Konsument die Schicht OR-Groups implementieren. Diese Wahl spiegelt das französische Modell wider: Ein Schüler ist in eine Klasse oder eine Gruppe eingeschrieben, nicht Fach für Fach.
Der Produzent stellt sich über REST bereit. Das Format OneRoster-CSV-Bundle (Zip-Archiv mit einer Datei je Sammlung) wird hingegen auf der Importseite unterstützt, für Anbieter, die ihr Verzeichnis per Datei statt per API liefern — siehe den Abschnitt zum Konsumenten weiter unten.
Omniscol als Konsument (SIS → Omniscol)
Als Konsument importiert Omniscol das Verzeichnis eines OneRoster-konformen SIS und gleicht es in die Einrichtung ab. Diese Konsumentenkonfiguration ist Teil der Synchronisierung mit externen Systemen: Sie ist auf Premium-Konten verfügbar und wird projektbezogen mit dem Omniscol-Team abgestimmt (siehe Synchronisierung mit externen Systemen).
- Transport — entweder die REST-API des Anbieters (die
Basisadresse wird konfiguriert, die standardmäßige
OneRoster-Paginierung wird befolgt), mit OAuth2-Authentifizierung im
Flow
client_credentialsgegen den Server des Anbieters; oder ein CSV-Bundle (Zip-Archiv). - Profil — ein Konfigurationsprofil gibt den zu lesenden Umfang an: Grundstock 1.2 allein, Gruppenschicht oder französische Abbildung für die schulische Bildung. Ein rein 1.2-Anbieter, ohne Gruppendienst, wird sauber importiert.
- Kontrollierte Anwendung — der Import folgt demselben Prinzip wie die anderen Konnektoren: Omniscol ruft die Daten ab und gleicht sie ab, und ein Administrator validiert die Anwendung auf die Einrichtung. Das entfernte System schreibt niemals direkt in Omniscol.
- Idempotente Reimporte — die Zuordnungen der externen Identifikatoren bleiben erhalten, sodass ein Reimport keine Dubletten erzeugt, selbst wenn der Anbieter eine Beschriftung umbenennt.
Französisches Profil (schulische Bildung)
Das französische Profil für die schulische Bildung bildet die
französischen Begriffe auf das OneRoster-Modell ab: Eine Klassenteilung
(die Klasse im eigentlichen Sinne) wird zu einer Group des
organisatorischen Haupttyps; eine Gruppe wird zu einer Group für die
pädagogische Vermittlung; eine Gruppe von Gruppen zu einer
übergreifenden Group; die Klassenteilungen und Gruppen-Ausrichtungen
werden zu Gruppenassoziationen; die Zuweisung einer Lehrkraft zu
einem Kurs wird zu einer Einschreibung der Lehrkraft. Identifikatoren wie
die INE oder der Personalidentifikator werden in den userIds des
Benutzers geführt.
Identifikatoren und Vertraulichkeit
Jede bereitgestellte Entität trägt einen stabilen Identifikator, die
sourcedId.
- Die strukturellen Identifikatoren (Einrichtung, Jahr, Kurs, Klasse, Gruppe) sind von einem Export zum nächsten stabil und unveränderlich: Ein Konsument kann sich darauf verlassen, um Daten über die Zeit hinweg zu korrelieren.
- Der Identifikator des Benutzers ist anonymisiert: Omniscol überträgt niemals seinen eigenen namentlichen Identifikator nach außen. Das nach außen übertragene Token wird durch eine Einwegfunktion (HMAC) abgeleitet, die dem Konto eigen ist; die Einschreibungen und Zugehörigkeiten verwenden dieses Token wieder, ohne jemals den ursprünglichen Identifikator preiszugeben.
Status
- Produzent — verfügbar und ohne entfernten Partner vorführbar (der Export genügt sich selbst). Rostering 1.2 und die Schicht OR-Groups werden schreibgeschützt bereitgestellt, mit OAuth2-Authentifizierung.
- Konsument — die Importkonfiguration ist Teil der Premium-Synchronisierung. Die Inbetriebnahme einer Live-Synchronisierung mit einem SIS hängt vom Anbieter und gegebenenfalls von den ministeriellen Zeitplänen ab: Sie wird auf Anfrage abgestimmt, Konnektor für Konnektor. Es handelt sich nicht um eine sofortige, schlüsselfertige Synchronisierung.