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.
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.
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.
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 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
Ladokhändelserna LokalStudentEvent, StudentTillLarosateEvent samt KontaktuppgifterEvent genererar ett meddelande till Canvas.
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.
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.
Ladokhändelserna KurstillfalleTillStatusEvent samt UtbildningstillfalleInstalltEvent (för ett kurstillfälle) genererar ett meddelande till Canvas.
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:
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 ä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.
| Ladokhändelse | LIS | Kimono/Canvas | Kommentarer |
|---|---|---|---|
SUNETs Canvasadapter skickar standardiserade meddelanden till Canvas. Det går dock att i samråd med Instructure anpassa hur man vill mappa informationen i meddelandet till Canvas för det enskilda lärosätet. Detta görs i ett integrationsverktyg som heter Kimono av personal från Instructure. Nedan beskrivs några typfall av mappningar som styr beteendet i Canvas.
Normalfallet är att en student får tillgång till ett kursrum i Canvas när registreringen sker på en studieperiod under motsvarande kurstillfälle i Ladok3. Om man vill ge tillgång till kursrummet redan vid antagning så behöver detta konfigureras upp i Kimono. Alla LIS-meddelanden från SUNETs Ladokadapter innehåller information om vad för händelse i Ladok3 som triggade meddelandet. Denna information följer med över till Kimono och kan användas för att styra mappningen där.
Värden som Instructure ska sätta i Kimono:
Normalfallet är att ett kursrum skapas per kurstillfälle i ladok3. Om man vill slå samman flera parallella kurstillfällen som samläses till ett kursrum i Canvas kan man slå samman ett antal attribut i meddelandet som nyckel för kursrummet.
Exempel:
Värden som Instructure ska sätta i Kimono:
Ett vanligt scenario är att man vill låsa upp kursrummet för antagna studenter så att de kan förbereda sig. Man vill däremot inte att dessa studenter ska finnas kvar i kursrummet om de aldrig dyker upp. Detta går att lösa genom att sätta ett tidsbegränsat medlemskap i kursrummet vid antagning, tex fram till ett par dagar innan kursen startar. En registrering ger studenten permanent medlemskap. Det gör att studenter som registrerar sig i tid inte kommer att märka övergången.
Exempel:
Värden som Instructure ska sätta i Kimono:
Varje kurstillfälle som skickas till Canvas kommer vara märkt med startterminskoden 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.
Denna bild beskriver de övergripande informationssambanden mellan Ladok3 och Canvas. Bilden kommer inom kort ersättas med en renritad bild.
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.
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.
För att kunna använda EduID som autentiseringslösning för Canvas så måste er Canvas-instans registreras 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: