Hej!

Chalmers har sedan vi gick in i Ladok 3 2018 huvudsakligen en databas (benämnd l3data) som fylls på och uppdateras av Ladoks feeds. Den innehåller all data som kommer via feedsen. Vi har försökt att modellera databasen utifrån Ladoks informationsmodell (men eftersom de inte publicerar den så är det ju bara vår gissning av hur den ser ut). De flesta av våra integrationer som behöver rå ladokdata läser ur den databasen. Strategiskt håller vi på att införa ett tjänstegränssnitt mot databasen (GraphQL) för att löskoppla tabellstrukturen från klienterna. Vissa lokala konsumenter behöver rå data som inte kommer via feeds, dessa läser direkt via Ladoks REST-API.

Vi läser över de vanligaste informationsmängderna till vårt masterdatasystem, där vi översätter till en Chalmers-specifik datamodell. De flesta konsumenter som inte explicit interagerar med Ladok läser denna chalmers-modell och blir därmed oberoende av vad Ladok hittar på. Det har räddat oss många gånger. Det är också nästan nödvändigt eftersom Chalmers ger utbildning till flera tusen studenter som registreras i GU:s Ladok. En Ladok-feed kommer aldrig att ge oss alla studenter, och att slå samman två feeds har sina utmaningar.

Som tekniskt lärosäte har vi också en struktur på våra utbildningar som Ladok inte stödjer fullt ut. Data behöver bearbetas och slås samman med andra källor för att bli fullt användbar. Det går t ex inte att från datan vi lagrar i Ladok se vilka som är aktiva år 4 och 5 på civilingenjörsutbildningarna. Ladok har inte förmågan att lagra all informationen som behövs för att kunna veta det, givet hur Chalmers valt att implementera civing kombinerat med Bolognamodellen.

De flesta integrationer hos oss läser på klocka och agerar då de ser att det behövs, men givet att vi bara har 10.000 HST så är det inget problem för oss.

Valet av dessa lösningsmönster baserades främst på att väldigt få av ladoks feed-meddelanden innehöll all den information våra konsumenter behövde. Alla konsumenterna skulle behöva ha varsinn "cache", med risk för att dessa diffade. Det verkade (åtminstone 2017) smartare att ha en enda cache, så att vi bara hade ett enda ställe att korrigera eventuella fel. Vi behövde också bara ha en enda konsument som var beroende mot det exakta utseendet på ladoks feeds. Under Ladok3-projektet var allt i ständig förändring, och vi ville hålla oss så oberoende som möjligt mot exakta format och data som Ladok skickade. När Ladok väl blev skarpt så avtog ändringstakten, så det argumentet är inte giltigt längre.

Vi ser framöver en önskan att kunna sprida händelser internt. Vi är dock inte alls intresserade av att sprida ladok-händelser i den råa form de kommer från Ladok. Nästan ingen av konsumenterna bryr sig t.ex. om huruvida ett förväntat deltagande skapats, annulerats eller fått ett återbud, eller om en registrering skapats, dragits tillbaks eller om det kommit ett avbrott. De bryr sig enbart om hur en viss students relation till en viss kurs/kurstillfälle förändrats. Det är den informationen vi vill sprida händelser för internt - att student X numera har relation W till kurstillfälle Y inom kurs Z.

Vi har än så länge en stark tro på en arkitektur där konsumenternas behov är löst kopplade till en central dataleverantör. Vi vill inte att den centrala dataleverantören kodifierar konsumenternas informationsbehov. Därför är en ren pub/sub-arkitektur inte i vår smak. Vårt masterdatasystem använder ett API som likt GraphQL låter konsumenten begära vilken data den skall få tillbaks. En ändring i en konsuments behov leder då aldrig till att vi behöver ändra någon annanstans än i den konsumenten. Vi kommer därför sannolikt att sprida väldigt tunna meddelanden när vi kommer dit, alternativt använda GraphQL subscriptions eller liknande teknik för att behålla klienternas kontroll över vilken data de läser.

mvh,
/Viktor


From: Tina Harberts via Ati <ati@lists.sunet.se>
Sent: 13 November 2024 08:40
To: ati@lists.sunet.se <ati@lists.sunet.se>
Cc: Julia Cheung <julia.cheung@ki.se>
Subject: [Ati] Ladok-Cache - fråga från vår tjänsteansvarig
 

Hej ATI-gänget!

 

En av våra tjänsteansvariga har försökt skicka ut en fråga till ATI-nätverket, men hon verkar inte ha behörighet att maila till listan. Hon har bett oss att göra ett försök. Här kommer hennes fråga samt kontaktuppgifter:

 

Hej,

Vi har ett Ladok-cache på KI som är tekniskt eftersatt och vi står inför ett beslut om hur vi ska göra med det framöver.

Vi skulle vilja fråga hur ni tankar in data om studenter och doktorander från Ladok med hjälpa av dessa frågor: 

  1. Hur hämtar ditt universitet/högskola data om studenter och doktorander från Ladok?
  2. Varför har ditt universitet/högskola valt att implementera det?
  3. Hur fungerar detta alternativ? Fördelar och nackdelar med detta alternativ?
  4. Hur länge planerar ni att använda detta alternativ?
  5. Övrigt ni vill dela med er om

Tack på förhand för er hjälp!

Med vänlig hälsning

 

Julia Cheung | Tjänsteansvarig för behörighets- och organisationsinformation
IT-avdelning | Karolinska Institutet
Nobels väg 5 | 171 77 Stockholm
08-524 861 64 | 070-281 29 75
julia.cheung@ki.se | ki.se

Karolinska Institutet – ett medicinskt universitet

 

 

Hoppas att någon kan hjälpa Julia med den input hon frågar efter!

 

Hälsningar,

Mats & Tina

 

Tina Harberts, arkitektur / test

IT-avdelningen, Karolinska Institutet

Nobels väg 5, 171 65 Solna

+46 (8) 524 871 51

tina.harberts@ki.se  ki.se

 

Karolinska Institutet - ett medicinskt universitet

 



När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI kommer att behandla dina personuppgifter. Här finns information om hur KI behandlar personuppgifter. 


Sending email to Karolinska Institutet (KI) will result in KI processing your personal data. You can read more about KI’s processing of personal data here.