[Ati] Re: Ladok-Cache - fråga från vår tjänsteansvarig

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 &lt;ati(a)lists.sunet.se&gt; Sent: 13 November 2024 08:40 To: ati(a)lists.sunet.se &lt;ati(a)lists.sunet.se&gt; Cc: Julia Cheung &lt;julia.cheung(a)ki.se&gt; 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<mailto: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<mailto: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<https://ki.se/om-ki/integritetsskyddspolicy>. 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<https://staff.ki.se/data-protection-policy>.