Vad är SUNETs Ladokadapter?

SUNETs Ladokadapter är en tjänst som alla lärosäten inom ramen för SUNET kan beställa. Den hjälper lärosätet att erhålla händelser från sin Ladokinstans som XML-meddelanden enligt industristandarden LIS (Learning Information Services). Adaptern är utvecklad för att fungera gentemot Ladok 3.

Tjänsten är händelsebaserad - det betyder att adaptern kontinuerligt lyssnar på er Ladokinstans, och när en händelse inträffar i Ladok, så kommer Ladokadaptern att uppfatta detta, berika händelsen med information om objektet som händelsen inträffade för, och publicera det resulterande objektet som ett XML-meddelande. Exempel på hur sådana meddelanden ser ut hittar ni i adapterns dokumentation.

Vad är SUNETs Canvasadapter?

SUNETs Canvasadapter är en tjänst som alla lärosäten inom ramen för SUNET kan beställa. Den hjälper lärosätet att transportera data i LIS-format in i Canvas.

Tjänsten är händelsebaserad - det betyder att tjänsten lyssnar på en uppsättning ändpunkter, och när ett korrekt meddelande anländer på någon av dessa ändpunkter så förs denna data över till Canvas (via ett LIS-interface som kallas Kimono - mer om det senare).

SUNETs Canvasadapter accepterar XML-meddelanden formaterade enligt LIS-standarden.

Översikt av helhetslösningen

Om man väljer att konfugera upp båda ovanstående adaptrar för sitt lärosäte så får man en helhetslöning för att hålla Canvas i synk med Ladok3. Då båda adaptrarna körs hos SUNET så behöver lärosätet inte sätta upp någon egen infrastruktur om man inte vill.

Viktigt att komma ihåg är att ingen data flödar åt andra hållet (i dagsläget), dvs en ändring i Canvas reflekteras inte i Ladok, och t.ex. resultat som registreras i Canvas förs INTE automatiskt över till Ladok.

Även om SUNETS Ladok- och Canvasadaptrar är två separata bitar mjukvara och kan användas helt och hållet på egen hand, så har de utvecklats samtidigt och aktiva val har tagits för att de ska fungera väl ihop.

Begränsningar/krav

Ett krav denna lösning ställer är att studenters samt sektionerna i Canvas har Ladoks UUID:n som SIS-ID. Detta för att registreringar ska kunna hanteras.

Kimono

Kimono är en molnbaserad integrationsplattform som Canvas använder för att kunna ta emot LIS-meddelanden. När vi i resten av dokumentationen pratar om att skicka meddelanden till Canvas så menas egentligen att meddelanden skickas till Kimono. Väl i Kimono översätts LIS-meddelandet till ett format som Canvas förstår, och förs sedan över till Canvas. I Kimono har man möjlighet att göra specialkonfigurationer för hur denna översättning ska gå till. Med denna metod så kan man t.ex. bestämma huruvida studenter ska få tillgång till ett kursrum vid registrering eller antagning, huruvida sammanslagningar (cross-listings för att använda en Canvas-term) ska göras automatiskt m.m. Det finns egentligen ingen begränsning i vilka Canvasbeteenden man kan skapa med hjälp av Kimonokonfoguration, men i dokumentationen här kommer vi enbart ta upp standardbeteendet samt några exempel på hur man kan förändra detta.

Personal

Personal finns ej i Canvas och måste föras över av lärosätet själv. Det enklaste sättet är att skapa en CSV-fil som laddas upp manuellt i Canvas. Om lärosätet har ett personalsystem eller integrationsplattform som kan producera LIS-meddelanden för sina anställda så kan lärosätet välja att skicka dessa till sin Canvasadapter hos SUNET. Detaljerna kring hur man gör detta hittar ni här: (WIP) Användningsfall: Använd Canvasadaptern för att synka användare från ert personalsystem till Canvas

Student

Ladokhändelserna LokalStudentEvent, StudentTillLarosateEvent samt KontaktuppgifterEvent genererar ett meddelande till Canvas.

Standardbeteende

Följande information förs över om studenten

Alla meddelanden till Canvas sätter användarens status till "active". Hantering av avlidna studenter och andra fall där användaren kan viljas tas bort får hanteras manuellt av lärosätet.

Möjlighet till konfiguration

Alla meddelanden till Canvas innehåller vilket Ladok-event som var källan till meddelandet, samt en boolean-flagga för huruvida studenten är avliden eller inte. Vill ni t.ex. ta bort en student automatiskt vid ett dödsfall (rekommenderas ej p.g.a. arkiveringskrav) så kontaktar ni er CSM hos Instructure som sätter er i kontakt med de som kan göra förändringar i er Kimono-instans.

Kurstillfälle

Ladokhändelserna KurstillfalleTillStatusEvent samt UtbildningstillfalleInstalltEvent (för ett kurstillfälle) genererar ett meddelande till Canvas.

Standardbeteende

Ett kursrum skapas i Canvas för varje kurstillfälle som kommer från Ladok3. Om eventet är KurstillfalleTillStatusEvent så sätts kursrummet som active i Canvas, med information enligt nedan. Om eventet är UtbildningstillfalleInstalltEvent så sätts kursrummets status till deleted i Canvas. Det går fortfarande att återskapa kursrummet via Canvas GUI.

Följande information förs över om kurstillfället:

Möjlighet till konfiguration

Det går att styra flera kurstillfällen till samma kursrum för att hantera scenarion där flera kurstillfällen ska ges i kursrum i Canvas, men det blir ingen 100%-ig lösning utan viss handpåläggning kan fortfarande krävas. Man implementerar det praktiskt som så att man i stället för kurstillfällets ID använder en uppsättning attribut som man vill sammaslå kurstillfällen baserat på, och använder detta som SIS-ID på kursen i stället för Ladoks ID.

Exempel: Om vi väljer att använda Kurskod och Termin som SIS-ID så kommer alla kurstillfällen för en viss kurskod och en viss termin dela kursrum i Canvas. Studenterna skulle fortfarande vara enrollade i var sen section i Canvas, där 1-1-förhållandet till kurstillfällen i Ladok finns kvar.

Det finns även vissa lärsosäten som inte vill sätta datum på sina kursrum, för att få en större flexibilitet i när studenter har åtkomst till rummen. Denna konfiguration görs tillsammans med Instructure, och går ut på att startdatum och slutdatum i LIS-meddelandet från oss inte skickas vidare till Canvas.

Studiedeltagande

Studiedeltagande är en sammanfattning för flera händelser:

Vid dessa händelser (samt deras inverser, t.ex. antagning borttagen), så skickas ett meddelande till Canvas. Vilken Ladok-händelse som leder till vilken Canvas-status hittar ni under Canvasadapterns dokumentation.

Standardbeteende

Följande information förs över till Canvas:

Möjlighet till konfiguration

Möjlighet till konfiguration i detta meddelande är begränsat, då det enbart innehåller de två UUID:n som ska sammankopplas. Det man kan konfigurera är om man vill ha ett annat beteende på vilket Ladokevent som leder till vilken status i Canvas.

Exempel: Om man vill att studenter ska få tillgång till kursrummet redan vid antagning (s.k. Early Access) i stället för registrering så behöver man släppa vidare LIS-meddelanden med "Admitted=true" till Canvas med statusen active.

Objekt i Canvas som måste hanteras manuellt

Terminer

Varje kurstillfälle som skickas till Canvas kommer vara märkt med Ladoks startterminskod för kurstillfället. Dock så förs inte terminer över med automatik till Canvas, utan måste skapas manuellt innan kurstillfället skickas till Canvas. Ni kan själva välja hur ni använder terminerna i Canvas (med/utan datum etc.), men terminens SIS-ID i Canvas måste matcha starterminskoden i Ladok 3 för att kopplingen mellan kurstillfällen och terminer ska fungera.

Organisationsstruktur/sub-accounts

Organisationsstruktur i Ladok förs inte över med automatik till Canvas utan måste underhållas manuellt i Canvas. Varje kurstillfälle kommer vara försett med ett attribut motsvarande givande institutions Ladok-kod, som gör att kursrum automatiskt sorteras in rätt i er subaccount-struktur i Canvas, förutsatt att subaccountets SIS-ID i Canvas motsvarar givande institutions kod i Ladok.


Lösningsarkitektur

Informationssamband

Denna bild beskriver de övergripande informationssambanden och relationerna mellan Ladok3 och Canvas

 

Mappningspecifikationer

Under denna rubrik kan du läsa om hur vi standardmässigt mappar attribut från LIS (från Ladok3) till Canvas. Det mesta går att ändra i Kimono tillsammans med Instructure. Specarna nedan ska ses som en standardmappning att utgå från så man slipper börja med ett blankt papper. Specarna kan användas som beställningsunderlag till Instructure.

LIS to Kimono Default Mappings.pdf

Här kommer snart även länkas till specifikationerna för det LIS-meddelanden som lämnar SUNET med verksamhetstermer. UMEÅ

Autentisering av användare

Användarens identitet federeras via SWAMID och mappas via fält i attributreleasen till en lokal användare i Canvas. Ladok3 har dock ingen kännedom om en students användar-ID. För att lösa detta tittar projektet på en lösning som liknar inloggningsförfarandet i Ladok3. Dvs. kunna ta tex personnummer ur attributreleasen och mappa mot ett fält på användaren i Canvas. SUNET driver frågan om en anpassning mot Canvas.