Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Vad är

...

Ladok-LIS adapter?

Ladok-LIS adapter är en tjänst som alla lärosäten inom ramen för SUNET kan beställalä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 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 kommer Ladok-LIS adaptern 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 CanvasadapterCanvas 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 få att transportera data i LIS-format att hamna 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. 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 Canvas 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

En användare skapas i Canvas när studenten blir antagen till en kurs på lärosätet.

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 skapas i Ladok3. Det går att 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. Följande information förs över till Canvas om ett kurstillfälle

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

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:

...

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 under Canvasadapterns dokumentation.

Sammanfattning meddelanden

  • Kolumn Ladok avser den händelse i Ladok som Ladokadaptern lyssnar på
  • Kolumn LIS avser vilket LIS-meddelande som skapas utifrån Ladokhändelsen.
  • Kimono/Canvas avser vilken effekt LIS-meddelandet får i Canvas (OM man inte har begärt specialmappningar i Kimono - mer om det senare).

...

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.

Sammanslagning av Kursrum

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:

Stryp tillgång till kursrummet för antagna studenter som inte registrerat sig

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:

Hantering av termin

Termin styr statistik och filter i Canvas. Det går att koppla kursen till en termin automatiskt vid integration.  Man kan lämna termin tom och man kan sätta ett datumintervall på kursen i Canas.

Exempel:

...

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.

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. Bilden kommer inom kort ersättas med en renritad bild.Ladok och Canvas

 Image RemovedImage Added

Mappningspecifikationer

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

View filenameLIS to Kimono Default Mappings.docxheight250pdf

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. Ladok3  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 Ladok3Ladok. 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:

Så här beställer du SUNET Canvas Adapter

...

  • 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.)