Table of Contents

Vad är Ladok-LIS adapter?

Ladok-LIS adapter är en tjänst som alla lärosäten som använder Ladok kan använda. 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.

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 Canvas adapter ä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 Ladok. 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.

Det finns en överskådlig presentation av processen via sidan http://www4.gu.se/doc/2014/processer/sunet/canvas/

Begränsningar/krav

Ett krav på denna lösning ställer är att studenters samt sektionerna i Canvas har Ladoks UUID:n som SIS-ID (SIS=Student Information System). 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 Ladok 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

• StudentID (Ladok UUID)
• Förnamn
• Efternamn
• E-post
• Personnummer

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 Ladok. 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:

• KurstillfällesID (Ladok)
• Termin
• Tillfällesskod
• Kurskod
• Kursnamn
• Poäng
• Undervisningstakt
• Undervisningstid
• Studieort
• Startdatum
• Slutdatum

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 sin 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:

• Antagning
• Registrering
• Studieavbrott
• Uppehåll 

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:

• Studentens Ladok-UUID
• Kurstillfällets Ladok-UUID
• Antagen (boolean)
• Registrerad (boolean)
• Avbrott (boolean)
• Uppehåll (boolean)
• Ladoks händelsetyp (Registrering, Omregistrering, Avbrott etc.)

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. Se vidare SUNETs Canvas adapter.

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 Ladok och Canvas

Mappningspecifikationer

Under denna rubrik kan du läsa om hur vi standardmässigt mappar attribut från LIS (från Ladok) 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

Specifikationerna för det LIS-meddelanden som lämnar SUNET går att finna under respektive sida och tjänst, 'Ladok Adapter' och 'SUNET Canvas Adapter'. Under canvas-adaptern redovisas de förändringar som görs i LIS-meddelandet för att anpassa det mot canvas.

Autentisering av användare

Användarens identitet federeras via SWAMID och mappas via fält i attributreleasen till en lokal användare i Canvas. Ladok 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 Ladok. 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.

• EduID

  För att kunna använda EduID som autentiseringslösning för Canvas så måste er Canvas-instans registreras som Service Provider i SWAMID. För att göra detta, kontakta operations@swamid.se. Som Login ID i Canvas behöver i så fall samma mailadress sättas som mailadressen på personens EduID. Detta går att konfigurera i Kimono. För att konfigurera upp EduID som SAML-provider i Canvas kan man göra enligt följande mall:

  

• Egen IdP
  Det går alldeles utmärkt att använda sin egen IdP för att autentisera användare i Canvas. Det går att välja helt fritt i konfigurationen av Canvas vilket attribut från er IdP som ska matchas mot användarens Login ID i Canvas (Personnummer, användarnamn etc.)