Utgåva 2.0 Ladok 3 arkitektur B Sehlberg, J Stenberg, M Berglund Sida: 1 (45) Ladok3. Nationellt system
|
|
- Linda Lundberg
- för 8 år sedan
- Visningar:
Transkript
1 B Sehlberg, J Stenberg, M Berglund Sida: 1 (45) Ladok3 Nationellt system
2 B Sehlberg, J Stenberg, M Berglund Sida: 2 (45) Innehåll 1 Introduktion Syfte Mål Begränsningar Referenser Förkortningar Definitioner och centrala begrepp Styrande effektmål Övriga förutsättningar Sammanfattning Fördelar Nackdelar Risker Arkitekturella mål Vision Icke-funktionella krav Prestanda Tillgänglighet Förvaltning Säkerhet Skalbarhet Övriga krav Effektmål Effektmål 6 Flexibilitet Effektmål 7 Användbarhet Effektmål 1 Förbättrad kommunikation Effektmål 4 Lokal kostnadseffektivitet Effektmål 3 Gemensam kostnadseffektivitet Effektmål 2 Tillgänglighet och autentisering Effektmål 5 Tillförlitlighet och säkerhet Arkitekturella principer Viktiga grundprinciper Standarder Logisk vy Övergripande arkitektur Ladok3 som molntjänst Lagringsteknik Meddelandehantering Integration med andra system (lokala och externa) Autentisering/auktorisering Grundfunktionalitet i Ladok Ladok användargränssnitt Ladok kärna Ladok Referens Ladok Integration Lokala Anpassningar Tjänster och meddelanden i Ladok Tjänstemodell... 21
3 B Sehlberg, J Stenberg, M Berglund Sida: 3 (45) Meddelandeflöde i Ladok Processer Processtjänster Scenariovy Informationsvy Gemensam central lösning Rapportdata Driftsättningsvy Systemöversikt Implementationsvy Säkerhetsvy Autentisering och auktorisering Säkerhetsnivåer Detaljering av autentiseringen Lärosäte som använder central tjänst Lärosäte med lokala tillägg Loggning Validering av data Integrationsvy Core Services Ladok Integration modellen Grundprinciper Viktiga grundprinciper utifrån krav Övriga grundprinciper Arkitekturella mönster Tjänstearkitektur Definition av tjänst i Ladok Tjänst anropar tjänst Händelsestyrd uppdatering Från Ladok Till Ladok Fråga svar Från Ladok Till Ladok Risker och möjligheter Decentraliserad lagring Meddelandehantering SOA... 45
4 B Sehlberg, J Stenberg, M Berglund Sida: 4 (45) Figurer Figur 1: Ladok3 i kontext Figur 2: Övergripande moduler Figur 3: Nyckelfärdigt Ladok användargränssnitt Figur 4: Eget användargränssnitt istället för Ladok användargränssnitt Figur 6: Användning av Ladok Referens Figur 5: Anpassade tjänster Figur 7: Tjänster i Ladok Figur 8: Meddelandeflöden i Ladok Figur 9: Exempel på fysisk separering av information Figur 10: Exempel på logisk separering av information Figur 11: Exempel på distribution till egna databaser Figur 12: Driftsättningsvy Figur 13: Hantering av roller i Ladok Figur 14: Hantering av autentisering i Ladok Figur 15: Hantering av lokala tjänster mot Ladok Figur 16 Integrationsvy Figur 17: 4+1 scenariovyn Figur 19: Komponenter i en verksamhetstjänst Figur 19: Tjänster beroende av varandra Figur 20: Tjänster oberoende av varandra genom händelseuppdaterad cache Figur 21: Händelse till ett annat system via direkt tjänsteanrop Figur 22: Händelse till ett eller flera system via en meddelandetjänst Figur 23: Händelse till befintligt system via sammansatta händelser Figur 24: Händelse till ett system via direkt tjänsteanrop Figur 25: Händelse till Ladok och eventuella fler system via meddelandetjänster Figur 26: Hantering av mottagning av information från gamla system Figur 27: Ladok hämtar uppgift från annat system Figur 28: Annat system hämtar uppgift från Ladok... 43
5 B Sehlberg, J Stenberg, M Berglund Sida: 5 (45) Utgåvehistorik för dokumentet Utgåva Datum Kommentar Första publicerade version Uppdaterad med bl a använda standards Mindre korrigeringar Kompletterat masterdata, samt diverse mindre justeringar Justerat vissa begrepp och namnsättningar, kompletterat med möjliga lokala anpassningar i kärnan Infört diskussion kring risker i kap Anpassningar mot remiss och fastställd.
6 B Sehlberg, J Stenberg, M Berglund Sida: 6 (45) 1 Introduktion 1.1 Syfte Detta dokument beskriver ett förslag på en övergripande arkitektur för Ladok3. Med hjälp av ett antal olika vyer på arkitekturen beskrivs olika aspekter av systemet och dess uppbyggnad. Avsikten är att fånga och förmedla betydande arkitekturella val i förhållande till effektmålen, de funktionella och icke-funktionella kraven. 1.2 Mål Målet med dokumentet är att få ett underlag för bedömning av kostnader för utveckling av ett nytt Ladok, samt för att kunna gå vidare med bedömningar av olika lösningsalternativ. 1.3 Begränsningar Dokumentet behandlar enbart en övergripande arkitektur på Ladok3. Arkitekturen baseras på krav från motsvarande verksamhetsprojekt. Den beskrivna arkitekturen är inte en färdig detaljerad arkitektur, utan fokuserar främst på principer. 1.4 Referenser Referens Beteckning 1. Ladok3 Tjänstebaserad arkitektur, SOA_01.pdf 2. Övergripande kravspecifikation Process 8 v0.5.docx 3. Projektdirektiv Ladok3 Lösningsdelprojekt Referens Beteckning I. Patterns of Enterprise Application Architecture, Martin Fowler II. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Gregor Hohpe, Bobby Woolf III. Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans IV. Microsoft Architecture Journal. Ett antal artiklar om SOA: Autonomous Services and Enterprise Entity Aggregation Data Replication as an Enterprise SOA Antipattern Using Events in Highly Distributed Architectures Event-Driven Architecture: SOA Through the Looking Glass V. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, Nick Rozanski, VI. Architectural Blueprints The 4+1 View Model of Software Architecture, Philippe Kruchten, VII. REST In Practice, Jim Webber, Savas Parastatidis, Ian Robinson Förkortningar Förkortning Beskrivning ETL Extract, Transform, Load. Extrahera data från en eller flera källor, transformera och ladda, (t.ex. till en databas). MoM Message-oriented Middleware
7 B Sehlberg, J Stenberg, M Berglund Sida: 7 (45) NyA REST WS SMS-OTP SAML SSO IFK Nya Antagningssystemet Representational State Transfer Web Services Short Message Service One-time password Security Assertion Markup Language Single Sign-on, är en metod inom sammansatta datasystem för dess användare endast ska behöva logga in en enda gång för att nå de system som är anpassade till tjänsten. Icke-funktionella krav 1.6 Definitioner och centrala begrepp Definition Applikation Komponent Modul Tjänst Beskrivning En applikation är ett program utformat för att utföra en viss funktion direkt för användaren eller i vissa fall, till ett annat program. Är en enhet med en sammanhållen del verksamhetslogik. En komponent kan jämföras med en ljudanläggning uppbyggd av enskilda delar (komponenter) som, radio, förstärkare, etc. En större komponent kan i sig innehålla mindre komponenter. I detta dokument ser vi komponent och modul som samma begrepp. Är en autonom enhet som ansvarar för en sammanhållen del av verksamhetslogik och som exponerar funktionaliteten genom utbytande av meddelanden. 1.7 Styrande effektmål Arbetet med arkitekturen präglas av de effektmål och motsvarande direktiv, som finns satta för Ladok3 projektet. Effektmål 6 Flexibilitet Högskolorna får ett hållbart och flexibelt systemstöd, med en struktur som är generellt användbar med avseende på t ex utbildningsnivåer, valutor, periodbegrepp och ursprungsländer, och som byggs i en långsiktigt hållbar teknik med lång återstående livslängd vilket gör att investeringen kan nyttjas under längre tid än den ekonomiska avskrivningstiden Effektmål 7 Användbarhet Högskolorna får ett systemstöd som upplevs som användbart, lättarbetat, tilltalande och hjälpsamt samt möjliggör minimerad pappershantering; och som är stabilt genom att det utgår från grundläggande processer i kärnverksamheten och är enkelt och väldokumenterat. Effektmål 1 Förbättrad kommunikation Högskolorna får en gemensam plattform som snabbt och allsidigt kommunicerar med alla omgivande informationssystem av intresse och vid behov kan dela data med dessa, samt med andra högskolor, både nationellt och internationellt. Effektmål 4 Lokal kostnadseffektivitet Högskolorna har tillgång till ett systemstöd som ger möjlighet till rationalisering och lägre totala system-kostnader för hela den lokala studieadministrationen, jämfört med 2010 Effektmål 3 Gemensam kostnadseffektivitet Konsortiet får ökad kostnadseffektivitet för såväl systemutveckling som systemunderhåll, jämfört med 2010
8 B Sehlberg, J Stenberg, M Berglund Sida: 8 (45) Effektmål 2 Tillgänglighet och autentisering Högskolorna har tillgång till Ladokuppgifter 24/7 genom smidig och säker identitetshantering som underlättar studentmobilitet och möjliggör egenrapportering Effektmål 5 Tillförlitlighet och säkerhet Högskolorna får, jämfört med 2010, högre tillförlitlighet i applikation och data, minimerat antal fel, möjlighet att dela särskiljbara data mellan högskolor i ett systemstöd som uppfyller högskolans ökande krav på IT-säkerhet Dessa effektmål styrs av följande direktiv: Ladok3 ska byggas med sikte på kostnadseffektivitet i såväl vidareutveckling som systemunderhåll. Utvecklingen av Ladok3 ska söka optimala kombinationer av alternativen att bygga i egen regi, att bygga tillsammans med andra aktörer eller att köpa färdiga moduler. Ladok3 ska ge förutsättningar för enklare och därmed billigare hantering på högskolan vid mottagande av nya versioner, installation etc. Ladok3 ska ge Konsortiets medlemmar bättre förutsättningar att lokalt rationalisera och optimera det totala systemstödet. Systemlösningen ska möjliggöra för Konsortiets medlemmar att effektivt dela data och särskilja data i gemensamma installationer. Ladok3 ska byggas med generella och effektiva kommunikationsgränssnitt mot andra system. Det ska vara möjligt och realistiskt att byta ut enskilda systemdelar utan stora anpassningar i övriga delar av systemet. Ladok3 ska byggas med teknik som bedöms ha mycket lång återstående livslängd och som ger låga risker för inlåsning. Systemarkitekturen ska utgå från processerna i kärnverksamheten. Projektet ska, med utgångspunkt i processanalys och med beaktande av högskolornas lokala förutsättningar och behov, söka effektiva lösningar med god gemensam acceptans. 1.8 Övriga förutsättningar Arkitekturen Ladok3 ska vara tjänsteorienterad, baserat på rapport [ref. 1]. Autentisering är inte en del av Ladok3, men Ladok3 ska kunna använda de autentiseringslösningar som används inom universitets- och högskolevärlden. Auktorisering baseras på roller och hanteras primärt av respektive lärosäte. I de fall dessa inte har möjlighet till detta kan auktorisation göras i Ladok3. Hantering av skyddad identitet. Formen för dokumentet styrs av standarden IEEE Förberett för molnet krav från styrgrupp. Nationell installation beslut från expertgrupp.
9 B Sehlberg, J Stenberg, M Berglund Sida: 9 (45) 2 Sammanfattning Dokumentet beskriver arkitekturen för ett helt nytt Ladok3, som inte bygger vidare på nuvarande Ladok. Ladok3 beskrivs utifrån en tjänsteorienterad arkitektur bestående av dels gemensam kärnfunktionalitet, dels funktionalitet som kan styras av respektive lärosäte. Funktionaliteten tillhandahålls av ett antal verksamhetstjänster och är åtkomlig via ett webbaserat gränssnitt för användare och ett tjänstegränssnitt för exempelvis högskolornas egna system. Den tjänsteorienterade och moduluppbyggda arkitekturen ger en flexibilitet som minskar förvaltningskostnader och möjliggör enklare framtida förändringar. Genom att använda autonoma tjänster får man även en lösning med hög tillgänglighet och robusthet. Den valda arkitekturen ger även bra grund för drift i molntjänst. 2.1 Fördelar Fördelen med att utveckla ett helt nytt Ladok3 jämfört med refaktorisering av befintligt Ladok, är framförallt: Att Ladok kan byggas som ett nationellt system. Att Ladok kan optimeras för de krav och behov som finns. Kompromisser som rör krav och funktionalitet på grund av begränsningar i ett befintligt system inte behöver göras. Att arkitekturen kan utformas och implementationen göras efter de bästa principer och metoder som finns idag för att få ett system som effektivt kan anpassas till framtida behov, utan att kompromissa och ta hänsyn till det befintliga Ladok. Moderna verktyg för utveckling och test kan användas som ger en mer effektiv och säkrare utveckling, sannolikt med färre fel. Med inkrementell och iterativ utveckling kan progressen enkelt följas upp och anpassa efter förändringar. 2.2 Nackdelar Nackdelar med att utveckla ett helt nytt Ladok3, jämfört med främst refaktorisering: Systemet kan troligen inte levereras till produktion med delfunktionalitet i många små steg, på grund av omfattande beroenden till gamla Ladok. Istället kommer man att behöva leverera i ett fåtal större leveranser alternativt i form av en stor. Om projektet avbryts av någon anledning, kan det (beroende på var i projektet det sker) vara svårt att enkelt dra nytta av de nya delarna. Det är svårt att ur ett kravperspektiv specificera ett komplett system. Risken finns att väsentliga delar saknas vid planeringen. 2.3 Risker De största riskerna ser vi i: Att krav inte konkretiseras och detaljeras i detalj i den fart som utvecklingsteamen behöver Att högskolorna inte kan enas om funktionalitet och krav. Att krav saknas på funktionalitet som finns idag. Att utvecklingsprojektet inte har de detaljerade kraven när implementation ska göras. Att ett utvecklingsteam inte har tillgång till en produktägare eller inte får svar på frågor, (till exempel för att det finns 37 högskolor som en produktägare måste stämma av med). Att ett utvecklingsteam inte har den kompetens som krävs.
10 B Sehlberg, J Stenberg, M Berglund Sida: 10 (45) 3 Arkitekturella mål 3.1 Vision Den övergripande visionen för Ladok3 är att skapa ett nationellt studieadministrativt system som är komplett och nyckelfärdigt i sitt utförande men med möjligheten att skapa lokala ersättningar till vissa delar. Systemet skall vara webbaserat och fokuserat på självservice och möjliggöra drift i molntjänst. 3.2 Icke-funktionella krav Nedanstående icke-funktionella krav är ett urval, av de totala icke-funktionella kraven, som kan ha påverkan på arkitekturen. Målet med arkitekturen är därför att dessa krav ska uppfyllas. Eftersom inte alla detaljer kring de icke-funktionella kraven för Ladok 3 är helt utredda, kan nedanstående lista komma att förändras något Prestanda PRE-04 Antalet studenter och lärare: Systemet skall initialt vara dimensionerat för aktiva lärare och studenter på helårsbasis, men skall kunna dimensioneras upp när ökat behov uppstår. PRE-05 Antalet expertanvändare (administrativ personal): Systemet skall vara dimensionerat för 7000 expertanvändare, dvs. användare som inte är studenter. De centrala och oftast använda delarna av systemet får ta maximalt 0,9s från det att förfrågan inkommer till systemet till motsvarande svar returneras från systemet. Systemet skall klara av min sökningar/timme under bråd timme. Systemet skall klara av min registreringar/timme under bråd timme. (Bakgrunden till dessa två krav baseras på erfarenheter från NyA, där man har c:a sökningar per bråd timme. Behoven i Ladok är mer väldefinierade när det gäller sökning, man vet mer om vilken information man söker och har därmed inte samma behov av omfattande sökningar. Antal registreringar kommer att vara avsevärt färre än antal sökningar.) Tillgänglighet TIL-01 Tillgänglighet: Systemet skall vara tillgängligt 24 timmar om dygnet 7 dagar i veckan. Totala tillgängligheten skall vara 99 % över tid respektive 99,9% kontorstid, inkluderat både planerade och oplanerade avbrott. Detta medför att systemet sammanlagt får vara otillgängligt 87,6 timmar per år Förvaltning DES Ett driftställe. Systemet skall ha ett driftställe. DES Nationell installation. Alla lärosäten skall använda samma nationella installation av systemet. Det skall inte finnas några parallella instanser av systemet, annat än i lastdelnings- eller redundanssyfte. DES Lärosätesanpassade moduler. Det skall vara möjligt att lägga till/ersätta moduler med lärosätesanpassade moduler utifrån varje lärosätes behov. DES Gemensam kärna med fristående moduler. Systemet skall bestå av en solid kärna som kan utvidgas med moduler för specifika ändamål. DES Tjänstebaserad arkitektur. Systemet skall bygga på en tjänsteorienterad arkitektur. DES Designprincip: Systemet skall ha en minimalistisk teknisk design. DDB-02 En central databas för alla högskolor: Alla högskolor anslutna till Ladok3 skall använda samma databas. DDB-07 Ingen access till databasen via SQL: All interaktion med databasen skall ske via särskilda gränssnitt och inte via SQL-access.
11 B Sehlberg, J Stenberg, M Berglund Sida: 11 (45) DDB-04 Central data skall delas mellan alla högskolor. För att underlätta underhåll av data skall data som delas mellan högskolor representeras på ett ställe. Exempel på sådana data är personuppgifter och adressuppgifter. UND Ingen duplicering av logik: En förändring av en affärsregel skall endast innebära ändring på ett ställe i systemet. UND Framtidsäker teknik: Systemet skall byggas i en teknik som är hållbar över tid och har lång återstående livslängd. Arkitekturen skall vara förberedd för ny teknik. UND Partiell installation: Systemets delar skall kunna uppdateras var för sig utan att hela systemet behöver göras otillgängligt under uppgraderingen av respektive del Säkerhet DES Säkerhet: Att förlägga en del av systemet i molnet skall inte göra systemet mindre säkert. SAK En identitet: Alla användare i systemet skall ha endast en identitet. SAK En identitet oavsett lärosäte: Varje användare skall ha endast en identitet oavsett lärosäte. SAK Stark identitet: Autentiseringen i systemet skall ske med mer än bara ett användarnamn och ett lösenord. SAK Certifikatbaserad identitet: Användarens identitet skall vara certifikatbaserad. SAK-03 Autentisering NyA: Autentisering skall kunna ske via NyA. SAK-04 Extern autentiseringsmodul: Autentiseringsfunktionen skall vara en fristående modul som möjliggör både utnyttjande av extern autentisering samt intern. SAK-05 Källsystem för behörighetssystem: Systemet skall exponera sådan information att behörighetssystemen kan hantera uppgifter om studenternas behörigheter utifrån de aktiviteter de deltar i. SAK-09 Spårbarhet: De ändringar som göra i systemet av användare skall vara tydligt spårbara och ändringarna skall vara tillgängliga via webbgränssnitt för effektiv spårbarhet. SAK-26 Extern behörighetskontroll: Behörighetskontroll skall kunna ske externt utanför systemet. SAK-10 Databastillgång för skrivning: Inga applikationer utanför systemet skall ha direkt tillgång till databasen för skrivning. SAK-15 Separering av arkivdata: Arkiven för arkivering skall avskiljas från övrigt i systemet för att undvika oavsiktlig förvanskning av uppgifter. SAK-26 Extern behörighetskontroll: Behörighetskontroll skall kunna ske externt utanför systemet Skalbarhet Den använda arkitekturen ska tillåta att Ladok3 kan skalas upp (och ner) för att kunna stödja de prestandakrav som satts i Övriga krav INT Informationsutbyte: Ifall information om eller för en student som behövs i systemet redan finns i ett externt system skall det finnas möjlighet att den informationen inhämtas där istället för att behöva anges i systemet. INT SCB, CSN: Systemet skall tillhandahålla och leverera underlag för statistik till SCB samt automatiskt överföra uppgifter om registreringar och resultat till CSN. INT Andra myndigheter: Andra myndigheters behov av intyg ifrån systemet skall hanteras med självbetjäning och andra tekniker á la Ladok Ping. INT-10 Standardiserade gränssnitt: Systemet skall använda standardiserade gränssnitt mot andra system som skall utbyta information med systemet. INT meddelandebaserat. Systemet skall ge lärosätena möjlighet att arbeta med meddelandebaserade tjänster.
12 B Sehlberg, J Stenberg, M Berglund Sida: 12 (45) 3.3 Effektmål Nedanstående tolkning av effektmålen baseras på hur dessa påverkar arkitekturen, d v s tolkningen är inte gjord utifrån hela Ladok3 projektet Effektmål 6 Flexibilitet Tolkning: De olika lärosätenas individuella behov ska kunna hanteras av Ladok3 utan krav på lokala specialanpassningar i de centrala delarna av Ladok3 (Ladok kärna). De gränssnitt som tillhandahålls ska täcka de behov, som de individuella lärosätena har för sin verksamhet. Utökningar och förändringar i en modul ska kunna göras utan risk för påverkan på andra delar i systemet. Individuella tjänster i Ladok3 ska kunna bytas ut utan krav på ny leverans av övriga delar av Ladok3. Arkitekturstöd: Tjänsteorienterad arkitektur, möjliggör ändring/utbyte av tjänster med minimal påverkan på omgivande tjänster. Lokala kopplingar kan dock påverkas. Uppdelning på olika funktionella moduler för olika ändamål, tillåter förändring med minimal påverkan på omgivningen. Meddelandebaserat informationsutbyte, möjliggör en distribuerad datalagring och ger därmed ett mer robust system. Stabila, versionshanterade tjänstegränssnitt, som kan användas för lokala anpassningar Effektmål 7 Användbarhet Tolkning: Självservice, studenten i centrum. Hindra inte utan ge stöd åt användaren. Involvera användarna i utvecklingen. Användbarhetsdesign viktig del i utvecklingen. Arkitekturstöd: En nationell installation ger bra förutsättningar för studenten i centrum. Möjliggöra lokala anpassningar för lärosätesspecifika behov. Gemensamma tjänster kan utvecklas med hög användbarhet, beroende på prioriteringar Effektmål 1 Förbättrad kommunikation Tolkning: Gränssnitt ska vara anpassade för verksamheten, se även Effektmål 7 Användbarhet, d v s gränssnitten ska vara anpassade efter verksamhetens behov. Viktigt att involvera lärosätena för att få med deras behov i gränssnitten. Etablerade och relevanta standards ska användas. Arkitekturstöd: Meddelandebaserat informationsutbyte, möjliggör en distribuerad datalagring och ger därmed ett robust system. Stabila, versionshanterade tjänstegränssnitt, som kan användas för lokala anpassningar Effektmål 4 Lokal kostnadseffektivitet Tolkning: Se Effektmål 1 Förbättrad kommunikation se Effektmål 6 Flexibilitet Arkitekturstöd:
13 B Sehlberg, J Stenberg, M Berglund Sida: 13 (45) Se Arkitekturstöd under Effektmål 1 Förbättrad kommunikation Se Arkitekturstöd under Effektmål 6 Flexibilitet Effektmål 3 Gemensam kostnadseffektivitet Tolkning: Gemensam nationell installation. Enklare förvaltning uppgradering med nationell installation. Modularitet förenklar förvaltning, t ex utbyte av enskilda komponenter. Arkitekturstöd: Se Arkitekturstöd under Effektmål 1 Förbättrad kommunikation Se Arkitekturstöd under Effektmål 4 Lokal kostnadseffektiviteteffektmål 6 Flexibilitet Se Arkitekturstöd under Effektmål 6 Flexibilitet Effektmål 2 Tillgänglighet och autentisering Tolkning: Systemet ska vara robust och tåla störningar i olika delar med minimal påverkan på andra Tillåt alternativa lösningar för autentisering. Arkitekturstöd: Se Arkitekturstöd under Effektmål 6 Flexibilitet Se kapitel 10, Säkerhetsvy Effektmål 5 Tillförlitlighet och säkerhet Tolkning: Nya arkitekturen med robusthet i fokus. Nationell gemensam lösning ger större möjlighet till att dela särskiljbara data mellan högskolor både för student och administration Autonoma tjänster och distribuerad datalagring Arkitekturstöd: Se kapitel 10, Säkerhetsvy.
14 B Sehlberg, J Stenberg, M Berglund Sida: 14 (45) 4 Arkitekturella principer 4.1 Viktiga grundprinciper Utifrån de krav och mål som ställs på Ladok3, speciellt övergripande krav som flexibilitet, förvaltningsbarhet, etc., är följande punkter extra viktiga grundprinciper för Ladok3:s arkitektur för att uppnå ett bra slutresultat. Tjänsteorienterad arkitektur - Tjänsteorientering möjliggör lätt föränderlig verksamhet. Verksamhetslogik och regler för ett område finns på ett ställe Autonoma tjänster - Med autonoma oberoende tjänster ökar tillförlitligheten och flexibiliteten för tjänsten. Meddelandebaserat och händelsestyrt, (Event Driven Architecture, EDA) - Ger ett flexibelt sätt att hantera förändringar av information i system. Decentraliserad data-arkitektur - Minskar beroenden till datakälla och ger därmed en robustare arkitektur. Webben som plattform - Internet har under många år i praktiken visat vara en mycket stabil och kompetent infrastruktur för kommunikation. Grunden som gjort detta möjligt är ett antal enkla protokoll och principer, dessa är även en bra plattform för distribuerade system. o REST-baserat - Fördelen med REST-baserade tjänster är bland annat enkelheten och snabbheten. Dessa grundprinciper och övriga finns beskrivna i detalj i appendix kapitel 12, sidan Standarder I största möjliga utsträckning ska Ladok 3 baseras på existerande standarder. De standarder som Ladok 3 primärt ska använda är: HTTP Hypertext Transport Protocol HTTPS Hypertext Transport Protocol Secure HTML Hypertext Markup Language (sannolikt HTML5) XML extensible Markup Language SAML Security Assertion Markup Language LDAP - Lightweight Directory Access Protocol Atom för publicering/distribution av meddelanden (RFC 4287 och RFC 5023) WCAG Web Content Accessibility Användargränssnittdelines European Interoperability Framework for Pan-European egoverment Services (EIF 1.0) EMIL - Education Information Markup Language eduperson - LDAP-schema för att beskriva person attribut inom högskole- och universitetsområdet. eduorg - LDAP-schema för att beskriva organisatoriska attribut inom högskole- och universitetsområdet. Ytterligare standarder kan bli aktuella i samband med realiseringen av systemet. Exempel på områden där nya standarder kan bli aktuella, är vid integration mot de lokala systemen på lärosätena, exempelvis för det som beskrivs som Lokala anpassningar i detta dokument. Andra områden är integration för nationell lösning för e-legitimation och andra två-faktorslösningar, som kan bli aktuella.
15 B Sehlberg, J Stenberg, M Berglund Sida: 15 (45) 5 Logisk vy 5.1 Övergripande arkitektur Ett viktigt krav för Ladok3 är att reducera kostnaderna. Genom att utveckla Ladok3 som ett nationellt centralt system med bra möjligheter att integrera mot lokala system och externa system (se även IFK i kapitel 3.2.3), finns potential för att kostnaden för drift och förvaltning kan minskas. Ladok3 är uppdelat i grundtjänster (Ladok kärna) och utbytbara tjänster (Ladok Referens), samt integrationer (Ladok Integration). Figur 1: Ladok3 i kontext Ladok kärna innefattar de centrala grundläggande gemensamma funktionerna i Ladok. Ladok Referens är tjänster som ingår i Ladok3, men kan i de fall man vill ha en egen lösning ersättas av motsvarande tjänster hos respektive lärosäte. En förutsättning för detta är då att denna lokala lösning använder motsvarande tjänstegränssnitt som den inbyggda tjänsten använder mot Ladok kärna. Via olika integrationer i Ladok Integration kan Ladok3 utbyta information med andra externa aktörer (t ex CSN, SCB). Integrationerna i Ladok Integration använder främst Core Services, men kan i undantagsfall använda sig av andra gränssnitt för vissa specialändamål. Vilken typ av integration, som används beror till stor del på de anslutande systemens möjligheter. Genom den tjänsteorienterade och moduluppbyggda arkitekturen får man en flexibel lösning som minimerar förvaltningskostnader och möjliggör enklare framtida förändringar, genom att möjliggöra uppdatering av enskilda delar utan att resten påverkas. 5.2 Ladok3 som molntjänst Den valda arkitekturen ger även möjlighet till drift av Ladok3 som molntjänst, men är inte direkt anpassad för någon specifik molntjänst. Det betyder däremot inte att Ladok3 har fullt stöd för alla typer av molntjänster. Beroende på vilken molntjänst man eventuellt väljer i framtiden och hur man vill använda denna, finns det ett antal olika områden man kan behöva ta hänsyn till och även då anpassa för. Nedanstående kapitel exemplifierar några specifika områden, som bör beaktas, dessa är: Lagringsteknik Meddelandehantering
16 B Sehlberg, J Stenberg, M Berglund Sida: 16 (45) Integration med andra system lokala och externa Autentisering/auktorisering Lagringsteknik De olika molnplattformarna har olika lösningar för datalagring med olika för och nackdelar. Exempelvis Google APP Engines data store är ingen relationsdatabas (och använder därmed inte SQL), utan lagrar informationen som objekt (entiteter), med en eller flera egenskaper. Fördelen med denna typ av databas är bland annat skalningsmöjligheten och lagringssäkerheten. På motsvarande sätt har Amazon i sin molntjänst olika typer av lagringslösningar med olika användningsområden. Det är därför nödvändigt säkerställa att all åtkomst till databaser kapslas in för att göra applikationen oberoende av plattformen. Samtidigt riskerar man ett visst porteringsarbete vid byte av molnleverantör med annan datalagringslösning Meddelandehantering Även för meddelandehantering finns olika tekniklösningar beroende på plattform och vilken funktionalitet man vill använda. Det är även här nödvändigt att säkerställa att man inte skapar onödiga beroenden till den använda plattformen Integration med andra system (lokala och externa) Eftersom molnleverantörerna normalt endast tillåter kommunikation över http/https, finns vissa begränsningar i hur man kan integrera sig med molntjänsten, vilken lösning som används är ofta beroende på leverantör. Google tillhandahåller t ex ett eget API (Channel API) för kommunikation med kundens lokala system. Amazon använder en teknik Virtual Private Cloud (VPC) för att skapa ett virtuellt nätverk mellan molntjänsten och den lokala miljön Autentisering/auktorisering Vilken autentiseringsmekanism som kan användas styrs också i hög grad av molnleverantören och vald plattform. Google använder exempelvis vanliga Google konton, men kan också använda OpenID identifierare. Däremot finns inget direkt stöd för behörighet. Microsoft Azure har exempelvis möjlighet till integration med AD. 5.3 Grundfunktionalitet i Ladok Enligt IFK i kapitel skall Ladok3 vara tjänsteorienterat. Följande bild visar en logisk modell över Ladok3 och dess ingående tjänster, samt hur systemet exponerar den interna grundfunktionaliteten i Ladok kärna via webbgränssnitt och även via tjänstegränssnitt, Core Services. Via tjänstegränssnitten kan andra system komma åt de olika tjänsterna i Ladok, t ex tjänster i Lokala anpassningar. Då det för närvarande inte har identifierats något behov av överordnat arbetsflöde i den övergripande arkitekturen finns inte något stöd för workflow med i arkitekturen. Skulle det visa sig finnas ett sådant behov i realiseringsfasen kommer detta då att beaktas. De regler som behövs är ganska statiska jämfört med t ex NyA, varför en generell regelmotor inte ansetts nödvändig. De affärsregler som behövs är därför inbyggda i respektive tjänst, d v s det finns ingen separat regelmotor för detta utan varje domän ansvarar för sina regler.
17 B Sehlberg, J Stenberg, M Berglund Sida: 17 (45) Figur 2: Övergripande moduler Med början i den övre delen av figuren, finns ett inbyggt användargränssnitt Ladok användargränssnitt som används av både administrativ personal och studenter. Ladok kärna innefattar de centrala gemensamma funktionerna i Ladok. Ladok Referens innefattar en uppsättning utbytbara standardtjänster. Ladok Integration används vid integration mot externa aktörer. Lokala anpassningar är inte en del av Ladok3, men kan innefatta tjänster som de lokala lärosätena vill använda istället för motsvarande i Ladok Referens Ladok användargränssnitt Ladok användargränssnitt tillhandahåller ett gemensamt användargränssnitt för Ladok kärna och Ladok Referens. Ladok användargränssnitt kan användas nyckelfärdigt, anpassat med avseende på logotype, färgsättning och viss placering med hjälp av style sheet (CSS). Det finns några principiella sätt att hantera användargränssnittet: Lärosätet har inga egna anpassningar (förutom logotyp och färgval) utan använder Ladok och Ladok användargränssnitt som ett nyckelfärdigt system Lärosätet använder inte Ladok användargränssnitt utan har ett helt eget användargränssnitt, som använder Core Services och motsvarande i Ladok Referens. Lärosätet använder en del av Ladok användargränssnitt, för Core Services och Ladok Referens men har även ett eget användargränssnitt med egna anpassningar, för t ex Lokala anpassningar, eller anpassade tjänster i Ladoks kärna. Integration av egna utökningar, kräver även att man säkerställer att dessa utökningar även kan hantera single sign-on, lämpligen med SAML 2.
18 B Sehlberg, J Stenberg, M Berglund Sida: 18 (45) Ladok3 tillhandahåller ett eget inbyggt användargränssnitt för Ladok Kärna och Ladok Referens. Används detta användargränssnitt kan man som användare dels komma åt olika delar i systemet via menysystemet, men också enkelt komma åt olika information och funktioner via vanliga hyperlänkar. Exempelvis skulle man kunna tänka sig att via kurs hitta ett kurstillfälle, för att därifrån kunna se vilka studenter som finns registrerade och via en student kunna se vilka andra kurser denne är registrerad på, etc. Nedanstående figurer visar en konceptuell bild av detta d v s layouten exemplifierar endast förhållandet mellan användargränssnitt och Ladok kärna och Ladok Referens. Den slutgiltiga layouten är något som hanteras i utvecklingsprojektet. Figur 3: Nyckelfärdigt Ladok användargränssnitt De lärosäten som har andra krav än vad som kan tillhandahållas i Ladok användargränssnitt kan antingen utveckla ett helt eget användargränssnitt, genom att använda de tillgängliga tjänstegränssnitten i Ladok kärna och Ladok Referens eller från eget användargränssnitt länka in fristående delar av Ladok användargränssnitt (exempelvis från Ladok Referens). Figur 4: Eget användargränssnitt istället för Ladok användargränssnitt Ladok kärna Ladok kärna innefattar de grundläggande centrala funktionerna i Ladok:
19 B Sehlberg, J Stenberg, M Berglund Sida: 19 (45) Core Services Tjänstegränssnitt för Ladok3. Studiedeltagande Ansvarar för information om alla typer av deltaganderegistreringar. Studieresultat Ansvarar för information om resultat på tentamen, kurser och motsvarande samt examen. Kataloguppgifter Ansvarar för registrering och hantering av examensdefinitioner, provuppsättningar, organisationsstruktur på den egna lärosätet, etc. Även gemensamma standarduppgifter, som t ex kommunnamn och länder hanteras här. Hantera utbildningsutbud Ansvarar för registrering och lagring av information om kurser, kurstillfällen, program och examina. Tar emot information från bland annat Utbildningsdatabas. Student Ansvarar för registrering och lagring av information om student Spårbarhetslogg (infratjänster) Lagrar en logg över alla händelser i systemet. Enskilda tjänster kan uppgraderas eller bytas ut utan krav på att övriga delar måste bytas ut eller uppgraderas samtidigt. De tjänstegränssnitt som dessa tjänster tillhandahåller är i möjligaste mån bakåtkompatibla. Vid större förändringar kan nya kompletterande tjänstegränssnitt skapas och gamla versioner av dessa kan senare fasas ut enligt uppgjorda planer. Även enskilda moduler ska kunna bytas ut utan krav på att övriga delar måste bytas ut/uppgraderas Ladok Referens De tjänster som inte har samma nära koppling till de funktioner som finns i Ladok kärna, läggs i Ladok Referens. Ladok Referens innefattar därför en uppsättning standardtjänster, t.ex. en funktion för att registrera utbildningsinformation. Lärosäten kan välja att använda den inbyggda funktionen för att registrera utbildningsinformation eller att använda en egen lokal utbildningsdatabas, som då kommunicerar via Core Services. Enligt IFK ska det vara möjligt att använda olika autentiseringsmetoder, därför innefattar Ladok Referens även autentisering och auktorisering, vilket ger möjlighet att använda olika typer av externa mekanismer för detta, exempelvis: Referens Services Tjänstegränssnitt för de tjänster som finns i Ladok referens. Hantera Utbildningsutbud Ansvarar för att skapa information om kursutbudet och kurstillfällen Anmälan till examination Ansvarar för att hantera examinationstillfällen och anmälan till dessa. Autentisering (infratjänster) Ansvarar för att antingen kommunicera med eget lärosäte för autentiseringsinformation eller den inbyggda identitetsutfärdaren beroende på konfiguration. Auktorisering (infratjänster) Ansvarar för att antingen kommunicera med eget lärosäte för rollinformation eller den inbyggda katalogen.
20 B Sehlberg, J Stenberg, M Berglund Sida: 20 (45) Enligt de icke-funktionella kraven skall Ladok3 kunna anpassas till lokala processer. Ladok3 är i grunden ett centralt system med kompletta tjänster, men tillåter att ett lärosäte väljer att ersätta vissa moduler med sin egen lösning. Dessa utbytbara moduler kallas tillsammans Ladok Referens. För att detta skall vara möjligt krävs att Ladok3 tillhandahåller ett väldefinierat tjänstegränssnitt, med stöd för dessa anpassningar. En viktig grundprincip för en modul i Ladok Referens är att den kan fungera som en fristående applikation/funktion. Ladok kärna får inte ha något beroende till modulen i Ladok Referens. En modul i Ladok Referens kan däremot ha ett beroende till Ladok kärna (t ex för att hämta vissa grunduppgifter för sin egen hantering). Ett exempel kan vara den inbyggda tjänsten för att hantera utbildningsutbud (t ex utbildningstillfällen) i Ladok3 som tillhör Ladok Referens. Hantera utbildningsutbud använder motsvarande tjänst (Utbildningsutbud) i Ladok kärna. Om ett lärosäte vill använda sin egen lösning för att hantera utbildningsutbud, finns det ett tydligt tjänstegränssnitt och en inställning som kopplar bort den inbyggda modulen. Figur 5: Användning av Ladok Referens Funktionaliteten i Ladok Referens visas normalt sett i Ladok användargränssnitt, men för de som har valt att använda sin egen implementation försvinner de menyalternativen och liknande representationer och får därmed ersättas av den egna lösningens motsvarigheter. Dessa implementationer måste därför tillhandahålla sitt eget användargränssnitt. En fördel med en egen lösning är att man t ex kan tillhandahålla specialanpassningar för sitt eget lärosäte. I vissa undantagsfall kan det, för ett lärosäte, finnas behov av att utöka funktionaliteten i Ladoks kärna på ett sätt som inte är kompatibelt med andra lärosäten. Ett exempel skulle kunna vara ett lärosäte som behöver en utökad funktion med tillhörande extra information för en tjänst. Anpassningen hanteras då genom att systemet kan känna av att användaren kommer från ett lärosäte med en anpassad tjänst, med tillhörande anpassat användargränssnitt. Systemet dirigerar användaren till det anpassade användargränssnittet för de delar, som använder den anpassade tjänsten.
21 B Sehlberg, J Stenberg, M Berglund Sida: 21 (45) Figur 6: Anpassade tjänster För att den anpassade tjänsten ska kunna samexistera med övriga tjänster, krävs det att de grundfunktioner den ordinarie tjänsten har även används av den anpassade tjänsten. De anpassade tjänsterna ska naturligtvis också följa de arkitekturella principerna som är beskrivna i kapitlet Grundprinciper Ladok Integration För att kommunicera med externa parter såsom CSN, SCB och NyA, används Ladok Integration. I Ladok Integration placeras olika adaptrar för integration mot externa aktörer. Ladok Integration använder sig av Core Services i Ladok kärna för att hämta och lämna data, samt den händelsestyrda arkitekturen i Ladok3. För de system, som inte har stöd för detta kan man ta fram olika typer av adaptrar, som anpassar integrationstekniken till den externa parten. För mer detaljer se även kapitlen och Notera att lärosätena främst använder Core Services för att kommunicera med Ladok3 förtjänster i Lokala anpassningar Lokala Anpassningar I denna del finns alternativa lokala anpassningar, som ersätter motsvarande inbyggda moduler i Ladok Referens. I Figur 2: Övergripande moduler, har till exempel Studieplan, Hantering utbildningsutbud, Autentisering och Auktorisering ersatts av lokala anpassningar. De motsvarande inbyggda modulerna i Ladok 3 kopplas då bort. Gränssnittet länkar istället till den lokala motsvarigheten. 5.4 Tjänster och meddelanden i Ladok3 Ladok3 bygger på en tjänsteorienterad och meddelandebaserad arkitektur. Följande sektioner beskriver Ladok3 ur motsvarande perspektiv Tjänstemodell Följande figur visar möjliga viktiga verksamhetstjänster i Ladok. De visade tjänsterna ska ses som exempel och kan komma att förändras i realiseringsfasen av projektet.
22 B Sehlberg, J Stenberg, M Berglund Sida: 22 (45) Figur 7: Tjänster i Ladok3 Uppbyggnaden av tjänsterna i Ladok kärna i ovanstående figur finns beskrivet i Ladok användargränssnitt,(composite Application) Användargränssnitt för Ladok3 som innehåller två delkomponenter, Studiedeltagande och Studieresultat. Applikationen använder de två delkomponenterna för att bygga ett sammanhållet gränssnitt för användaren utan att skapa beroenden mellan de två motsvarande tjänsterna i Ladok kärna. Studiedeltagande Prenumererar på och hanterar meddelanden om antagna studenter, (meddelanden som idag kommer från NyA), och sparar antagningarna. Hanterar logik och regler för registrering av studiedeltagande, exempelvis registrering och avbrott. Exponerar ett publikt tjänstegränssnitt som kan användas av externa system, till exempel ett lärosätes egen webbplats. Publicerar meddelanden som rör studiedeltagande. Studieresultat Hanterar logik och regler för registrering av studieresultat såsom kurser, tentamen, etc. Exponerar ett publikt tjänstegränssnitt som kan användas av externa system, till exempel ett lärosätes egen webbplats. Publicerar meddelanden som rör studieresultat. Utbildningsutbud Ansvarar för att ta emot och kontrollera nya och ändrade kurser från utbildningsdatabaserna. Exponerar ett publikt tjänstegränssnitt som utbildningsdatabaserna använder för att registrera kurser. Publicerar meddelanden som rör nya och ändrade kurser Meddelandeflöde i Ladok3 Ladok3 bygger på en meddelandebaserad arkitektur (se även 14.2, respektive 15.1) vilket innebär att tjänster som ansvarar för en viss information publicerar förändringar som rör denna information (händelser som har inträffat) och att tjänster som är beroende av den informationen prenumererar på dessa meddelanden (händelser). De meddelanden som skickas ut definieras av meddelandeinterfacet i Ladok3. Endast en delmängd av alla meddelanden kommer att publiceras till externa parter. Det beror på att man vill kunna lägga på säkerhet och även kunna hålla interfacet
23 B Sehlberg, J Stenberg, M Berglund Sida: 23 (45) stabilt. Den föreslagna arkitekturen ger en lösning med hög tillgänglighet och robusthet, genom att inte skapa onödiga beroenden mellan olika delar i systemet. Följande bild visar ett exempel på hur meddelanden kan flöda mellan publicerande och konsumerande tjänster, enligt ett Publish/Subscribe-mönster, i Ladok3. För transporten av meddelanden mellan tjänsterna används en meddelandeförmedlare. Flödet kan beskrivas enligt följande: Figur 8: Meddelandeflöden i Ladok3 1. Ett utbildningstillfälle skapas och registreras i Utbildningsutbud i Ladok3 av en administratör. 2. Utbildningsutbud publicerar ett motsvarande meddelande, som NyA prenumererar på. 3. Utbildningstillfället blir tillgänglig i NyA och en student anmäler sig på kursen. 4. Studenten blir antagen i NyA, som publicerar ett meddelande som Studiedeltagande i Ladok3 prenumererar på. 5. Studenten registrerar sig på kursen mot Studiedeltagande, som publicerar en händelse om registreringen till NyA, som prenumererar på händelsen. 6. När studenten är klar med kursen går administratören in den sammansatta applikationen Registrera resultat och läser upp information om studentens kursdeltagande och registrerar resultatet i Studieresultat. 7. Studieresultat publicerar ett meddelande, som NyA prenumererar på. Meddelande mot NyA hanteras via Ladok Integration. På motsvarande sätt kan t ex ett lärosäte prenumerera på motsvarande information.
24 B Sehlberg, J Stenberg, M Berglund Sida: 24 (45) 5.5 Processer Processerna i Ladok 3 är inte inbyggda i tjänsterna, (d v s tjänsterna styr inte processen), däremot stödjer tjänsterna de olika processerna. Processflödet styrs istället av den applikation (Composite Application) som använder de enskilda tjänster. Detta förutsätter naturligtvis att inte något regelverk hindrar valet av ordning (t ex ett kurstillfälle måste finnas registrerat innan man kan registrera sig på kursen). En process kan använda en eller flera tjänster Processtjänster De processer som Ladok3 skall stödja behöver motsvarande IT-tjänster. Följande del visar exempel på två av de processer som tagits fram i projektet verksamhetskrav och hur de skulle kunna realiseras som tjänster/operationer. Modul: Studiedeltagande Nr Processnamn Tjänster/operationer Indata Utdata 35 Förstagångsregistrera på kurstillfälle 36 Registrera utresande student på utbytesperiod 39 Hantera avbrott på utbildningstillfälle 41 Registrera student på forskarnivå Skapa förstagångsregistrering Skapa registrering för utresande student Skapa avbrott på utbildningstillfälle för student Skapa registrering för student på forskarnivå 44 Omregistrera på kurs Skapa omregistrering för student på kurs 46 Hantera individuell studieplan för student på grund- och avancerad nivå 48 Automatiserad eller manuell gruppindelning 49 Stödja studiefinansiering Inte färdig Skapa individuell studieplan Uppdatera individuell studieplan Ta bort individuell studieplan Dela upp studenter inom {kurstillfälle, program, institution} i grupp Student Kurstillfälle Student Utbytesperiod Student Student Student Kurstillfälle Student Studieplan Student Kurstillfälle Program Institution Avbrott Registrering Förstagångsregistrering Bekräftelse Omregistrering Individuell studieplan Grupp 50 Hantera individuell studieplan för student på forskarnivå Skapa individuell studieplan för student på forskarnivå Uppdatera individuell studieplan för student på forskarnivå Ta bort individuell studieplan för student på forskarnivå Student 51 Hantera byte av lärosäte Byt lärosäte Student Ansökan 52 Hantera studieuppehåll Ansök om studieuppehåll Bevilja studieuppehåll Avslå studieuppehåll Student Ansökan Individuell studieplan Bekräftelse Bekräftelse Beslut
25 B Sehlberg, J Stenberg, M Berglund Sida: 25 (45) 53 Hantera byte av ort m.m. inom lärosäte 54 Hantera byte av program /ämne 57 Fortsättningsregistrera student på kurstillfälle Ansök om byte av kurstillfälle Bevilja byte av kurstillfälle Avslå byte av kurstillfälle Ansök om byte av {utbildningsprogram, inriktning, ämne} på forskarnivå Bevilja byte av {utbildningsprogram, inriktning, ämne} på forskarnivå Avslå byte av {utbildningsprogram, inriktning, ämne} på forskarnivå Skapa fortsättningsregistrering Student Ansökan Student Ansökan Student Kurstillfälle Bekräftelse Beslut Bekräftelse Beslut Fortsättnings registrering Modul: Resultat Nr Processnamn Tjänster/operationer Indata Utdata 79 Sammanställa underlag för betygssättning 80 Göra bedömning och sätta betyg 81 Dokumentera resultat/tillgodoräknande 82 Offentliggöra resultat/tillgodoräknande 83 Göra en ansökan om tillgodoräknande 84 Bedöma och granska meriter Inget IT-stöd Skapa underlag Studenter Prestationer Underlag Betygssätt Underlag Arkivlista Prestation Fastställ resultat Arkivlista Fastställd arkivlista Offentliggöra resultat Student Resultat Resultat Ansök om tillgodoräknande Student Bekräftelse Ansökan 85 Besluta om meriterna ska tillgodoräknas Godkänn tillgodoräknande Avslå tillgodoräknande Ansökan Beslut
26 B Sehlberg, J Stenberg, M Berglund Sida: 26 (45) 6 Scenariovy Scenariovyn innehåller en mindre mängd användningsfall eller scenarios för att identifiera arkitektoniska element och för att illustrera och validera arkitekturens design. De tjänar också som en utgångspunkt för test av en arkitekturprototyp, se även appendix kapitel 12. Scenariovyn kommer att beskrivas i en senare fas i realiseringsprojektet.
27 B Sehlberg, J Stenberg, M Berglund Sida: 27 (45) 7 Informationsvy 7.1 Gemensam central lösning En gemensam central lösning kan ge både förvaltningsmässiga och driftsmässiga fördelar, samtidigt ställer en sådan lösning högre krav på att informationen separeras mellan de olika lärosätena. Att separera information på olika sätt mellan olika aktörer i en molntjänst är ett vanligt behov. Beroende på vad och var man vill separera finns det olika lösningar. Det är därför viktigt att klassa den information man lagrar och hanterar, så att man får den önskade separationen, men också får fördelarna av att ha gemensam information (jämför t ex behovet av Ladok Ping). Exempelvis vill man separera de lokalt unika delarna, så att man inte har tillgång till andra lärosätens information. Samtidigt kan man mycket väl samordna annan information, som generella kataloguppgifter (kommunnamn, länder, etc.). En central gemensam lösning underlättar även för de studenter, som kanske har eller håller på att studera på flera lärosäten, genom att de kan få alla sina uppgifter samlat på ett ställe via en inloggning. Dessutom förenklas möjligheten för olika högskolor att bedriva gemensamma utbildningar. Nedanstående figurer jämför en lösning med lokala Ladok-installationer och en central gemensam lösning. Figur 9: Exempel på fysisk separering av information Dagens Ladok har en fysisk uppdelning, enligt ovanstående figur, där varje lärosäte har sin egen fysiska installation. Figur 10: Exempel på logisk separering av information Ett gemensamt centralt Ladok har istället en logisk uppdelning mellan lärosätena, enligt ovanstående figur, där varje lärosäte har sin egen logiska lokala installation. Den logiska uppdelningen görs genom att respektive lärosätes information märks med en identifierare för lärosätet. Detta används sedan av Ladoks tjänster kopplat till vem som loggar in och vilket/vilka lärosäte man tillhör. I ovanstående figur kommer alltså användare H1 endast åt information märkt H1 och gemensam information. På motsvarande sätt kommer användare H2 endast åt information märkt H2 och gemensam information. Ovanpå detta appliceras sedan behörighet till information och funktion baserat på användarens roll.
Lösningen Ladok3 - detaljerad information.» Session 2
Lösningen Ladok3 - detaljerad information» Session 2 Innehåll» Huvudprinciper» Övergripande» Tjänster» Gränssnitt och integrationer» Säkerhet» Metodik Huvudprinciper» Tjänsteorienterad arkitektur Tjänsteorientering
Gränssnitt och identiteter. - strategiska frågor inom Ladok3
- strategiska frågor inom Ladok3 Sida 2 av 9 er Revision Datum Av Kommentar Granskare Godkännare 0.1 2011-05-26 Daniel Lind Utkast 0.2 2011-05-30 Daniel Lind Synpunkter från Catherine 0.3 2011-06-16 Daniel
Ladok3 på Ladok-info /16
Ladok3 på Ladok-info 2014-10-13/16 Vad är Ladok3 (systemet)? Ladok3 är en helt ny version av Ladok-systemet (som troligen kommer att kallas Ladok, inte Ladok3) Data från dagens Ladok förs över till Ladok3
Ladok3 kickoff på LU 2013-12-05
Ladok3 kickoff på LU 2013-12-05 Ladok Ett studieadministrativt system som används av nästan alla universitet och högskolor i Sverige. Bygger bl.a. på kraven i lagen 1993:1153. Innehåller antagna (men inte
Nya Ladok. Introduktion för systemutvecklare
Nya Ladok Introduktion för systemutvecklare Varför är vi här idag? För att få en bättre förståelse för nya Ladok För att varje integration är viktig för nya Ladok Agenda 1230-1430 Överblick över det nationella
Ladok3 SA-referensgruppen
Ladok3 SA-referensgruppen 2012-11-28 Aktuell införandeplan 1. Årsredovisning (kan köras parallellt i Ladok2 och Ladok 3 - verifiering) 2. Uppföljning 3. Examen + Registrering + Resultat 4. Kataloginfo
PhenixID + Zappa. Livscykelhantering, Autentisering och Single Sign-On
PhenixID + Zappa Livscykelhantering, Autentisering och Single Sign-On ÖVERSIKT Dokumentet beskriver en IAM (Identity Access Management) lösning, vid namn Zappa, för skolor i en region som hanterar konton
Så planeras Ladok3 att fungera - i webbläsaren och i integrationer med lokala och andra system
Så planeras Ladok3 att fungera - i webbläsaren och i integrationer med lokala och andra system 2012-05-03 Catherine Zetterqvist, Matz-Ola Cajdert, Bo Sehlberg Var befinner vi oss? 2010 2011 2012 2013 2014
2. Några begrepp som används i denna
Dokument: Produktbeskivning utbildningsinformation Version 1.1 Författare Sida 1 av 7 Matz-Ola Cajdert Ladok3-projektet Datum 2014-01-07 Utbildningsinformation i Ladok3 1. Sammanfattning I detta dokument
Federerad åtkomst Information om åtkomst till Apotekens Services tjänster inom ramen för en identitetsfederation.
Federerad åtkomst Information om åtkomst till Apotekens Services tjänster inom ramen för en identitetsfederation. Datum: 2011-02-28 Version: Författare: Christina Danielsson Senast ändrad: Dokumentnamn:
Ladok3 kickoff på LU xx 06 (Hbg), 11 (Lund), 13 (Malmö)
Ladok3 kickoff på LU 2014-02-xx 06 (Hbg), 11 (Lund), 13 (Malmö) Ladok Ett studieadministrativt system som används av nästan alla universitet och högskolor i Sverige. Bygger bl.a. på kraven i Studiedokumentationsförordning
Analys av HISinOne som grund för Ladok 3
Analys av HISinOne som grund för Ladok 3 Ellen Jacobsson, Mikael Berglund Sida: 2 (12) Innehåll 1 INTRODUKTION... 4 1.1 SYFTE... 4 1.2 REFERENSER... 4 2 SAMMANFATTNING... 5 3 BAKGRUND... 6 3.1 HIS OCH
LADOKTRÄFF. KI, Stockholm
LADOKTRÄFF KI, Stockholm 2018-11-22 2 Agenda 09.00-09.30 Fika och mingel 09.30-10.45 Inledning Konsortiets strategi och styrning framåt. Mauritz Danielsson Kommande utveckling av Ladok, en ny prioriteringsgrupp
Mål och verksamhetsplan
Sida 1 av 5 Ladokstämman 2018-05-17 beslutade om Verksamhetsinriktning 2019-2021 med mål och ekonomiska ramar för 2019, som anger ramar för konsortiearbetet under 2019 och inriktningen för 2020-2021. Stämmans
Förvaltningsplan NyA 2016
Systemförvaltning och systemdrift Föredragande Anders Mobjörk Systemansvarig 010-470 06 38 anders.mobjork@uhr.se BESLUT Diarienummer 4.2.2-1263-2015 Datum 2015-12-04 Postadress Box 45093 104 30 Stockholm
Förvaltningsstrategi NyA 2015-2017
Avdelningen för systemförvaltning och systemdrift Föredragande Per Zettervall Avdelningschef 010-470 03 00 per.zettervall@uhr.se DNR 4.2.2-1048-2014 Datum 2014-06-02 Postadress Box 45093 104 30 Stockholm
JHS 179 Planering och utveckling av en övergripande arkitektur Bilaga 9. Virtualisering och molntjänster i planering av teknologiarkitektur
JHS 179 Planering och utveckling av en övergripande arkitektur Bilaga 9. Virtualisering och molntjänster i planering av teknologiarkitektur Version: 2.0 Publicerad: 7.2.2017 Giltighetstid: tills vidare
Vad är molnet?... 2. Vad är NAV i molnet?... 3. Vem passar NAV i molnet för?... 4. Fördelar med NAV i molnet... 5. Kom igång snabbt...
Produktblad för NAV i molnet Innehåll Vad är molnet?... 2 Vad är NAV i molnet?... 3 Vem passar NAV i molnet för?... 4 Fördelar med NAV i molnet... 5 Kom igång snabbt... 5 Bli kostnadseffektiv... 5 Enkelt
Förvaltningsstrategi NyA
Avdelningen för systemförvaltning och systemdrift Föredragande Per Zettervall Avdelningschef 010-470 03 00 per.zettervall@uhr.se DNR 4.2.2-554-2015 Datum 2015-06-11 Postadress Box 45093 104 30 Stockholm
Ladok3» NUAK 2013-10-08
Ladok3» NUAK 2013-10-08 Historik Ladok Classic Ladok på webb 70-tal 1996 2004 Ladok Nouveau 2 Varför Ladok3? Åldrande teknisk plattform (Uniface) Höga kostnader för förändringar Dubblerad logik Ökande
WELCOME TO. Value of IAM in Business Integrations
WELCOME TO Value of IAM in Business Integrations WELCOME TO Value of IAM Agenda Zipper Zecurity, vilka är vi? IAM, varför och vad gör det för nytta? IBM Security Identity Manager IBM Security Role & Policy
Begreppslista. Begrepp Definition Exempel/Kommentar Preliminär. En användarbehörighet är kombinationen av. någon organisation.
Begreppslista Begrepp Definition Eempel/Kommentar Preliminär Användarbehörighet En behörighetsprofil knuten till någon organisation. En användarbehörighet är kombinationen av behörighetsprofil och organisation
Lathund: Lägga upp utbildning på forskarnivå Innevarande version vid senaste uppdatering:
Lathund: Lägga upp utbildning på forskarnivå Innevarande version vid senaste uppdatering: 0.97.0 Mer information om Ladok Mer utbildningsmaterial hittar du på Ladok.se: Aktuellt utbildningsmaterial Systemdokumentationen
Daniel Akenine, Teknikchef, Microsoft Sverige
Daniel Akenine, Teknikchef, Microsoft Sverige Quincy Invånare: 5,300 Arbete: 52% jordbruk 18 % byggsektor 18 % offentlig sektor Språk: Spanska 57% Företaget Inköp Företaget Inköp Installering Lång
Utfärdat av Revideringsdatum Dokument ID Håkan Tropp Systembeskrivning_Kursinfo.doc
SYSTEMBESKRIVNING 2005-12-22 1.0 1 (7) Kursinfo Översiktlig beskrivning Kursinfo är ett egenutvecklat system, för att hantera utbildningsrelaterad information. I Kursinfo hanteras all administration av
Instruktion för integration mot CAS
IT-enheten Instruktion för integration mot CAS Per Hörnblad Instruktion 2010-10-29 Sid 1 (7) Instruktion för integration mot CAS Projektnamn Instruktioner för Integration mot CAS Fastställt av Per Hörnblad
Ladok3 på Ladok-info
Ladok3 på Ladok-info 2016-10-27 Vad är Ladok3 (systemet)? Ladok3 är en helt ny version av Ladok-systemet (som kommer att kallas Ladok, inte Ladok3 när det väl är driftsatt) Data från dagens Ladok förs
Införande av en integrationsplattform med Apache Service Mix på LTU
Införande av en integrationsplattform med Apache Service Mix på LTU Apache Service Mix = Opensource java teknologier + Prenumerationer och Support = Red Hat JBoss Fuse Bakgrund 2012/2013 - Arbetsgruppen
Resultathantering i Ladok3.» Ladok-inkubator» Ola Ljungkrona
Resultathantering i Ladok3» Ladok-inkubator» Ola Ljungkrona Innehåll» Varför resultatleverans Vilka möjligheter ger det lärosätena, ladok3- projektet» Hur - Ladok3 funktionalitet mot befintlig Ladokdatabas»
PO_Lista_Icke-funktionella krav Ladoksystemet
Ola Ljungkrona/Bo Sehlberg Sida: 1 (13) PO_Lista_Icke-funktionella krav Ladoksystemet Ola Ljungkrona/Bo Sehlberg Sida: 2 (13) Innehållsförteckning 1 Inledning... 3 2 Icke-funktionella krav... 6 2.1 Användbarhet...
Paketerad med erfarenhet. Tillgänglig för alla.
En enkel tjänst för sammanhållen hantering av anställdas och elevers användarkonton, inloggning och behörigheter. Paketerad med erfarenhet. Tillgänglig för alla. Personer kommer och personer går. Digitala
Handhavandeguide: Utbildning på forskarnivå Innevarande version vid senaste uppdatering:
Handhavandeguide: Utbildning på forskarnivå Innevarande version vid senaste uppdatering: 1.10.0 Mer information om Ladok Mer utbildningsmaterial hittar du på Ladok.se: Aktuellt utbildningsmaterial Systemdokumentationen
ATT ARBETA MED STUDENTER I LADOK3 GRUND OCH AVANCERAD NIVÅ
2018-03-13 ATT ARBETA MED STUDENTER I LADOK3 GRUND OCH AVANCERAD NIVÅ MARIA EINLER, UTBILDNINGSENHETEN 1 Innehåll Samma slags studentdokumentation... 4 Ladok3 nytt sätt att arbeta... 5 Nya begrepp... 6
Referensarkitektur för U/H. Ola Ljungkrona Chalmers Per Hörnblad UmU
Referensarkitektur för U/H Ola Ljungkrona Chalmers Per Hörnblad UmU 1 Agenda ATI Nationell nätverk för Arkitektur och Teknisk integration Bakgrund referensarkitektur Referensarkitektur Innehåll Principer
Klient/server. Översikt. Lektion 1: Webbtekniker från Microsoft. Webbteknik från Microsoft. Klient/server. Designmönster. Utrullning.
Klient/server Översikt Webbteknik från Microsoft. Klient/server. Designmönster. Utrullning. Lektion 1: Webbtekniker från Microsoft Microsoft webbtekniker. ASP.NET. Klientsidan. Internet Information Server.
LADOK3 DOMÄNMODELLER. SUNET-veckan, , KTH Mikael Berglund, ITS, Umeå Universitet
LADOK3 DOMÄNMODELLER SUNET-veckan, 2017-10-18, KTH Mikael Berglund, ITS, Umeå Universitet 2 3 4 5 6 7 8 Stadsplan 2011 togs en stadsplan fram för Ladok3 Stadsplan ~= verksamhetsarkitektur En verksamhet
Mobilt Efos och ny metod för stark autentisering
Mobilt Efos och ny metod för stark autentisering I och med lanseringen av E-identitet för offentlig sektor, Efos, kommer Inera att leverera komponenter som möjliggör att en användare ska kunna logga in
Arkitektur. Den Röda Tråden
Arkitektur Done Den Röda Tråden Vad är arkitektur? Vad har vi arkitekturmodellen till? Hur redovisar vi en arkitektur? Hur tar vi fram en arkitektur? Uppgift arkitekturella krav Nu Redovisning/Diskussion
Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga A. Tekniska ramverk. Version: 1.0
Regelverk Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag Bilaga A Tekniska ramverk Version: 1.0 Innehållsförteckning 1 Bakgrund och syfte... 1 1.1 Definitioner 1 2 Inledning...
Projektdirektiv för Ladok3-projektet
Styrgruppen Sida: 1 (8) Projektdirektiv för -projektet Styrgruppen Sida: 2 (8) 1 Programnamn/identitet är namnet på hela det flerårsprojekt som ska utveckla nästa generation av studieadministrativt systemstöd
Programutvecklingsprojekt Projektgrupp Elvin. Detailed Design Document
Programutvecklingsprojekt 2003-04-24 Projektgrupp Elvin Detailed Design Document Björn Engdahl Fredrik Dahlström Mats Eriksson Staffan Friberg Thomas Glod Tom Eriksson engdahl@kth.se fd@kth.se d94-mae@nada.kth.se
Molntjänster. Översikt. Lektion 1: Introduktion till molntjänst. Introduktion till molntjänst. Vilka tjänster finns? Säkerhet.
Molntjänster Översikt Introduktion till molntjänst. Vilka tjänster finns? Säkerhet. Lektion 1: Introduktion till molntjänst Vad är detta? the Cloud. Definition av molntjänster. Tjänster. Skikt. Klient.
LADOK3 INTEGRATION MOT. STUDIEDELTAGANDE SU, Mikael Berglund, ITS, Umeå Universitet Samuel Moritz, Omegapoint
LADOK3 INTEGRATION MOT STUDIEDELTAGANDE SU, 2017-04-03 Mikael Berglund, ITS, Umeå Universitet Samuel Moritz, Omegapoint 2 Agenda Översikt Antagning Återbud / Avbrott Registrering Tillfällesbyte Studieplan
30 år av erfarenhet och branschexperts
30 år av erfarenhet och branschexperts Integrerad Säkerhet Integrerad Säkerhet Varför överordnat system Användarvänlighet Kvalitet Trygghet Kostnadseffektivitet Varför ett överordnat system? Med stora
Innehåll Molntjänster... 4 Vad är detta?... 5 Cirkeln sluts... 6 The Cloud... 7 The Cloud (forts.)... 8 Definition av molntjänster...
1 2 Innehåll Molntjänster... 4 Vad är detta?... 5 Cirkeln sluts... 6 The Cloud... 7 The Cloud (forts.)... 8 Definition av molntjänster... 9 Definition av molntjänster (forts.)... 11 Tjänster... 12 Skikt
Mobilt Efos och ny metod för stark autentisering
Mobilt Efos och ny metod för stark autentisering I och med lanseringen av E-identitet för offentlig sektor, Efos, kommer Inera att leverera komponenter som möjliggör att en användare ska kunna logga in
Krav relaterat till gemensam databas. - strategiska frågor inom Ladok3
- strategiska frågor inom Ladok3 Sida 2 av 10 er Revision Datum Av Kommentar Granskare Godkännare 0.1 2011-05-31 Catherine Zetterqvist Utkast 0.2 2011-06-01 Daniel Mindre ändringar och formalisering. 0.3
Filleveranser till VINN och KRITA
Datum Sida 2017-04-25 1 (10) Mottagare: Uppgiftslämnare till VINN och KRITA Filleveranser till VINN och KRITA Sammanfattning I detta dokument beskrivs översiktligt Vinn/Kritas lösning för filleveranser
Sustainable engineering and design
Sustainable engineering and design 1 Bildyta - Välj Infoga bild Trender inom geografisk IT Hur hanterar man att GIT idag är en del av IT-utveckling och verksamhetsutveckling? Mikael Elmquist Sweco 2 Geografisk
Lathund: Studieavgifter Innevarande version vid senaste uppdatering:1.9.0
Lathund: Studieavgifter Innevarande version vid senaste uppdatering:1.9.0 Mer information om Ladok Utbildningsmaterial hittar du på Ladok.se: Aktuellt utbildningsmaterial Systemdokumentationen och dess
Distribuerade affärssystem
Distribuerade affärssystem Kursens mål Bygga upp, strukturera och programmera distribuerade system med en flerskiktsarkitektur Beskriva och förklara teorier och uttryck som används inom affärskritiska
Utbytesstudier på forskarnivå samt Doktorander från andra svenska lärosäten
Utbytesstudier på forskarnivå samt Doktorander från andra svenska lärosäten Innehåll Syftet med guiden är att förtydliga hur funktionaliteten för utbytesstudier kan tillämpas för studier på forskarnivå.
DIG IN TO Nätverksadministration
DIG IN TO Nätverksadministration Nätverksadministration Datormolnet The Cloud Agenda IT förändras kontinuerligt IT infrastruktur behöver byggas ut Högre krav på IT infrastrukturen Vad är datormoln? Vad
Ladok3 Erik Ångman 1
Ladok3 Erik Ångman 1 Ladok3» Nästa generation av studieadministrativt systemstöd för universitet och högskolor i Sverige, som alltså ska ersätta det Ladoksystem som idag är i drift 2 Kort tillbaka- och
Säkerställ er tillgänglighet Kommunikationsrapporteringsverktyg
Säkerställ er tillgänglighet Kommunikationsrapporteringsverktyg Vad är Meridix Studio? Meridix Studio är ett verktyg som låter er analysera och följa upp er kommunikation via ett enkelt men kraftfullt
Tekniskt ramverk för Svensk e- legitimation
Tekniskt ramverk för Svensk e- legitimation ELN-0600-v1.4 Version: 1.4 2015-08-14 1 (10) 1 INTRODUKTION 3 1.1 IDENTITETSFEDERATIONER FÖR SVENSK E- LEGITIMATION 3 1.2 TILLITSRAMVERK OCH SÄKERHETSNIVÅER
Informationsmöte Ladok3 JURIDISKA FAKULTETEN
Informationsmöte Ladok3 JURIDISKA FAKULTETEN 2016-09-29 Vad är Ladok3? Nytt studieadministrativt system (data förs över) Webbaserat med fokus på självservice Säkrare, effektivt och mer användarvänligt
Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga A. Tekniska ramverk. Version: 3.0
Regelverk Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag Bilaga A Tekniska ramverk Version: 3.0 Innehållsförteckning 1 Bakgrund och syfte... 1 1.1 Definitioner 1 2 Inledning...
Förvaltningsstrategi NyA 2014-2016
Avdelningen för systemförvaltning och systemdrift Föredragande Per Zettervall Avdelningschef 010-470 03 00 per.zettervall@uhr.se DNR 4.2.2 2631-2013 Datum 2013-06-13 Postadress Box 45093 104 30 Stockholm
DATALAGRING. Ämnets syfte
DATALAGRING Ämnet datalagring behandlar hur lagring av data görs på ett strukturerat sätt för att datorprogram ska komma åt data på ett effektivt sätt. Lagringen kan ske med hjälp av databashanterare av
Mobilt Efos och ny metod för stark autentisering
Mobilt Efos och ny metod för stark autentisering I och med lanseringen av E-identitet för offentlig sektor, Efos, kommer Inera att leverera komponenter som möjliggör att en användare ska kunna logga in
Examenskontrollören. Processbeskrivning. Ändringshistorik Datum Av Kommentar Godkännare Suzanne Svensson Första utkast -
Examenskontrollören 2009-12-13 Ändringshistorik Datum Av Kommentar Godkännare 2009-12-20 Suzanne Svensson Första utkast - Suzanne Svensson 2009-12-21 2 (9) Innehållsförteckning MATCHA SPECIFICERADE EXAMENSKRAV
Överblick IAM. Stefan Thoft. Projektledare IAM
IAM Överblick IAM Stefan Thoft Projektledare IAM IAM - Identity & Access Management Identitetshantering (Identity Management) är ett begrepp som används för att beskriva hur man hanterar digitala identiteter
AUTOMATISKA PROCESSER I ORIGO, FÖR EFFEKTIVARE PASSERADMINISTRATION OCH HÖGRE SÄKERHET
AUTOMATISKA PROCESSER I ORIGO, FÖR EFFEKTIVARE PASSERADMINISTRATION OCH HÖGRE SÄKERHET ORIGO SYSTEMET FÖR EFFEKTIVARE PASSERADMINISTRATION OCH HÖGRE SÄKERHET Med Origo har vi i nära samarbete med våra
Identity and Access Management på LU
Identity and Access Management på LU Vem är jag? Eskil Swahn IT-arkitekt på Lunds universitet Funktionen IT-arkitektur Uppdrag ifrån universitetsledningen Omsätta verksamhetens krav i tekniska lösningar
Kravspecifikation. Crowdfunding Halland
Kravspecifikation Crowdfunding Halland Innehållsförteckning Kravspecifikation... 1 Inledning... 3 Kravsammanställning... 4 Grundläggande funktioner... 4 Intressenter och aktörer... 6 Användningsfall...
Datacentertjänster IaaS
Datacentertjänster IaaS Innehåll Datacentertjänst IaaS 3 Allmänt om tjänsten 3 Fördelar med tjänsten 3 Vad ingår i tjänsten 4 Datacenter 4 Nätverk 4 Lagring 4 Servrar 4 Virtualisering 4 Vad ingår i tjänsten
Instruktion. Datum. 2013-06-19 1 (12) Coverage Dokument id Rev Status? - 1.0 Godkänd. Tillhör objekt -
20130619 1 (12)? 1.0 Godkänd Secure Manager Guide Hantera användarprofiler i tjänsten Telia Secure Manager Dokumentet beskriver hur du som administratör beställer och hanterar användarprofiler i administrationsportalen
Nya Ladok. Målbilder för framtidens studieadministration Sammanfattning av delrapporten VT 2014 kursadministratörernas och lärarnas målbilder
Nya Ladok Målbilder för framtidens studieadministration Sammanfattning av delrapporten VT 2014 kursadministratörernas och lärarnas målbilder Bakgrund Med anledning av att Uppsala universitet inom några
Ladok3 SamIT 2013-05-24
Ladok3 SamIT 2013-05-24 Kort om Ladok och Ladok3 Ladok är ett gemensamt nationellt system för studiedeltagande, resultat och examina. Ägs och drivs av medlemslärosätena (i princip samtliga svenska UoH,
Modernt stöd för en effektiv e-förvaltning
Modernt stöd för en effektiv e-förvaltning Så enkelt som möjligt för så många som möjligt Genom EF1 tillhandahåller Softronic en plattform (uppsättning tekniska tjänster) som tillsammans med övriga tjänster
Lathund: Programplanering Innevarande version vid senaste uppdatering:
Lathund: Programplanering Innevarande version vid senaste uppdatering: 0.97.0 Mer information om Ladok Utbildningsmaterial hittar du på Ladok.se: Aktuellt utbildningsmaterial Systemdokumentationen och
XML-produkter. -Registret över verkliga huvudmän (RVH) Teknisk handledning för webbtjänst mot RVH (Web Services) Datum: Version: 1.
XML-produkter -Registret över verkliga huvudmän (RVH) Teknisk handledning för webbtjänst mot RVH (Web Services) Datum: 2018-09-18 Version: 1.0 Innehållsförteckning 1. Inledning... 3 1.1. Syfte 3 1.2. Målgrupp
Fallstudie Den svenska Försvarsmakten Meddelandeinfrastruktur redo för det nya nätverksbaserade försvaret
Fallstudie Den svenska Försvarsmakten Meddelandeinfrastruktur redo för det nya nätverksbaserade försvaret Copyright 2002 - Xware AB. All rights reserved. xtrade is a registered trademark of Xware AB. Version
Apotekens Service. federationsmodell
Apotekens Service Federationsmodell Detta dokument beskriver hur Apotekens Service samverkar inom identitetsfederationer Datum: 2011-12-12 Version: Författare: Stefan Larsson Senast ändrad: Dokumentnamn:
Arkitektur för Bistånd
ark_uppsala_bistånd_v3.ppt Arkitektur för Bistånd Sven-Håkan Olsson, Definitivus AB. 1 Enstaka bild får användas med angivande av källa ÖTP V2.0 s22 Generellt mönster i ÖTP Medborgare Företag Handläggare
Sentrion och GDPR Information och rekommendationer
Information och rekommendationer Innehållsförteckning GDPR... 3 Principer... 3 Registrerades rättigheter... 3 Sentrion och GDPR... 4 Laglighet, korrekthet och öppenhet... 4 Ändamålsbegränsning... 4 Uppgiftsminimering...
Integrationstjänsten - Meddelandetjänsten Version 1.0
Tjänstebeskrivning Integrationstjänsten - Meddelandetjänsten Version 1.0 Introduktion Meddelande tjänsten eller EDI tjänsten som den kallats under många år är en punkt-till- punkt-, alternativt punkt-till-många-leverans
Kompletterande frågor - Regler för informationshantering. och arkivering i IT-system/applikationer, LA 2017
1(5) Landstingsarkivet 2018-05-24 LA 2018 0100 Kompletterande frågor - Regler för informationshantering och arkivering i IT-system/applikationer 1 Inledning och bakgrund Vid upphandling, avrop, utveckling
Identity Management för Microsoft
Identity Management för Microsoft Microsofts roadmap inom Sverige och hur påverkar det oss som leverantör och er som slutkund. Vilka steg har Microsoft tagit inom identitet, regelefterlevnad och åtkomst.
Lösenordsregelverk för Karolinska Institutet
Lösenordsregelverk för Karolinska Institutet Dnr 1-213/2015 Version 2.0 Gäller från och med 2015-05-18 Sida 2 av 7 Lösenordsregelverk för Karolinska Institutet - Sammanfattning Syfte Det övergripande syftet
Din leverantör av hissautomater, pallställ, grenställ och utdragsenheter.
v.2 Compact talk Programvaran som integrerar Compact Hissautomater med överliggande system Compact Talk gör det enkelt att till låg kostnad integrera Compact Hissautomater med ett överliggande system som
CNET SOLUTIONS VÅRA TILLÄMPNINGSOMRÅDEN FÖR IOT
CNet Solutions www.cnetsolutions.se 1 CNET SOLUTIONS Med Internet of Things kan företag snabbt och enkelt kontinuerligt samla in mätdata av betydelse för affärer och processer. CNet Solutions hjälper företag
Identity Management i ett nätverkssäkerhetsperspektiv. Martin Fredriksson
Identity Management i ett nätverkssäkerhetsperspektiv Martin Fredriksson Guide Konsult Göteborg AB, 2004 Varför IdM? Flera olika plattformar/tekniska system Windows, AD, Unix, routrar, VPN, etc, etc Många
Ladok3 Netinfo
Ladok3 Netinfo 2012-09-27 Ladok2 och Ladok3 Ladok2 betecknar här dagens Ladok Databas (MySQL) Noveau/Windowsklient/Uniface Java-batchar LPW-tjänster och portletar Ladok3 är nästa version av Ladok I princip
Studievägledarfrukost med nya Ladok-tema! Cecilia Marklund och Annika Björklund Studentavdelningen 21 juni 2018
Studievägledarfrukost med nya Ladok-tema! Cecilia Marklund och Annika Björklund Studentavdelningen 21 juni 2018 Vad gör ni i Uppdok idag? Läser endast i Uppdok Var tittar ni? (UT10, mer?) Behörighetskontroller?
Tentamen i: Affärssystem och tjänsteorienterad arkitektur
Tentamen i: Affärssystem och tjänsteorienterad arkitektur Kurskod: DSK2:SOA1 Datum: 14 februari 2014 Tid: 15:00 19:00 Examinator: Elin Uppström Information Hjälpmedel: Omfång: Poängkrav: Utförande: Inga
Per Rasck Tjänsteansvarig. Tobias Ljunggren IAM Arkitekt
Per Rasck Tjänsteansvarig Tobias Ljunggren IAM Arkitekt EN MOLNBASERAD Identitet och behörighetstjänst Vi har tagit fram en lösning som hjälper er Förbättra genom hög grad av automation Förenkla lätt att
Dokument: Objektägare-ITs placering. Författare Malin Zingmark, Förnyad förvaltning
Dokument: Objektägare-ITs placering Författare Malin Zingmark, Förnyad förvaltning Version A Sida 1 av 9 Datum 2015-03-25 Bil p 820 : 1 Objektägare-ITs placering Innehåll Objektägare-ITs placering... 1
Om lathunden. Vad lathunden inte beskriver Systemdokumentationen och dess funktionsbeskrivningar på wikin beskriver systemet som helhet.
Om lathunden Syftet med lathunden Syftet med Lathunden är att minimera informationsmängden för att utföra en uppgift i ett specifikt sammanhang. Lathunden förutsätter att du känner till det grundläggande
Handhavandeguide: Studiedeltagande Innevarande version vid senaste uppdatering:
Handhavandeguide: Studiedeltagande Innevarande version vid senaste uppdatering: 1.15.0 Mer information om Ladok Mer utbildningsmaterial hittar du på Ladok.se: Aktuellt utbildningsmaterial Systemdokumentationen
Välkommen! Bakgrund Cloud Sweden Vad är molnet? Legala aspekter på molntjänster. http://cloudsweden.se
Välkommen! Bakgrund Cloud Sweden Vad är molnet? Legala aspekter på molntjänster Cloud Sweden Oberoende kompetensnätverk Analys & Konsultbolag Leverantörer Kunder Dataföreningen Startat i mars 2010 Predrag
Introduktion till molntjänster Tekniken bakom molntjänster och legala utmaningar
Introduktion till molntjänster Tekniken bakom molntjänster och legala utmaningar 19 november 2012 - Erica Wiking Häger och Mikael Moreira Innehåll 1. Vad är molntjänster? 2. Legala utmaningar 3. EU:s förslag
PhenixID & Inera referensarkitektur. Product Manager
PhenixID & Inera referensarkitektur Product Manager tommy.almstrom@phenixid.se PhenixID & Inera referensarkitektur PhenixID & Inera Identitetslager PhenixID & Inera Identifieringstjänst PhenixID & Inera
Data Sheet - Secure Remote Access
Data Sheet - Secure Remote Access Savecores säkra fjärranslutning Med Savecores säkra fjärranslutning kan du känna dig trygg på att ditt data är säkert, samtidigt som du sparar tid och pengar. Ta hjälp
Skapa förväntat deltagande på kurstillfälle eller kurspaketeringstillfälle (Manuell antagning i Ladok)
Skapa förväntat deltagande på kurstillfälle eller kurspaketeringstillfälle (Manuell antagning i Ladok) Innehåll. Förväntat deltagande på kurstillfälle -2 2. Förväntat deltagande på kurspaketeringstillfälle
Vilka problem och möjligheter står våra utbildningsdatabaser inför i och med övergången till nya Ladok?
Vilka problem och möjligheter står våra utbildningsdatabaser inför i och med övergången till nya Ladok? Karim Andersson, Lunds universitet Lotta Garvill, Örebro universitet Per Sandström, Uppsala universitet
TMP Consulting - tjänster för företag
TMP Consulting - tjänster för företag Adress: http://tmpc.se Kontakta: info@tmpc.se TMP Consulting är ett bolag som utvecklar tekniska lösningar och arbetar med effektivisering och problemslösning i organisationer.
NyA, Ladok och identitetsfederationer - så hänger det ihop! Kristina Leve, VHS
NyA, Ladok och identitetsfederationer - så hänger det ihop! Kristina Leve, VHS Jag tänkte berätta om VHS NyA Ladok Studera.nu och identitetstjänster Information och påverkan VHS Verket för högskoleservice
Webbteknik. Innehåll. Historisk återblick Teknisk beskrivning Märkspråk Standardisering Trender. En kort introduktion
Webbteknik En kort introduktion Innehåll Historisk återblick Teknisk beskrivning Märkspråk Standardisering Trender 1 Historisk återblick 89 CERN Tim Berners Lee Ett plattformsoberoende sätt att sprida