Hantering av integrationer i Ladok3

Bo Sehlberg Sida: 1 (25) Hantering av integrationer i Ladok3

Bo Sehlberg Sida: 2 (25) Versionshistorik Version Datum Utfärdare Kommentar 0.1 2012-02-27 Bo Sehlberg Första Utgåvan 0.6 2012-04-02 Bo Sehlberg Justering av kap 2. 0.7 2012-04-02 Bo Sehlberg Omstrukturering och komplettering kap 3, samt nytt namn på dokumentet 0.8 2012-04-04 Bo Sehlberg Mindre korrigeringar. 0.9 2012-04-11 Bo Sehlberg Kompleteringar och förtydliganden 0.91 2012-04-16 Bo Sehlberg Ytterligare mindre kompletteringar 0.92 2012-04-17 Bo Sehlberg Ändringar i kapitel 4.1 kring metakatalog

Bo Sehlberg Sida: 3 (25) INNEHÅLL 1 INLEDNING... 4 1.1 MÅLGRUPP... 4 1.2 REFERENSDOKUMENT... 5 1.3 BEGREPP... 5 2 FÖRÄNDRINGAR... 6 2.1 ANVÄNDARGRÄNSSNITT... 6 2.2 TJÄNSTEGRÄNSSNITT... 6 2.3 DATABASGRÄNSSNITT... 7 2.3.1 Uppföljningsbehov... 7 2.3.2 Integrationsbehov... 7 2.3.3 Felsöknings/registervårdsbehov... 7 3 SCENARION... 9 3.1 ÖVERGRIPANDE PÅVERKAN... 9 3.1.1 Exempel nuläge... 9 3.1.2 Påverkan på integrationer... 10 3.1.3 Exempel nyläge 1... 11 3.1.4 Exempel nyläge 2... 12 3.2 INTEGRATIONSMÖNSTER... 13 3.2.1 Data Consistency... 13 3.2.2 Multistep Process... 13 3.2.3 Composite Application... 13 3.3 KONSEKVENSER FÖR LPW ANVÄNDARGRÄNSSNITT... 14 3.3.1 Dagens Ladok... 14 3.3.2 Ladok3... 14 3.4 KONSEKVENSER FÖR ANVÄNDNING AV LPW FÖR UTDATA... 15 3.4.1 Dagens Ladok... 15 3.4.2 Ladok3... 15 3.5 KONSEKVENSER FÖR ANVÄNDNING AV SQL FÖR UTDATA... 16 3.5.1 Dagens Ladok... 16 3.5.2 Ladok3... 16 3.6 KONSEKVENSER FÖR ANVÄNDNING AV LPW LÄS / SKRIV FÖR DIALOG, INTERAKTION... 18 3.6.1 Dagens Ladok... 18 3.6.2 Ladok3... 18 3.7 LPW LÄS / SKRIV FÖR DIALOG, INTERAKTION MED SQL LÄS... 19 3.7.1 Dagens Ladok... 19 3.7.2 Ladok3... 19 3.8 KONSEKVENSER FÖR ANVÄNDNING AV SQL SPEGLA TILL/FRÅN DB-KOPIA... 20 3.8.1 Dagens Ladok... 20 3.8.2 Ladok3... 20 3.9 FÖRÄNDRINGAR I TJÄNSTEGRÄNSSNITT... 21 3.9.1 Begär studiedeltagande... 21 3.9.2 Svar studiedeltagande... 22 4 LPW-TJÄNSTER... 23 4.1 SOAP-TJÄNSTER... 23 4.2 WEBBGRÄNSSNITT... 24 4.3 PORTLETS... 25 4.4 PING... 25

Bo Sehlberg Sida: 4 (25) 1 Inledning Övergången till Ladok3 kommer att innebära stora förändringar med avseende på integrationer på lärosätena. Det är därför viktigt att lärosätena får en uppfattning om vad övergången till Ladok3 innebär, med avseende på de integrationer som finns mot dagens Ladok och hur de behöver anpassas vartefter Ladok3 färdigställs och så småningom införs. Detta dokument är tänkt som ett komplement till tidigare dokument med fokus på integration och är därför inte en komplett beskrivning av lösningen för Ladok3. Dokumentet beskriver övergripande olika scenarion och hur dessa kan påverkas vid övergången till Ladok3. De beskrivningar som presenteras ska endast ses som principiella, eftersom varje lärosäte har individuella lösningar och behov. Dokumentet tar även upp viktiga principiella skillnader mellan dagens SOAP-baserade tjänster i LpW och motsvarande REST-baserade tjänster i Ladok3. För att få en så smidig övergång som möjligt till de nya REST-tjänsterna, är det viktigt att lärosätena aktivt deltar med beskrivning av sina integrationer mot Ladok och även tillhandahåller motsvarande kravställning till projektet. De i dokumentet beskrivna förändringarna, ska ses som ett underlag för att underlätta bedömningen av omfattningen på de förändringar en övergång till Ladok3 innebär för lärosätena. Genom att dokumentera vilken typ av integrationer, för vilket ändamål och vilken information man hanterar, kan lärosätena stötta projektet med kravunderlag för de RESTtjänster som projektet tar fram. 1.1 Målgrupp Dokumentet vänder sig främst till systemägare, Ladokansvariga, integratörer och arkitekter.

Bo Sehlberg Sida: 5 (25) 1.2 Referensdokument Referens Dokument 1. Ladok3_Nationellt system. https://www.ladok.se/fileadmin/forvaltning/bibliotek/ladok3/ovriga_resultatdok _forberedelse/120214_ladok3_nationellt_system.pdf 2. PO_PM_SF_Gränssnitt_Identiteter. https://www.ladok.se/fileadmin/forvaltning/bibliotek/ladok3/pm_sf_graenssnit t_identiteter.pdf 1.3 Begrepp Begrepp Atom feed DBA REST Förklaring Atom är ett XML-baserat format för publicering av information, som använder http för transport. Databasadministratör Representational State Transfer, är ett IT-arkitekturbegrepp som beskriver hur tjänster för maskin till maskin-kommunikation kan tillhandahållas. Begreppet härrör från en avhandling av Roy Fielding - en av författarna till HTTP-specifikationen - och har fått en snabb spridning inom systemutvecklingsområdet. LpW Ladok på Web, se även 4 LW-tjänster Webbgränssnitt för olika utdata-tjänster, se även 4.2 LP-tjänster Ladok Ping-tjänster se även 4.4 T-tjänster Ladok SOAP-tjänster, se även 4.1 TG-tjänster Ladok Portletar, se även 4.3 SOAP SQL Ett protokoll för utbyte av information i decentraliserade och distribuerade miljöer (tidigare även kallat Simple Object Access Protocol), se även 4.1 Structured Query Language, ett standardiserat språk för att hämta och modifiera data i en relationsdatabas

Bo Sehlberg Sida: 6 (25) 2 Förändringar 2.1 Användargränssnitt Ladok3 planeras att tillhandahålla två kompletta användargränssnitt: Studentens gränssnitt Internt gränssnitt (för administratörer, lärare, examinatorer etcetera) Studentgränssnittet har en gemensam funktionalitet och ska vara anpassningsbart med avseende på grafisk layout till det lokala lärosätets webbplats via stylesheets. Det interna gränssnittet är däremot samma för alla lärosäten, på samma sätt som Nouveau idag är gemensamt. Systemet separerar dock åtkomsten till informationen baserat på vilket lärosäte man ansluter sig från, så att varje lärosäte har kontroll på sin information. Mer information om användargränssnittet finns i ref [2]. I och med att Ladok3 kommer att tillhandahålla kompletta användargränssnitt för de funktioner Ladok3 tillhandahåller, sker nedanstående förändringar mot dagens Ladok: LWxx-tjänster (10 st) (webbgränssnitt för hantering av olika typer av utdata) ersätts generellt av de funktioner som ska finnas i det inbyggda webbaserade användargränssnittet för Ladok3, då främst i uppföljningsdelen. LW-tjänsterna som separat produkt blir därför överflödiga i Ladok3. TGxx-tjänster (13 st portlets) ersätts generellt av standardanvändargränssnittet (student/internt) i Ladok3. Inga TGxx-tjänster finns därför inplanerade i Ladok3. Som alternativ till TGxx-tjänsterna finns motsvarande funktionalitet tillgänglig via samma REST-tjänster som används av Ladok3:s webbgränssnitt. Autentiseringen i Ladok3 användargränssnitt ska kunna hantera dagens autentiseringslösningar, där Single sign-on (SSO) baseras på SAML2 och Swami-federationen. 2.2 Tjänstegränssnitt Ladok3 planeras att bli en gemensam installation för alla lärosäten. I och med det finns inte längre något behov av den Ping-lösning som används idag: LPxx-tjänster (5 st pingtjänster) ersätts generellt av Ladok3:s användargränssnitt och motsvarande REST-tjänster i kombination med möjligheten att via behörighet tillåta andra lärosäten att få tillgång till motsvarande funktion och information i Ladok3. De Txx-tjänster (SOAP) som finns i dagens Ladok kommer att ersättas av motsvarande RESTtjänster i Ladok3. REST-tjänsterna i Ladok3 kommer sannolikt inte att ha en exakt ett-till-ettmotsvarighet till dagens Txx-tjänster, men de planeras täcka upp för minst de behov som dessa ger stöd för idag. Förutom den tekniska skillnaden mellan SOAP och REST, finns det även motsvarande skillnader med avseende på de informationsobjekt som används och hur de hanteras, se även 3.9 för mer information om förändringarna. Txx-tjänster (30 st) ersätts därför av liknande REST-tjänster, där: o o T02, T10, T12, T20, T23 T28, T30, T32, används av de flesta lärosätena Övriga används av enstaka lärosäten (färre än hälften)

Bo Sehlberg Sida: 7 (25) Alla funktioner i Ladok3 nås via REST-tjänster, därför använder användargränssnitten i Ladok3 också REST-tjänster. Det betyder att omfattningen av REST-tjänster kommer att vara avsevärt större än dagens T-tjänster. 2.3 Databasgränssnitt Målsättningen med Ladok3 är att minska användningen av SQL till ett absolut minimum. Det finns flera orsaker till detta, främst: Att minimera beroenden mellan Ladok och lokala lösningar Att säkerställa att man inte kortsluter systemets affärslogik Att säkerställa aktivitetsloggning och spårbarhet Idag används SQL för i huvudsak tre olika användningsområden i Ladok, antingen mot produktionsdatabasen eller mot en speglad kopia (Ladok Open). De är: 1. Uppföljningsbehov 2. Integrationsbehov 3. Felsöknings-/registervårdsbehov 2.3.1 Uppföljningsbehov Användning av direkt SQL-åtkomst för uppföljningsbehov i dagens Ladok kommer att hanteras enligt följande i Ladok3: Ersätts i första hand av det stöd Ladok3:s uppföljningsdel tillhandahåller via de inbyggda funktionerna för rapporter och andra typer av utsökningsfunktioner. Ersätts i andra hand, om Ladok3:s uppföljningsdel inte anses tillräcklig, av en egen databas med lämpligt schema (med fördel baserat på uppföljningsdelens schema), som föds med innehåll via händelser från Ladok3. Denna egna databas kan då driftas samordnat eller lokalt på lärosätet. För mer information om hantering av uppföljningsbehovet, se även 3.5. 2.3.2 Integrationsbehov Användning av direkt SQL-åtkomst för integrationsändamål i dagens Ladok kommer att hanteras enligt följande i Ladok3: Direkt SQL-access för skrivning ersätts av REST-tjänster i Ladok3. Direkt SQL-access för läsning ersätts i första hand av REST-tjänster i Ladok3. Om behov av direkt SQL-åtkomst finns kan det hanteras mot en separat uppföljningsdatabas med det lärosätets speglade information från uppföljningstjänsten i Ladok3, enligt princip som beskrivs i 3.5. 2.3.3 Felsöknings/registervårdsbehov Varje lärosäte ska ha nödvändigt stöd för felsökning och registervård. Det bör även vara möjligt för lärosätena att läsa sin egen tabellinformation, som komplement till de vanliga registervårdsdelarna. För behov som det inbyggda stödet för felsökning och registervård inte har tillräckligt stöd för, ska det finnas en DBA-support som kan hantera direkt åtkomst till den gemensamma databasen via SQL. Denna hantering bör skötas av en central supportfunktion med ett systemadministrativt ansvar, där man även bör logga alla typer av problem för att kunna

Bo Sehlberg Sida: 8 (25) upptäcka återkommande problem och genom det få ett underlag för framtida funktionella kompletteringar av felsöknings-/registervårdsstödet i systemet.

Bo Sehlberg Sida: 9 (25) 3 Scenarion 3.1 Övergripande påverkan I de följande kapitlen beskrivs en förenklad bild av dagens Ladok och dess omgivning med integrationer mot/från andra system vid ett fiktivt lärosäte. 3.1.1 Exempel nuläge Idag finns en mängd olika integrationer mot Ladok. Många äldre integrationer baseras uteslutande på direkt åtkomst mot databasen via SQL, eftersom inget annat alternativ funnits. I och med Ladok på Webb används även detta gränssnitt frekvent i olika sammanhang. Nedanstående figur visar ett fiktivt lärosäte (baserat på en blandning av olika verkliga). Ovanstående figur visar Ladok på vänster sida med Nouveau-klienter längst upp. Därunder finns bland annat lärosätets system för hantering av utbildningsinformation, som nyttjar SQL direkt mot Ladok. Under Ladok finns kommunikation mot externa parter (CSN, SCB, NyA, etc.). Uppe till höger finns lärosätets egen studentportal, som nyttjar både LpW-tjänster och SQL (såväl för läsning som skrivning). Till höger har lärosätet en egen Ladok Open-kopia för utläsning av information för bland annat kontroll av data, och uttag av underlag för vidare bearbetning (sammanfattas fortsättningsvis som rapporthantering). Där finns också en egen testinstallation. Därunder finns ett antal olika system, som läser/skriver uppgifter från/till Ladok för till exempel hantering av tentamen och praktik.

Bo Sehlberg Sida: 10 (25) 3.1.2 Påverkan på integrationer Nedanstående figur visar översiktligt, med röd markering, vilka integrationer som påverkas av Ladok3, det vill säga i stort sett alla integrationer. Följaktligen visas även de delar som försvinner, i och med Ladok3, med rödmarkering. Ladok Noveau-klienterna ersätts av Ladok3:s webbaserade användargränssnitt. LpW-tjänsterna (SOAP-tjänsterna) ersätts av REST-tjänster. SQL-kopplingar direkt mot Ladok DB ersätts av REST-tjänster. När det gäller kopplingarna mot CSN, SCB, etcetera så påverkar de inte lärosätenas integration, eftersom dessa hanteras centralt i Ladok3. Detta betyder att i princip alla integrationer kommer att påverkas, mer eller mindre.

Bo Sehlberg Sida: 11 (25) 3.1.3 Exempel nyläge 1 För att få en mer långsiktigt bra lösning måste de SQL-kopplingar lärosätet har använt mot dagens Ladok Open, ersättas av motsvarande REST-tjänster. På det sättet kan lärosätet även få nytta av de nya möjligheterna med Ladok3. Ladok Nouveau ersätts med Ladok3:s nya webbaserade administratörsgränssnitt. LpW-tjänster (TG/SOAP och T/portlets) i studentportalen ersätts med länkar till/från nyckelfärdiga tjänster i studentgränssnittet i Ladok3. Rapporthanteringen ersätts med den inbyggda uppföljningsdelen i Ladok3. För integrationerna mot (behörighetsinformation) för Alumni, Schema och Bokning tar Metakatalog emot händelser om studenter och studiedeltagande. Metakatalogen används sedan av dessa system för att hämta behörighetsinformation. För Tentamensanmälan och Praktik i figuren har man använt sig av Ladok3:s REST och/eller Atom feeds, för integrationen mot Ladok. Systemet för Utbildningsinformation, till vänster, anpassas till de nya REST-tjänsterna i Ladok3 och lärosätet väljer därmed att ersätta motsvarande funktion i Ladok Referens med sin egen lösning.

Bo Sehlberg Sida: 12 (25) 3.1.4 Exempel nyläge 2 Nedanstående figur visar översiktligt hur ovanstående system skulle kunna se ut efter en migrering till Ladok3, i de fall ett absolut krav på användning av SQL finns på lärosätet. I det här exemplet vill lärosätet behålla SQL-gränssnitten (med de justeringar som ändå behövs på grund av ändringar i datamodell) för kunna tillhandahålla de rapporter man behöver i kombination med eget data. Lärosätet valde därför att behålla SQL-kopplingen för Rapporter, som då arbetar mot en egen databas. Databasen förses med uppdateringar via händelser (Atom feeds) från Ladok och kan lämpligen vara baserad på samma teknik som den inbyggda uppföljningsdelen i Ladok3. I övrigt hanteras integrationerna enligt Alternativ 1.

Bo Sehlberg Sida: 13 (25) 3.2 Integrationsmönster Gartner beskriver tre olika huvudtyper av integrationsmönster. Data Consistency Multistep Process Composite Application Dessa integrationsmönster används i olika omfattning och kombinationer för de integrationer som finns mot Ladok idag. Konsekvensbeskrivningarna i kap 4.3 och efterföljande kapitel beskriver endast integrationen i respektive anslutningspunkt (pilände) i nedanstående beskrivna integrationsmönster. Integrationsmönstren kan användas i kombination med de olika integrationer lärosätet använt för att få en uppfattning av komplexiteten och kostnaden på lärosätet i respektive fall. 3.2.1 Data Consistency Målet med mönstret Data Consistency är att säkerställa att samma information som lagras i flera system är konsistent. Detta mönster är även tänkt att användas för synkronisering mellan dagens Ladok och Ladok3, d v s envägssynkronisering från ett till ett annat system. Vanligtvis ett mindre kostsamt integrationsmönster. 3.2.2 Multistep Process I mönstret Multistep Process hanteras ett verksamhetsflöde för att automatisera genomförandet av olika steg i en affärsprocess. Troligen ett ganska vanligt mönster på lärosätena. Vanligtvis ett mer kostsamt integrationsmönster än Data Consitency. 3.2.3 Composite Application Mönstret Composite Application agerar som en enhetlig applikation, men denna använder sig av flera tjänster i bakgrunden. Detta mönster används i olika sammanhang också, t ex i lärosätenas studentportaler. Vanligtvis det mest kostsamma av dessa integrationsmönster.

Bo Sehlberg Sida: 14 (25) 3.3 Konsekvenser för LpW användargränssnitt Ladok3 tillhandahåller två kompletta webbaserade användargränssnitt: Studentens gränssnitt Internt gränssnitt (för administratörer, lärare, examinatorer, etc.) Studentgränssnittet ska vara anpassningsbart med avseende på grafisk layout till det lokala lärosätets webbplats via stylesheets. Det interna gränssnittet är samma för alla lärosäten. Mer information om användargränssnittet finns i ref [2]. 3.3.1 Dagens Ladok Lärosätet använder TG-tjänster (portlets) i sin egen portal mot Ladok och/eller LW-tjänster (webb) mot Ladok. 3.3.2 Ladok3 Ladok3 kommer att tillhandahålla ett webbaserat gränssnitt för administratörer/lärare samt ett för studenter, som bland annat innefattar funktioner som motsvarar det LW- och TG-tjänsterna (webb resp. portletar) tillhandahåller i dagens Ladok. Ladok3 kommer därför inte att levereras med dessa som separata moduler. I de fall lärosätet har en egen webbportal kan denna kombineras med det webbaserade gränssnittet i Ladok3, genom att man länkar ihop webbplatserna med varandra enligt princip i nedanstående figur.

Bo Sehlberg Sida: 15 (25) Principiellt kan det då fungera enligt följande. Om studenten till exempel klickar på länken Registrera på kurs i menyn i lärosätets webbportal länkas den vidare till motsvarande sida/formulär i Ladok3:s webbgränssnitt, som då öppnas i samma fönster. Är studenten redan identifierad på lärosätet, behövs ingen ytterligare identifiering i Ladok3:s webbgränssnitt. Genom den anpassade layouten kan en liknande layout som på lärosätets egen portal visas. Användaren gör sin registrering och ser resultatet och kan därefter välja att klicka på länken Tillbaka och blir då länkad tillbaka till lärosätets portal. Vill lärosätet ändå använda de portletar som finns tillgängliga i dagens Ladok, kan lärosätet ta befintlig källkod för de portletar man vill fortsätta att använda och anpassa dem till de nya REST-tjänsterna mot Ladok3. Detta kan med fördel göras i samarbete med eventuella andra lärosäten som också vill använda dem. Ett annat alternativ är att lärosätet i sin egen webbapplikation istället använder de RESTtjänster som Ladok3:s webbgränssnitt använder. Genom att använda dessa REST-tjänster får man ett naturligt plattformsoberoende stöd för studentens användargränssnitt. 3.4 Konsekvenser för användning av LpW för utdata 3.4.1 Dagens Ladok Lärosätet använder LW-tjänster (webb) och/eller T-tjänster (SOAP) för att läsa information från Ladok för exempelvis rapporter. 3.4.2 Ladok3 Ladok3 tillhandahåller en uppföljningsdel, som bland annat ska innefatta de utdatadelar som LW-tjänsterna tillhandahåller. De T-tjänster som används för utdataändamål i dagens Ladok ersätts av REST-tjänster som bland annat tillhandahåller motsvarande funktionalitet.

Bo Sehlberg Sida: 16 (25) 3.5 Konsekvenser för användning av SQL för utdata 3.5.1 Dagens Ladok Lärosätet använder en Ladok Open-databas för att exempelvis kunna söka och ta ut rapporter med SQL. 3.5.2 Ladok3 Ladok3 kommer att ha en helt ny datamodell och är en gemensam installation för alla lärosäten, varför dagens SQL-baserade lösningar inte kommer att fungera. På grund av detta kommer det inte heller att vara möjligt att spegla ut databasen på samma sätt som idag med t ex Ladok Open. 3.5.2.1 Uppföljning standardlösning I första hand hanteras utdata av Ladok3:s inbyggda stöd för uppföljning och rapporter. Uppföljningsdelen kan då också användas för utsökning med möjlighet att ta ut resultatet för efterbearbetning i t ex Excel. Lärosätet använder enbart det inbyggda stödet för uppföljning utdata/rapporter, med verksamhetsdata från övriga delar i Ladok, men även aggregerad information för exempelvis årsredovisning. 3.5.2.2 Uppföljning utökad standardlösning I de fall det inbyggda stödet för uppföljning/rapporter/utdata inte uppfyller ett lärosätes behov, kan det kompletteras med en egen rapportfunktion. Den egna rapportfunktionen använder då motsvarande REST-tjänster för att skapa utökade rapport-/uppföljningsfunktioner och även ge möjlighet att sammanföra information med andra lokala informationskällor, t ex ekonomisystem.

Bo Sehlberg Sida: 17 (25) 3.5.2.3 Uppföljning anpassad lösning samordnad drift Vill lärosäte även fortsättningsvis använda sig av SQL kan en alternativ lösning i Ladok3 vara möjlig, men hanteras då tekniskt på ett annat sätt. Lärosätet använder ändå primärt det inbyggda stödet för uppföljning utdata/rapporter, men kompletterar det med en egen kopia av Ladok3:s uppföljningsdel. Den egna uppföljningsdatabasen innehåller enbart information för det egna lärosätet, men kommer ha en fördröjning på uppdateringen (timmar) för att inte belasta den gemensamma lösningen. 3.5.2.4 Uppföljning anpassad lösning lokal drift Som ett alternativ till att ha en egen uppföljningsdel med någon form av samordnad drift, kan lärosätet även välja att drifta den i egen regi och på det sättet få större flexibilitet. I övrigt motsvarar denna funktionellt föregående lösning med samordnad drift.

Bo Sehlberg Sida: 18 (25) Med en egen lokal lösning kan lärosätet även få en bättre möjlighet att sammanföra information med andra lokala informationskällor, t ex ekonomisystem. 3.6 Konsekvenser för användning av LpW läs / skriv för dialog, interaktion 3.6.1 Dagens Ladok Lärosätet har applikationer, som använder sig av T-tjänsterna (SOAP) för åtkomst till Ladok. 3.6.2 Ladok3 De T-tjänster som finns i dagens Ladok kommer att ersättas av motsvarande REST-tjänster i Ladok3. REST-tjänsterna i Ladok3 kommer inte att ha en exakt motsvarighet till dagens T- tjänster, men ska täcka upp dessa funktionellt. Förutom den tekniska skillnaden mellan SOAP och REST, finns det även motsvarande skillnader med avseende de informationsobjekt som används. Se även 3.9 för mer information om de tekniska förändringarna.

Bo Sehlberg Sida: 19 (25) 3.7 LpW läs/skriv för dialog, interaktion med SQL Läs 3.7.1 Dagens Ladok Lärosätet har en applikation, som använder sig av Txx-tjänsterna för åtkomst till Ladok, men använder även SQL för kompletterande information, som till exempel saknas i T-tjänsterna. 3.7.2 Ladok3 I Ladok3 finns två huvudsakliga alternativa vägar att gå. 3.7.2.1 Alternativ 1 1. Övergå helt och hållet till REST-gränssnitten 2. Kombinera REST-gränssnitten med kompletterande spegel-db och SQL-läs. Detta är det rekommenderade alternativet. För att kunna nyttja Ladok3 fullt ut bör applikationen konverteras för att enbart använda REST-tjänsterna, istället för kombinationen Txx-tjänster och SQL. Det betyder att all SQL-åtkomst byts ut mot motsvarande RESTtjänster. Det är därför viktigt att projektet får tillräckligt kravunderlag från lärosätena för att tillgodose behovet. 3.7.2.2 Alternativ 2 Detta alternativ finns att tillgå för de lärosäten som har behov av långtgående informationsuttag som inte tillgodoses av REST-gränssnitt. Senare dialog får avgöra frekvens och metod för uppdatering av lokal databas.

Bo Sehlberg Sida: 20 (25) 3.8 Konsekvenser för användning av SQL spegla till/från DB-kopia 3.8.1 Dagens Ladok I vissa fall kan ett lokalt verksamhetssystem baseras på en kopia av Ladok DB (hela eller en del av), som uppdateras med jämna mellanrum. Ny information som skapas i det lokala verksamhetssystemet speglas tillbaka till Ladok DB på motsvarande sätt. 3.8.2 Ladok3 I Ladok3 finns två huvudsakliga alternativa vägar att gå. 1. Övergå helt och hållet till REST-gränssnitten 2. Använda händelser till den lokala databasen och REST-tjänster från den lokala databasen och fortsätta använda SQL från lokala verksamhetssystem. 3.8.2.1 Alternativ 1 För att kunna nyttja Ladok3 fullt ut bör applikationen konverteras för att enbart använda REST-tjänsterna istället för kombinationen REST-tjänster och SQL. 3.8.2.2 Alternativ 2 Ett annat alternativ är att använda sig av överföring av händelser från Ladok3 till en egen lokal databas enligt 3.5.2 för SQL-läsning och på motsvarande sätt göra REST-anrop till Ladok3 för ändringar som görs i det lokala verksamhetssystemet. Troligen blir detta både mer komplext och dyrare än alternativ 1.

Bo Sehlberg Sida: 21 (25) 3.9 Förändringar i tjänstegränssnitt I Ladok3 baseras tjänstegränssnitten på REST, istället för SOAP, enligt de arkitekturella principer som tagits fram för Ladok3. Med REST får man en lösare koppling mellan systemen och därmed ett mindre beroende. I SOAP använder man bara en liten del av de möjligheter som HTTP ger, då HTTP används enbart som ett transportprotokoll där. Med REST utnyttjas HTTP som ett applikationsprotokoll. De T-tjänster (SOAP) som används i dagens Ladok använder ett XML-schema, som utgår från den informationsmodell som finns i dagens Ladok. Eftersom Ladok3 kommer att ha en helt ny informationsmodell, kommer även dessa XML-scheman att påverkas. Det betyder att förutom övergång från SOAP-baserade tjänster till REST-baserade, så kommer även informationsinnehållet att skilja sig åt. Till exempel kan vissa enskilda SOAP-tjänster ersättas med flera REST-tjänster. Informationsobjekten kan se annorlunda ut med olika mängd attribut, etc. I följande kapitel ges exempel på ett SOAP-anrop och motsvarande svar, samt ett motsvarande REST-anrop med svar. 3.9.1 Begär studiedeltagande Med SOAP beskriver anropet ett gränssnitt, som ska hantera anropet. Ändras gränssnittet måste även anropet ändras. Det http-verb som används är POST, även då man hämtar uppgifter. SOAP POST /studiedeltagande HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: 123 <?xml version="1.0"?> <soap:envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingstyle="http://www.w3.org/2001/12/soap-encoding"> <soap:body xmlns:m="http://www.example.org/studiedeltagande"> <m:getstudiedeltagande> <m:studiedeltagandeid>1234</m:studiedeltagandeid > </m:getstudiedeltagande > </soap:body> </soap:envelope> I REST begär man istället en resurs. REST GET /studiedeltagande/1234 HTTP/1.1

Bo Sehlberg Sida: 22 (25) 3.9.2 Svar studiedeltagande Svaret i SOAP innehåller i princip en datastruktur, som man sen kan använda på olika sätt, t ex genom att skapa en ny SOAP-begäran enligt 3.9.1 för att hämta nya uppgifter eller uppdatera någon uppgift. SOAP HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingstyle="http://www.w3.org/2001/12/soap-encoding"> <soap:body xmlns:m="http://www.example.org/stock"> <m:getstudiedeltaganderesponse> <m:studiedeltagandeid>1234</m:studiedeltagandeid> <m:student>6789</m:student> <m:kurstillfalle>6789</m:kurstillfalle> <m:impediment>utanför_registreringsperiod</m:impediment> <m:skapad>2012-01-17t14:59:15.992</m:skapad> <m:tillstånd>ej_påbörjat</m:tillstånd> </m:getstudiedeltaganderesponse> </soap:body> </soap:envelope> Svaret i REST innehåller motsvarande resultat men innehåller också på samma gång uri:er till de olika resurserna. En sådan uri kan sedan användas till att påverka eller skapa en resurs, men också för att hämta motsvarande resurs information. På det sättet får man automatiskt information om vad man kan göra i den aktuella tjänsten. I nedanstående exempel kan man hämta uppgifter för studenten 5678 och kurstillfället 6789. På motsvarande sätt kan man ( dap:action ) registrera på studiedeltagandet 1234, men inte lämna återbud på studiedeltagandet ( dap:impediment ). REST HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <studiedeltagande xmlns=http://schemas.studiedeltagande.ladok.se xmlns:dap="http://schemas.studiedeltagande.ladok.se/dap"> <dap:link rel="http://relations.studiedeltagande.ladok.se/student" uri="http://studentkatalog.ladok.se/student/5678" mediatype="application/vnd.ladok+xml"/>

Bo Sehlberg Sida: 23 (25) <dap:link rel="http://relations.studiedeltagande.ladok.se/kurstillfälle" uri="http://localhost:8084/katalog/kurstillfalle/6789" mediatype="application/vnd.ladok+xml"/> <dap:link rel="self" uri="http://localhost:8082/studiedeltagande/1234" mediatype="application/vnd.ladok+xml"/> <dap:action rel="http://relations.studiedeltagande.ladok.se/återbud"> <dap:impediment>utanför_registreringsperiod</dap:impediment> </dap:action> <dap:action rel="http://relations.studiedeltagande.ladok.se/registrering"> <dap:link uri="http://localhost:8082/studiedeltagande/registrering/1234" mediatype="application/vnd.ladok+xml"/> </dap:action> <skapad>2012-01-17t14:59:15.992</skapad> <tillstånd>ej_påbörjat</tillstånd> </studiedeltagande> 4 LpW-tjänster Ladok på Web tjänsterna omfattar fyra olika typer: T-tjänster (SOAP) LW-tjänster (webb) TG-tjänster (portlets) LP-tjänster (ping) Dessa beskrivs kort i följande kapitel. 4.1 SOAP-tjänster T02 Registerutskrift, grund och avancerad nivå T03 T04 llen. T05 viss kurs. T06 prov. T07 lle) T08 T09 kurs. T10 lle T11 T12 kthet. T13 Val av kurser inom program med terminsregistrering

Bo Sehlberg Sida: 24 (25) T14 Registerutskrift forskarstuderande T15 Val av val av inriktning. T16 kta T17 T18 forskarstudier T19 kan kan T20. mta T21 programuppgifter om en student T22 ten T23 kursen (inom tre veckor) T24 ndra adress T25 r Registerad T26 - r uppe T27 rteckning. T28 Verifiering av intyg n T12, T16 och T25 T29 kurs T30 tter T11. nst T31 llen i LADOK databasen. T32 jlighet till examen T33 prov T34 hel kurs 4.2 Webbgränssnitt LW01 ljning av kohorter av program LW02 ende kurs LW03 program LW04 ngproduktion LW05 LW06 r att klara kurs LW07 LW08 R-databasen LW09 Registreringsverifikat LW10 lja upp olika aspekter av forskarutbildning

Bo Sehlberg Sida: 25 (25) 4.3 Portlets TG02 TG05 TG06 TG09 TG12 TG19 TG20 TG23 TG24 TG28 TG29 TG30 TG32 TG67 TG80 4.4 Ping LP01 LP02 LP03 LP04 Gränssnitt för registerutskrift, grund- och avancerad nivå Uppföljning på kurs Gränssnitt för resultatrapportering, grund- och avancerad nivå Deltagare på kurs Gränssnitt för verifierbart resultatintyg, grund- och avancerad nivå Gränssnitt Följa examensansökan Gränssnitt Examensansökan Tidigt avbrott på kurs Gränssnitt Ändra adress Gränssnitt Verifiering av intyg Tacka nej till antagning Gränssnitt för registrering, grund- och avancerad nivå Gränssnitt Examenskontrollör Resultatrapportering grund och avancerad nivå Verifierbara intyg Användaradministration Visning av doktoranduppgifter Visning av studentuppgifter Visning av studentuppgifter för CSN