D Konverteringsstrategi og - design

Transkript

1 Version 1.32 Status 02 - Under udarbejdelse Godkender Katja Ring Johansen Forfatter Mads Hald Jørgensen UDDANNELSES- OG FORSKNINGSMINISTERIET ESAS D Konverteringsstrategi og - design Copyright 2020 Netcompany. Alle rettigheder forbeholdes. Elektronisk, mekanisk, fotografisk eller anden gengivelse, oversættelse eller kopiering af dette dokument eller dele deraf er ikke tilladt uden forudgående skriftlig tilladelse fra Netcompany.

2 Dokumenthistorik Version Dato Forfatter Status Bemærkninger Mads Hald Jørgensen Udkast Mads Hald Jørgensen Udkast Mads Hald Jørgensen Udkast Første udkast af afsnit 2 og underafsnit er færdiggjort Uddybet i henhold til kommentarer fra reviewprocessen, tidslinje udestår stadig Mads Hald Jørgensen Klar til review Tidslinje tilføjet, kommentarer indarbejdet Kell Kvist Review Kell Kvist Review Mads Hald Jørgensen Review Kell Kvist Review Mads Hald Jørgensen Review Kell Kvist Review Mads Hald Jørgensen Review Mads Hald Jørgensen Review Mads Hald Jørgensen Review Kell Kvist Review Kommentarer relateret til krav KO-6 Kommentarer relateret ril krav KO-3, KO-4, KO-5 Rettelser baseret på kommentarer i afsnit 2.2 Kommentarer relateret til krav KO-3, KO-5 Tilføjet uddybende kommentar i afsnit 4 relateret til krav KO-8 Kommentarer relateret til krav KO-7, KO-8 Ændret sætning i slutningen af afsnit Logning (rapportering og afstemning relateret til KO-9 Tilføjet Logning (rapportering og afstemning relateret til KO-10 Ændret og udvidet en sætning i afsnit 4.2, relateret til KO-11 Kommentarer relateret til krav KO-9, KO-10, KO-11, KO Bo Høegh Frederiksen Udvidet afsnit 3.3, 4.2 og Rasmus Holm Jensen Udkast Bo Høegh Frederiksen Udkast Opdatering af (Bedømmelser) Tilføjet afsnit om mapping af postnumre Bo Høegh Frederiksen 02 - Under Omstrukturering og omskrivning 2020 Netcompany Side 2 af 69

3 Version Dato Forfatter Status Bemærkninger udarbejdelse af afsnit Sidsel Thaarup Udkast Tilføjet afsnit om GUE Rasmus Holm Jensen Udkast Omskriv afsnit om Logning (Rapportering og afstemning) afsnit 2.8. Dette afsnit erstatter også det tidligere afsnit om Afstemning (tidligere 2.8) Caroline Bøegh Salomonsen Udkast Tilføjet afsnit om praktikophold Sidsel Thaarup Udkast Caroline Bøegh Salomonsen Udkast Tilføjet afsnit om Lande og Postnumre Tilføjet afsnit om Personoplysninger Bo Høegh Frederiksen Sidsel Thaarup Sidsel Thaarup Caroline Bøegh Salomonsen Caroline Bøegh Salomonsen Klar til review Klar til review Klar til review Klar til review Klar til review Tilføjet afsnit Fejl! Henvisningskilde ikke fundet. om konvertering af testdata Åben Uddannelse Teknisk Studieskift UVM-FAG Semestermerit Sidsel Thaarup Udkast Fartstid Caroline Bøegh Salomonsen Caroline Bøegh Salomonsen Klar til review Klar til review Unge database-hændelser Faktureringsgrundlag & Faktureringsgrundlagslinjer Bo Høegh Frederiksen Udkast Tilføjet afsnit om staging Sidsel Thaarup Mads Hald Jørgensen Bo Høegh Frederiksen Klar til review Klar til review Klar til review Tilføjet afsnit om lønnet praktik Færdiggjort afsnit om rekvirent Tilføjet afsnit om STÅ indberetning 2020 Netcompany Side 3 af 69

4 Version Dato Forfatter Status Bemærkninger Caroline Bøegh Salomonsen Reviewet Rewiet afsnit om funktionelle områder Bo Høegh Frederiksen Bo Høegh Frederiksen Klar til review Klar til review Opdateret afsnit om meritregistreringer Omskrevet afsnit Caroline Bøegh Salomonsen Udkast Tilføjet afsnit om enkeltfag Bo Høegh Frederiksen Mads Hald Jørgensen Bo Høegh Frederiksen Anne-Marie Julskov Hansen Sabrina Vogt Anne-Marie Julskov Hansen Klar til review Klar til review Version Godkendt Version Godkendt Tilføjet Delete til operationer Større omskrivninger og tilføjelser i dokumentet baseret på erfaringer og reviewkommentarer Tilføjet afsnit om falske positive fejl. Indskrevet kommentar i Bilag 8.1. om fjernelse af 4 ÅU Aktivitetsgruppekoder, der ikke skal konverteres med S412 Referencer Reference Titel Forfatter Version [D0170.1] D Konverteringsområder Netcompany A/S [Go-Live, Pilotudrulning] Tidsplan for pilotudrulning, Q Netcompany A/S [Datamappinger] Mappingliste på Toolkit Netcompany A/S Tabel 1 - Referencer Indholdsfortegnelse 1 INTRODUKTION Formål Afgrænsning Målgruppe Netcompany Side 4 af 69

5 1.4 Ordliste...Fejl! Bogmærke er ikke defineret. 2 KONVERTERINGSPROCESSEN Konverteringsstrategi Udlæsning og indlæsning af data Konvertering ved hjælp af staging Kørsel af konvertering Tværgående dubletter Afslutning af konvertering Fejlhåndtering under konvertering For-, hoved- og efterbehandling Logning (rapportering og afstemning) Samling og tidsmåling af pakkeeksekvering (PackageLog) Overførsel af unikke nøgler (UniqueLog) Behandling og fejlhåndtering (EventLog) Afstemning og rapportering (VerificationLog) DATAAFGRÆNSNING FUNKTIONELLE OMRÅDER Mappinger Afhængigheder til konverteringen Plugins og workflows Konverteringsopsætning Metadata Personer Studerende Uddannelser Karaktergivende elementer Indberetninger Dataejerskab og deling Dataejerskab af person Deling af personer Deling af studieforløb og gennemførelsesuddannelseselementer på ÅU TIDSPLAN FOR KONVERTERING Leverance af data fra kunden Prøvekonverteringer Detaljeret konverteringsplan TEST AF KONVERTERING Teknisk test Funktionel test Test af rapportering...fejl! Bogmærke er ikke defineret. 7 TEKNISK INFRASTRUKTUR TIL KONVERTERING Udviklingsmiljø Konverteringsmiljø BILAG ÅU Aktivitetsgruppekoder med opsætning i S Netcompany Side 5 af 69

6 1 Introduktion Dette dokument vil beskrive datakonverteringen fra det eksisterende SIS system til det kommende system. 1.1 Formål Formålet med dette dokument er at dokumentere det overordnede konverteringsdesign, med henblik på at få review og accept af det overordnede design af SIU. Formålet er desuden at være en del af dokumentationen til institutionerne, så de kan få indblik i, hvordan deres data er konverteret. 1.2 Afgrænsning Dette dokument beskriver det overordnede design for konverteringsopgaven, og skal suppleres med detaljerede mappinglister og datatransformationsregler fra -projektets Toolkit. Konverteringen udføres med en konverteringsmotor, som er baseret på SQL Server Integration Services (SSIS). SSIS vil ikke blive beskrevet i detaljer i dokumentet. 1.3 Målgruppe Målgruppen for dette dokument er følgende: Udviklere af konverteringen o Med henblik på at udføre arbejdspakker relateret til konverteringen og generelt få indblik i opsætningen af konverteringsmotoren. Tekniske reviewere hos SIU o Med henblik på at kvalitetssikre designet og den planlagte gennemførsel af konverteringen fra et teknisk perspektiv. Projektledere af projektet samt ledelsen af konverteringen o Med henblik på at planlægge konverteringsopgaver og udrulning mv. Tekniske ressourcer hos institutionerne o Med henblik på at give dem mere teknisk forståelse for konverteringen, og de afgrænsninger der er sat op for konverteringen. 2 Konverteringsprocessen Dette afsnit beskriver de overordnede praktiske og tekniske rammer for konverteringen. Følgende områder vil blive beskrevet: Konverteringsstrategi: Beskriver grundlæggende, hvordan der skal konverteres. Udlæsning og indlæsning af data: Beskriver praktikken omkring levering af data og hvordan denne data indlæses. Kørsel af konvertering: Beskriver de tekniske rammer for kørsel af konverteringen. Afslutning af konvertering: Beskriver de aktiviteter der udføres, efter data er blevet indlæst i destinationssystemet Netcompany Side 6 af 69

7 Fejlhåndtering under konvertering: Beskriver den overordnede fejlhåndteringsmekanisme i forbindelse med konverteringen. Auditlogging: Beskriver niveauet for logning i forbindelse med konverteringen. Afstemning: Beskriver hvordan konverteringen afstemmes. 2.1 Konverteringsstrategi [KO-12] Godkendt: Kell Kvist. Dato: I dette afsnit beskrives konverteringsstrategien i overordnede termer. Det samlede projekt for vil blive kørt som et agilt SCRUM projekt, og derfor vil opsætning af konverteringsmotoren og udførsel af prøvekonverteringer også foregå agilt, fordelt over projektets delleverancer. Konverteringen til det nye system sker af 3 delkonverteringer (en under pilotudrulning og en for hver udrulningsbølge), hvor hver delkonvertering indeholder flere institutioner. Hver institution er kun med i en enkelt delkonvertering, så alle data for den enkelte institution konverteres samtidigt. Alle data som skal konverteres stammer fra SIS systemet, så der er kun ét kildesystem der skal konverteres fra. Dog har hver institution deres egen SIS database, ligesom der også er en delt SIS database. Desuden suppleres SIS data med institutionsspecifikke mappingark, til at mappe data der ikke er mulige at mappe direkte imellem SIS og Læseadgangen til SIS data for de enkelte institutioner leveres af leverandøren af SIS, i form af læseadgang til fulde kopier af institutionernes produktionsdatabaser for SIS. Hvornår kopier af de enkelte institutioners databaser skal leveres, aftales med institutionerne i samarbejde med SIU, når institutionerne er blevet opdelt i de forskellige delkonverteringer. Hver delkonvertering er planlagt til at køre over en weekend. Institutionernes adgang til SIS lukkes ned fredag middag, og mandag morgen åbnes der op for adgangen til. Indeholdt i denne nedetid, er eventuelle ændringer og verifikationer, som institutionerne skal foretage lokalt, før de kan gå i drift med det nye system og integrationerne med deres lokale systemer. Det inkluderer f.eks. ændringer af de webservices der anvendes til integrationer, samt eventuelle ændringer af nøgler der anvendes til integration med fra deres lokale systemer, hvis disse nøgler er blevet ændret ifm. konverteringen. Dette kunne f.eks. være ID på studerende, hold eller lignende. For at sikre at institutionerne kan udføre de påkrævede handlinger, skal der udarbejdes en detaljeret plan for hver institution, som udspecificerer hvilke handlinger der skal udføres og hvornår de skal udføres. Alle handlinger som kan foretages før eller samtidigt med konverteringen planlægges derefter, så det begrænses hvor mange handlinger der først kan udføres efter konverteringen er afsluttet og afstemt. Den overordnede plan for en given delkonvertering er beskrevet i Tabel 2 (Der er endnu ikke indsat konkrete datoer, da disse skal afklares som en del af detaljeret design og under planlægningen af de enkelte delkonverteringer): Dato + Tid Fredag kl 12:00:00 Fredag kl. 12:00:00 Fredag kl. 12:00:00 Fredag Kl. 14:00:00 Aktivitet SIU lukker for adgangen til SIS for de udvalgte institutioner, og -PROD for alle institutioner, og påbegynder eventuel klargøring af data for udvalgte institutioner. SIS-jobs der kan have indflydelse på data til konverteringen afvikles en sidste gang. Der tages backup af -PROD databasen Der tages backup af institutionernes SIS-prod Netcompany Side 7 af 69

8 Fredag kl. 16:00:00 Fredag kl. 17:00:00 -PROD backup indlæses i PREPROD miljøet Konverteringsmotoren igangsættes og transformering, validering og indlæsning påbegyndes mod i PREPROD. * Data som skal oprettes sammenlignes med allerede oprettede data, og poster oprettes eller opdateres tilsvarende. Indlæsning færdiggøres, og afsluttende afstemning af data påbegyndes. Afstemning afsluttes og konverteringen meldes afsluttet. Søndag kl. 12:00:00 Søndag kl. 17:00:00 Søndag kl. 18:00:00 Mandag kl. 08:00:00 Begrænset adgang til PREPORD aktiveres for de konverterede institutioner med henblik på godkendelse af konverteringen. -PREPROD flyttes over i PROD. trykprøves af brugere Adgang til åbnes op for alle brugere Tabel 2 - Overordnet tidsplan for delkonvertering Der udarbejdes en detaljeret plan for hver udrulningsbølge. For piloterne kan denne findes under Tabel Udlæsning og indlæsning af data [KO-3, KO-4, KO-5, KO-6] Det er blevet besluttet, at konverteringsmotoren skal trække data direkte fra SIS databaserne. Ved prøvekonverteringer vil der blive taget kopier af relevante institutioners SIS databaser. Disse kopier indlæses i en Oracle database, så der kan laves en 1-til-1 kopi, uden at skulle omforme data til SQL eller andet format. Ved konverteringen af data til Go-Live læses der direkte fra institutionernes SIS databaser i produktion. Der tages en backup af databaserne umiddelbart inden konverteringen begynder, til dokumentation af konverteringsgrundlaget. Udvælgelsen af relevant data for konverteringen gøres i et samarbejde mellem Netcompany, SIU og institutionerne. Enkelte tabeller kan komme på tale at undlade fra kopien, hvis de indeholder markante mængder data som ikke skal konverteres. Dette kunne fx være logs af forskellig art, eller vedhæftede filer. I udviklingsmiljøet er det kun tilladt at arbejde med anonymiserede data, da udviklingsmiljøet ikke er placeret internt i SIUs IT-landskab. Der er åbnet op for læseadgang til en anonymiseret database kopi fra en enkelt institution, som kan bruges til opsætninger og prøvekonverteringer i udvikling. Denne database anvendes til opsætning af konverteringsmotor og eventuelle prøvekonverteringer, indtil et internt konverteringsmiljø er etableret. Når det interne konverteringsmiljø er etableret, skal der opsættes en læseadgang til en fuld kopi af en SIS database, så der arbejdes med fulde datasæt. Der skal etableres og benyttes en kopi af en SIS database, da man af sikkerhedsmæssige og performancemæssige årsager ikke ønsker at læse direkte i en kørende produktionsdatabase i SIS. Netcompany koordinerer tidspunkter og frekvens af databasekopier med driftsleverandøren af SIS. Det er Netcompany der udarbejder scripts og andet programmel, til at udtrække relevante data til konverteringen fra disse databasekopier. Udvælgelsen af relevante data sker i samarbejde med SIU og uddannelsesinstitutionerne. Kvaliteten af relevante data vurderes af Netcompany, SIU og uddannelsesinstitutionerne. Hvis kvaliteten af data ikke er tilstrækkelig til at kunne konverteres til, kan institutionerne blive bedt om manuelt at foretage datavask, eller det kan aftales imellem Netcompany, SIU og institutionerne, at data er af for dårlig kvalitet og slet ikke kan konverteres ind i Netcompany Side 8 af 69

9 Det er vigtigt at have et stabilt datasæt at arbejde med under udviklingen af konverteringen. Nye kopier af SIS databaser tages maksimalt én gang hvert sprint, dvs. cirka hver 4. uge. Dette kan godt involvere kopier af tre forskellige databaser. Dette giver mange kopier over hele udviklingen af projektet, derfor skal driften etablere en procedure, så det kan foretages med mindst mulig manuel indblanding. Det vil give mere arbejde for driften i starten af projektet, men give værdi over projektets løbetid. SIU er overordnet ansvarlig for at der bliver lavet kopier af databaserne og givet læseadgang fra konverteringsserveren. Netcompany er overordnet ansvarlige for anvendelsen af databasekopierne til opsætning af konverteringsmotoren og gennemførslen af prøvekonverteringer, med støtte fra SIU og institutionerne. Før en delkonvertering, vil det være nødvendigt at etablere kopierer af databaserne for de institutioner som er en del af delkonverteringen. Disse kopier bruges til at færdiggøre evt. opsætning af konverteringsmotoren, som er specifik for de enkelte institutioner, og at gennemføre prøvekonverteringer og afstemninger for at sikre kvaliteten af data. 2.3 Konvertering ved hjælp af staging Konverteringen kommer til at foregå over flere etaper, og institutionernes data vil blive konverteret ind i et live system. For at minimere drift forstyrrelser og lette arbejdet ved en eventuel tilbagerulning, vil der blive anvendt et stagingmiljø som selve kørslen af konverteringsmotoren peges mod. Ved succesfuldt og godkendt konvertering af institutionernes data vil databasen blive ført tilbage til produktionsmiljøet med det nyligt migreret data. Ved at gøre brug af staging vil det give Netcompany, SIU og institutionerne muligheden for uforstyrret at kontrollere at datamigreringen er forløbet korrekt. Herved sikres det, i tilfælde af fejl eller, at resultatet ikke kan godkendes, at den daglige drift uforstyrret vil kunne fortsætte umiddelbart efter uden nogen påvirkning af produktionsdata. Det er driften, der er ansvarlige for kopi og flytningen af databasen frem og tilbage mellem produktions- og stagingmiljøet, mens Netcompany er ansvarlige for eksekveringen af konverteringsprogrammellet. Kontrollen af det konverterede data står både Netcompany, SIU og institutionerne i den igangværende udrulningsbølge for. Der udarbejdes en separat teknisk vejledning til, hvordan staging mellem miljøerne udføres. 2.4 Kørsel af konvertering [KO-3, KO-4, KO-5, KO-7,KO-14] Til kørslen af konverteringen anvendes en konverteringsmotor, som er baseret på Microsoft SQL Server Integration Services (SSIS). Kørslen af en konvertering igangsættes af en konverteringsansvarlig med konverteringsmotoren, som bliver opsat på en konverteringsserver. I konverteringsmotoren vil der være defineret en række Extract Transform Load (ETL) operationer som skal foretages. Data læses (Extract) direkte fra en eller flere SIS databaser. Disse data kontrolleres efter opsatte regler, som er specifikke i forhold til de data som læses. Reglerne der opsættes er regler som udelukkende anvendes til konverteringen og nødvendige forretningsregler, som vil være gældende i. For at kunne køre konverteringen hurtigere, implementeres de påkrævede forretningsregler direkte i konverteringsmotoren. For de konverterede uddannelsesstrukturer valideres der ikke mod regelmotoren, da betingelser fra SIS ikke kan konverteres til betingelser i. Reglerne bestemmer, hvordan data transformeres og efterfølgende indlæses (Load) i. Transformeringer af data logges og anvendes til senere afstemning. Konverteringsmotoren afstemmer de data, der er indlæst for et givent datasæt, fx studerende, så det sikres at der er konverteret samme antal studerende som der er i datagrundlaget. Der kan blive fravalgt data fra datagrundlaget allerede ved læsning, hvis dele af data ikke er relevant i forhold til konverteringen, fx forældede data. Se afsnit 3 - Dataafgrænsning for uddybning af fravælgelse af data. Logning af datatransformeringerne anvendes til at bestemme, om 2020 Netcompany Side 9 af 69

10 dublet data er blevet lagt sammen under konverteringen, hvilket vil resultere i et mindre antal studerende oprettet i ift. data læst fra datagrundlaget. Konverteringsmotoren er illustreret i Figur 1. AMS Konverteringsmotor Konverterings initialisation IBA Konverteringsmanager Workers Transformation Elevdata Profiling KME De-Normalisering Audit logging Skrivning til destination Uddannelsesdata Profiling VIA Efterbehandling Afstemning Konverterings finalisation Figur 1 Konverteringsmotor I Tabel 3 er konverteringsmotorens funktionelle komponenter beskrevet. Bemærk at den samlede proces for konverteringen vil involvere flere iterationer af handlingerne i konverteringsmotoren, hvor der fx først læses, transformeres og konverteres data om elever, og herefter læses, transformeres og konverteres data om uddannelser eller hold. Funktionel komponent De-normalisering Beskrivelse Data udvælges fra kildetabeller med et opslag med joins (krydsopslag). Der kan i isolerede tilfælde være decideret forbehandling hvor data de-normaliseres via en midlertidig tabel eller vha. et view. Dernæst udføres logik til at udvælge de konkrete kilderækker, der danner input til de enkelte transformationsaktiviteter. Destinationsrækker dannes ved at udføre mappings. Dvs. at hvert enkelt felt i destinationsrækken beregnes på baggrund af kildefelterne. Transformation Transformationerne kan være betingede af værdier der læses fra specifikke felter, så der mappes forskellige kildefelter til det samme destinationsfelt, afhængigt af de data der læses. Der er muligt at tilpasse transformationsregler specifikt til enkelte institutioner, eller opsætte helt nye transformationsregler specifikt til en enkelt institution. Transformationer der indebærer ændring af data, vil blive logget med auditlogning. Auditlogning Skrivning til destination Undervejs i konverteringen kan der dannes logs som skal understøtte informationsgrundlaget for konverteringen og afstemningen. Auditlog er yderligere beskrevet i afsnit 2.8. Når transformationerne afsluttes gemmes destinationsrækkerne i en synkroniseret kø, indtil der endelig foretages en samlet skrivning til destinationsdatabasen Netcompany Side 10 af 69

11 Efterbehandling Efterbehandlingsskridtet er et muligt skridt, hvor der f.eks. kan laves afslutningsvise justeringer af destinationsdata, fx eventuelle handlinger til automatisk datavask, som kan gennemføres uden at kompromittere datakvaliteten. Efterbehandling vil ikke altid være nødvendig. Det sidste skridt af en konverteringsmanager er, at der foretages et antal dækkende afstemninger. Afstemninger skal så vidt muligt være uafhængige af al logik i transformationer og kun tælle op i henholdsvis kildedata og destinationsdata. Afstemning Der kan dog være behov for at medtage eventuelle sammenlægninger af dubletter, når der laves optællinger, hvis konverteringsmotoren opsættes til at lave automatiske dubletsammenlægninger. Optællinger i kildesystem og destinationssystem sammenlignes og resultatet logges Tværgående dubletter [KO-7] Tabel 3 - Beskrivelse af konverteringsmotorens funktionelle komponenter Da data til konverteringer kommer fra mange forskellige databaser, og skal konverteres ind i en enkelt database, skal der opsættes regler for, hvordan tværgående dubletter håndteres (altså dubletter som er placeret i forskellige databaser). Det nye system vil ikke tillade oprettelse af dubletter, derfor skal konverteringen håndtere dette. I daglig brug vil systemet have indbygget funktionalitet til at håndtere forsøg på oprettelse af dubletter. Hvis en studerende har været tilknyttet tre forskellige institutioner og er oprettet i hver institutions SIS database, gælder følgende regler: Første institution, hvor personen har været tilknyttet, bruges til at oprette personen og sættes også som ejer Efterfølgende institutioner kontrolleres mod samme person. Hvis disse har nyere data omkring personen, dvs. et mere aktuelt studieforløb, så sættes den nye institution som ejer. Personer deles med alle institutioner, hvor personen har været tilknyttet, indenfor kriterierne for udvælgelse af aktive personer og studieforløb (se afsnit 3) Stamdata for personen sættes med data for første relevante institution, og opdateres kun igennem CPR integration. Personer med et fiktive CPR-nummer, som tidligere er oprettet i, får dannet et nyt cpr-nummer med formen xxxx, hvor xxxx sættes som et fortløbende serienummer. Fødselsdatoen sættes fortsat ud fra datoen for det oprindelige CPR-nummer. 2.5 Afslutning af konvertering Efter endt delkonvertering til, vil konverteringsmotoren optælle logs for det indlæste data. Disse logs anvendes til rapportering af delkonverteringen. Under indlæsning af konverteringsdata, skal alle planlagte jobs og integrationer med eksterne systemer være deaktiveret. Undtagelsen er, hvis en specifik integration skal bruges, for at hente data der er påkrævet for at konverteringen kan gennemføres. Når afstemningen af data er gennemført, kan integrationerne og planlagte jobs genaktiveres i planlagt rækkefølge Netcompany Side 11 af 69

12 2.6 Fejlhåndtering under konvertering Hvis fejl indtræffer undervejs i en konvertering, vil disse blive fanget og håndteret inden for rammerne af en konverteringsmanager. Alle fejl logges så snart de opdages af konverteringsmotoren og konverteringen fortsætter, således at en håndtering kan foretages umiddelbart bagefter. Er der tilfælde, hvor en fejl ikke kan udbedres i forbindelse med konverteringen, skal der som udgangspunkt oprettes en opgave til manuel opfølgning efter konverteringen. Tilstande der resulterer i en opgave til manuel opfølgning specificeres nærmere i forbindelse med design af konverteringen. Loggen vil indeholde oplysninger, så det er muligt at genfinde datagrundlaget, som har været årsag til fejlen. Såfremt en mere alvorlig fejl opstår, hvor f.eks. forbindelsen til databasen forsvinder, vil der under konverteringen blive implementeret checkpoints, hvilket udgør logning af et gendannelsespunkt af databasen. Konverteringen kan derfor genoptages fra dette checkpoint, hvorfor konverteringen således ikke skal startes forfra i tilfælde af nedbrud. Et gendannelsespunkt vil også blive oprettet inden de første data i en delkonvertering oprettes, så det er muligt at rulle systemet tilbage til den datatilstand, der var inden konverteringen. 2.7 For-, hoved- og efterbehandling Konverterings programmellet er overordnet set delt op I tre stadier: Forbehandling, hovedbehandling og efterbehandling. Disse stadier har tre forskellige typer ansvar og skal eksekveres hhv. før, under og efter konverterings lukkevinduet. Figur 2 illustrerer rækkefølgen og vinduet af stadierne. Disse omtales også som PreFlow, MainFlow og PostFlow. Forbehandling Konverterings lukkevindue Dataoprettelse Efterbehandling Supplerende efterbehandling Figur 2 - Konverteringsstadier Forbehandling eller Preflow er konvertering af data fra statiske kilder og SIU, som danner grundlag for, at de institutionsspecifikke data kan konverteres ind korrekt, her er der tale om data som afdelinger og teams, samt statiske data som lande og postnumre. Hovedbehandling eller MainFlow er her hvor data reelt konverteres og her hvor lukke vinduet for konverteringen starter. Her konverteres de institutionsspecifikke data ind. Alt fra studerende til udbudte fag som er registreret i SIS. Efterbehandling eller PostFlow er opdatering af de allerede konverterede data. Her køres programmel som sammenbinder de nyligt konverterede data, så som at binde planlægningselementer og gennemførselselementer sammen. Derudover laves der også opdateringer af data, som kræver mange dataområder indlæst inden opdateringen kan foretages. Generelt bruges dette til at skabe orden i data som ikke er kritisk for at løsningen virker. Supplerende efterbehandling som vil blive kørt efter lukkevinduet. Dette kan være almindelige -systemjob, som fx opdatering fra CVR og CPR, men også konverteringsspecifikke jobs som dannelse af bevisgrundlag for de konverterede studieforløb. Den supplerende efterbehandling udføres, imens systemet er i drift Netcompany Side 12 af 69

13 2.8 Logning (rapportering og afstemning) [KO-9, KO-10, KO-13] Der logges af forskellige årsager i forbindelse med konvertering. Det samlede fælles formål med disse er rapportering af udfaldet for en given konvertering. I dette afsnit vil vi beskrive strategien for at logge i forbindelse med eksekveringen af konverteringsprogrammellet. Der vil herunder være beskrivelse af: - en log til at samle og tidsmåle eksekvering af en pakke (PackageLog) - en log til unikke nøgler (UniqueLog) - en log til status af de enkelte rækker fra SIS (EventLog) - en log som skal hjælpe med at afstemme og opsamle udfaldet af konverteringen (VerificationLog). Disse logs ligger i hver sin tabel i en fælles database, og vil i forbindelse med prøvekonverteringer og go-live konverteringer blive lagt på relevante institutioners SIS-sftp drev som MSSQL database backup filer. Foruden log tabellerne findes der referencetabeller, som bruges til at strømline data, og gør det muligt at lave mere eksplicitte krydssøgninger på tværs af delt data logs imellem. Disse tabeller indeholder et navn/angivelse samt en primær nøgle, som kan bruges til at annotere andre logs. Sources Bruges til at ensarte navngivningen af forskellige datakilder og datadestinationer. Altså vil der kun findes en række fra samme datakilde i SIS. Eksempelvis vil PERSONER (datakilde) kun fremgå én gang, og tilsvarende vil tabelnavnet i (datadestination) også kun fremgå én gang. Operations Bruges til at ensarte navngivningen for operationer, som annoterer poster i andre logs. Navnet på en operation er eksempelvis Create. Dette vil kun fremgå én gang og en primær nøgle kan bruges til annotere poster i Event- og VerificationLog. Indholdet af denne tabel vil blive beskrevet i højere detaljegrad i afsnit Organizations Bruges til at ensarte navngivningen af ejere af data, som annoterer poster i andre logs. Altså vil der kun findes en række for hver institution i denne tabel. Der vil også være en række som repræsenterer system ejede data samt en række for data, som skal ejes af styrelsen. En model over strukturen for logdatabasen kan ses Figur 3 - Log database. Foruden førnævnte tabeller eksisterer der også database views: EventLogView og UniqueLogView og VerificationLogView. Disse views samler indhold fra reference tabeller (Sources, Operation og Organizations) ind i samme view så man reducere krydssøgning med reference nøgler Netcompany Side 13 af 69

14 OrganizationId Organizations - DBName: string - Group: int - Id (PK): int - Organization: string OrganizationId Operations - Id: int - Operation: string OperationId OriginSoruceId DestinationSourceId Sources - Id: int - Id1Name: string - Id2Name: string - Source: string - SourceSystem: string - TabelName: string - TableFriendlyName: string OrganizationId PackageLogId OperationId OrganizationId PackageLog - EndTime: DateTime - Id (PK): int - MasterLogId (FK): int - OrganizationId (FK): Int - PackageName: string - StartTime: Datetime PackageLogId MasterLogId EventLog - Created: datetime - DestinationId: string - DestinationSourceId (FK): int - Id (PK): int - Message: string - OperationId (FK): int - OrganizationId (FK): int - OriginId: string - OriginSourceId (FK): int - PackageLogId (FK): int - TraceCodes: string OriginSourceId DestinationSourceId PackageLogId VerificationLog - Amount: int - DestinationSourceId (FK): int - Id (PK): int - OperationId (FK): int - OrganizationId (FK): int - OriginSourceId (FK): int - PackageLogId (FK): int UniqueLog - Created: datetime = getdate() - DestinationId: string - DestinationSourceId (FK): int - Id1: string - Id1Name: string - Id2: string - Id2Name: string - Id3: string - Id3Name: string - OrganizationId (FK): int - OriginId: string - OriginSourceId (FK): int - PackageLogId (FK): int Figur 3 - Log database Samling og tidsmåling af pakkeeksekvering (PackageLog) For at sammenbinde udførslen af en konverteringspakke findes der en PackageLog. En post i denne tabel oprettes før eksekvering af en pakke starter og opdateres umiddelbart efter eksekveringen er gennemført. Denne log muliggør at måle på, hvor lang tid eksekveringen af en pakke tager. Denne log bruges i særdeleshed af tekniske årsager, så vi kan lave performance målinger på konverteringsprogrammellet ned til den enkelte pakke. Ydermere benyttes primær nøglen for denne log også til at lave rapportering og afstemning som beskrives i Afstemning og rapportering (VerificationLog) En beskrivelse af felter kan ses Tabel 4 PackageLog felter, og flowet for hvordan en post i PackageLog oprettes kan ses på Figur 4 PackageLog flow. Felt Indhold Id OrganizationId PacakgeName Starttime Endtime Primær nøgle for PackageLog Reference nøgle til Organizations-tabellen svarende til ejer af data Navnet på den eksekverede pakke. Tidstempel for hvornår eksekvering af pakken startede Tidstempel for hvornår eksekvering af pakken sluttede 2020 Netcompany Side 14 af 69

15 MasterLogId Reference nøgle. Referere en anden post i PacakgeLog. Dette bruges til samle vores tre overordnede behandlings flows (2.7) Tabel 4 PackageLog felter Pakken starter PacakgeLog post oprettes og der angives starttidspunkt Pakkens indhold eksekveres PackageLog post opdateres med sluttidspunkt Pakken slutter Figur 4 PackageLog flow Overførsel af unikke nøgler (UniqueLog) [KO-13] Logs for overførsel af unikke nøgler oprettes i en tabel kaldet UniqueLog. Denne log binder primærnøgler fra SIS til primær nøgler i, hvilket gør det muligt at fremsøge data systemerne imellem efter en konvertering. En beskrivelse af felterne i denne log er beskrevet i Tabel 5 - UniqueLog felter. Felt Indhold Id Created Primær nøgle for UniqueLog. Tidsstemple for hvor rækken er oprettet. OriginId Primær nøgle af posten inden konvertering. Denne nøgle vil i de fleste tilfælde være en primær nøgle i en SIS-tabel, eller en fil som indlæses. Vær opmærksom på, at i nogle tilfælde er denne sat til en kombination af ID er i SIS eller selvkonstruerede primær nøgler i filer. OriginSource Dette vil i de fleste tilfælde angive en SIS-tabel og et ID-feltnavn, men kan også være navnet på filer som indlæses for alle institutioner. Hvis OriginId er en kombination af flere ID er i SIS, vil det fremgå af navnet på posten i Sources tabellen, fx er Source til oprettelse af GUEr fra Bedømmelser angivet som KARAKTERER(ELEV_ID, SKFA_ID) med ID [ELEV_ID]- [SKFA_ID] DestinationId DestinationSource Organization PackageLog Id1 Id1Name Id2 Id2Name Id3 Id3Name Primær nøgle for posten efter konvertering, en GUID i en -tabel. Hvilken -tabel (hvilken entitet) denne er placeret i efter konvertering. Den institution rækken er konverteret for, som derved også er blevet ejer af de data der er oprettet. Hvilken konverterings pakke denne post er oprettet igennem. Felt til at tilknyttet ID er som kan bruges til at identificerer rækken på foruden originid. Feltnavnet for ID1 Felt til at tilknyttet ID er som kan bruges til at identificerer rækken på foruden originid. Feltnavnet for ID2 Felt til at tilknyttet ID er som kan bruges til at identificerer rækken på foruden originid. Feltnavnet for ID3 Tabel 5 - UniqueLog felter 2020 Netcompany Side 15 af 69

16 Der oprettes poster i denne log i de fleste af konverteringspakker. Dette sker dog kun for poster som læses, transformeres og oprettes med succes i. Generelt vil poster i UniqueLoggen blive oprettet jf. flowet i Figur 5 - UniqueLog flow. Læs data fra SIS Tilpas og transformer felter til Kan data transformeres? Nej Fejhåndtering Ja Opret post i Oprettet successfuldt? Nej Ja Skriv til UniqueLog Figur 5 - UniqueLog flow Behandling og fejlhåndtering (EventLog) [KO-2] For at kunne tracke og logge udfaldet for alt data, der læses fra SIS og andre kilder, oprettes poster i vores EventLog. Denne log bruges til at registrere, hvad der sker for den enkelte post og tilknytte en besked, som er specielt gavnlig ved logs, hvor resultatet ender med advarsler eller fejl. En beskrivelse af felterne i EventLog kan findes i Tabel 6 - EventLog felter Felt Indhold Id Created OperationId Message OriginId OriginSourceId Primær nøgle for EventLog Tidsstemple for hvornår rækken er oprettet. Nøgle i Operations-tabellen som beskriver udfaldet af rækken. Operations beskrives yderligere i afsnit Operations. Besked, som skaber kontekst til log posten og dens operation. Eksempelvis: The person with PERS_ID has been ignored because it has been filtered as inactive, and not relevant for the data migration. Primær nøgle af posten inden konvertering. Denne nøgle vil i de fleste tilfælde være en primær nøgle i en SIS-tabel, eller en fil som indlæses. Vær opmærksom at i nogle tilfælde er denne sat til en kombination af Id er i SIS eller selvkonstruerede primær nøgler i filer. Referencenøgle til Sources-tabellen svarende til datakilden. Dette vil i de fleste tilfælde angive en SIS-tabel, men kan også være navnet på filer som indlæses for alle institutioner Netcompany Side 16 af 69

17 DestinationId DestinationSourceId OrganizationId PackageLogId TraceCodes Primær nøgle af posten efter konvertering, en GUID i en -tabel. Referencenøgle til Sources-tabellen svarende til datadestinationen, altså hvilken -tabel (hvilken entitet) denne er placeret i efter konvertering. Referencenøgle til Organizations-tabellen. Den institution rækken er konverteret for, som derved også er blevet ejer af de data der er oprettet. Referencenøgle til PackageLog, der beskriver, hvilken konverteringspakke denne post er oprettet gennem. En liste af koder, som beskriver rækkens forløb gennem flowet. Tabel 6 - EventLog felter Operations For at beskrive udfaldet af den enkelte række bruges et koncept, vi kalder Operations. Disse operationer beskriver forskellige udfald af en enkelt række. En beskrivelse af operationer og deres definitioner kan ses i Tabel 7 - Log operationer. Operation Read Create Update Map Warning Ignore Error Duplicate Share Delete Definition Rækken blev læst. Dette er den eneste operation, som aldrig annoteres på poster i EventLog, men bruges udelukkende til VerificationLog til optælling/afstemning. Rækken fra SIS er oprettet i Hvis posten i et tidligere flow er blevet oprettet og nu opdateres uden fejl. Der oprettes ingen post i, men der mappes derimod til et id i for en post som er præoprettet. Eksempelvis mappes KARAKTERVARDI i SIS til Karakter i som er centralt oprettet inden institutions data konverteres. Altså når der skiftes fra institutions styret til centralt styret data. Opmærksomhedspunkt, denne række er oprettet eller opdateret, men ikke som ønsket formentlig grundet manglende data i SIS eller lign. Forretningsregler for hvilke data, der skal medtages i konverteringen udelukker denne række fra at blive behandlet. Dette kan både være direkte ignorering, eksempelvis at vi kun konverterer studieforløb fra elever som er aktive i SIS. Eller indirekte at vi kun opretter bedømmelser, hvis vi tidligere har oprettet et studieforløb. Rækker med ignore bryder ud af flowet og oprettes ikke i. (Læs mere i afsnit 3). Alvorlig fejl. Udfaldet på rækken er forkert og kan ikke behandles. Rækker med error bryder ud af flowet og oprettes ikke i Hvis en post allerede findes i, og derfor ikke skal oprettes igen. Rækker med Duplicate bryder ud af flowet og oprettes ikke i Share bruges på poster, som er blevet delt med flere institutioner. Rækken i er blevet slettet. Denne operation bruges i forbindelse med oprydning i data. I forbindelsen med, at data slettes bliver den tilhørende række i UniqueLog-tabellen fjernet. Tabel 7 - Log operationer Det skal understreges at en række godt kan skifte operation i løbet af et flow. Altså status på behandlingen af en række kan godt skifte. Eksempelvis vil en række som umiddelbart skulle markeres som en Warning, fordi man ikke kunne finde noget refereret data godt blive markeret med en Error, hvis oprettelsen af selve posten fejlede Netcompany Side 17 af 69

18 På Figur 6 vises der et eksempel på eksekvering af en pakke, som illustrerer, hvorledes de forskellige operationer markeres. Bemærk at dette flow udelader Update og Map. Flows for disse vil være meget lig dette, dog vil man i et Update flow sjældent lave Duplicate tjeks. Figur 6 EventLog flow Afstemning og rapportering (VerificationLog) [KO-10] Som opsummering på en konvertering, skrives til VerificationLog. Denne log er med til at afstemme, hvor mange poster fra SIS, der læses samt, hvor mange af disse poster, som oprettes, ignoreres etc. Indholdet i denne tabel er en opsummering af eventlogs og en tælling på antal rækker læst for hver pakke. En beskrivelse af felterne i VerificationLog kan findes i Tabel 8 - VerificationLog felter. Felt Beskrivelse Id OperationId Primær nøgle for VerificationLog Nøgle til operations-tabellen som beskriver udfaldet af rækken. Beskrives yderligere i afsnit Netcompany Side 18 af 69

19 OriginSourceId DestinationSourceId OrganizationId PackageLogId Amount Referencenøgle til sources-tabellen, der fortæller datakilden. Dette vil i de fleste tilfælde angive en SIS-tabel, men kan også være navnet på filer, som indlæses for alle institutioner. Referencenøgle til sources-tabellen svarende til datadestinationen, altså hvilken -tabel (hvilken entitet) denne er placeret i efter konvertering. Referencenøgle til Organizations-tabellen. Den institution rækken er konverteret for, som derved også er blevet ejer af de data der er oprettet. Referencenøgle til PackageLog, der beskriver, i hvilken konverteringspakke denne post er oprettet. Antallet af poster påvirket af operation. Eksempelvis hvor mange poster, der er oprettet. Tabel 8 - VerificationLog felter Der oprettes en række per pakke, per operation som pakken resulterer i fra EventLog. Foruden dette oprettes der altid en række med antallet af rækker, der trækkes ud af SIS-tabellen. Med andre ord fungerer Read rækken i VerificationLog, som en slags opsummering af antallet af rækker i Eventloggen, og fortæller, hvor mange rækker der læses. Et eksempel på indholdet af VerificationLog for en pakke, som læser fra ELEVER-tabellen i SIS og opretter Studieforløb (i tabellen dbo._studieforloeb) Kan ses i tabel 8. I dette eksempel læses der 1250 rækker i SIS, hvor 980 af dem oprettes som forventet. 250 ignoreres som et resultat af data afgrænsning (afsnit 3) og 20 af posterne mødte ikke afbrydende, men potentielle fejl, der er markeret med en warning. Operation Amount OriginSource DestinationSource Organization Read 1250 ELEVER(ELEV_ID) NULL Create 980 ELEVER _studieforloeb Ignore 250 ELEVER _studieforloeb SIMAC, Svendborg International Maritime Academy SIMAC, Svendborg International Maritime Academy SIMAC, Svendborg International Maritime Academy Warning 20 ELEVER _studieforloeb Accepteret fejl i SIS-data Tabel 9 - VerificationLog eksempel SIMAC, Svendborg International Maritime Academy I forbindelse med konverteringen kan der blive genereret fejl, som bliver udløst af fejl eller mangler i opsætning af data i SIS. Dette kan også skyldes et bevidst fravalg af opsætningen fra institutionerne som en måde at fravælge at data konverteres fra SIS til. I begge tilfælde vil ovenstående blive registeret som en fejl i EventLog, da der er data som ikke kan oprettes. Institutionerne vil gennem prøvekonverteringer blive gjort opmærksomme på disse fejl og givet mulighed for at udbedre dem inden den endelige konvertering til. Det betyder, at der i konverteringen kan fremtræde falske positive i loggen. I Tabel 10 nedenfor er angivet en liste over hvilke fejl der ved gennemgang af konverteringen vil blive set bort fra. Entitet Message TraceCode PackageName Type Gennemførselsuddannelseselement FAGUDD with SKFA_ID: XXXX and UDDA_ID: YYYY and UDDANNELSESKODE ZZZZ cannot be found. The course is not setup in S412 on a uddannelsesordning with that uddannelseskode Tabel 10 - Fejlbeskeder som betragtes som accepteret fejl 004 MainCreateGUE Error 2020 Netcompany Side 19 af 69

20 Som en konsekvens af de accepteret fejl, vil konverteringen af entiteter som er afhængige af disse poster blive ignoreret, da data ikke kan findes i. 3 Dataafgrænsning I dette afsnit beskrives hvordan data afgrænses ved konverteringen. De mere detaljerede regler for dataafgrænsning for hver enkelt entitet kan se i tabellen nedenfor. Afgrænsningen af historisk data til konvertering er fastlagt i samarbejde med SIU, med feedback fra pilotinstitutionerne, til følgende: o Alle aktive studerende på en ordinær uddannelse Alle studieforløb, der er afsluttet inden for konverteringsåret og 2,5 år bagud Alle studieforløb indeholdende en karakter givet inden for konverteringsåret og 2,5 år bagud Alle studieforløb, der er påbegyndt inden for konverteringsåret og 6,5 år bagud baseret på indskrivningsdato af hensyn til mulig genindskrivning. o o o For åben uddannelse konverteres data for studerende tilmeldt gyldige UVM uddannelseselementer med en startdato inden for de seneste 6 år, da uddannelsen ifølge bekendtgørelsen skal være afsluttet senest 6 år efter, at den studerende er påbegyndt uddannelsen. For IDV uddannelser konverteres data for aktive studerende og gennemførelsesuddannelseselementer med en holdplacering med startdato efter den 1/1/2019. Begrænsningen kan foretages, idet disse data ikke er bevaringsværdige af myndighedsårsager, men blot ønsket af institutionerne til statistiske formål. For alle typer studerende gælder det, at den studerendes uddannelse i SIS skal have tilkoblet en central uddannelseskode og at denne uddannelseskode skal være opsat af SIU i som uddannelsesaktivitet, for at den studerende kan blive konverteret. Alle historiske data fra SIS vil efter konverteringen blive gjort tilgængelige for de enkelte institutioner i første omgang som læseadgang til SIS og på sigt som dataudtræk. Dataområde Underområde Beskrivelse Følgende gælder for konvertering på tværs af forskellige typer studieforløb: Generelt Studieforløb med central afgangsårsag 3 (ikke påbegyndt uddannelsen) konverteres ikke. Studieforløb markeret som "Testperson" konverteres ikke. Studieforløb Den studerendes uddannelse i SIS har tilknyttet en central uddannelseskode, som er opsat af SIU i som en uddannelsesaktivitet. Mindst en af følgende betingelser skal være opfyldt, før et studieforløb på ordinær uddannelse konverteres: OU Studieforløbet er aktivt. Studieforløbet er afsluttet indenfor løbende år 1 + 2,5 år. o Eksempel: Ved konvertering 1. oktober 2020, er skæringsdato for data 1. juli Løbende år = Kalenderåret, hvori der konverteres 2020 Netcompany Side 20 af 69

21 Dataområde Underområde Beskrivelse Seneste karakter på studieforløbet er indenfor løbende år + 2,5 år. o Eksempel: Ved konvertering 1. oktober 2020, er skæringsdato for data 1. juli 2017 Påbegyndt løbende år + 6,5 år baseret på indskrivningsdatoen angivet i feltet Påbegyndt uddannelse i SIS skærmbilledet S294 Studerende o Eksempel: Ved konvertering 18. oktober 2020, er skæringsdato for data 1. juli 2013 ÅU Studieforløbet har haft mindst én holdplacering på et fag opsat på studieforløbets uddannelse, hvor holdplaceringens startdato er indenfor 6 år fra konverteringstidspunktet. Eksempel: Ved konvertering 1. oktober 2020, er skæringsdato for data 1. oktober 2014 IDV Studieforløbet har haft mindst én holdplacering på et IDV fag opsat på studieforløbets uddannelse, med startdato på eller efter IDV konverteres kun for uddannelser med én af følgende aktivitetsgruppekoder: 9999 IV-kurser Specialsygeplejerske i kræftsygepleje Specialsygeplejerske i borgernær sygepleje. Personer Generelt Personer konverteres, hvis de har mindst et studieforløb, der overholder betingelserne for konvertering. Generelt Uddannelsesaktiviteter er centralt defineret af SIU, og er opsat direkte i af SIU. OU Uddannelsesaktiviteterne der er opsat i, er baseret på et udtræk af konverteringsrelevante studerende i SIS, ud fra de definerede afgrænsninger for Studieforløb ovenfor i dette skema. Uddannelsesaktiviteter ÅU Uddannelsesaktiviteterne der er opsat i, er baseret på de aktivitetsgruppekoder der har været tilknyttet fag i Takstkataloget fra 2013 og frem. Der er opsat uddannelsesaktiviteter for IDV for følgende aktivitetsgruppekoder: IDV 9999 IV-kurser Specialsygeplejerske i kræftsygepleje Specialsygeplejerske i borgernær sygepleje. Uddannelsesstruktur Generelt OU Uddannelsesstrukturer konverteres fra uddannelser i SIS, hvis der er opsat en tilsvarende uddannelsesaktivitet i. Uddannelsesaktivitet skal have samme aktivitetsgruppekode, delformål, DST-kode, SU-retningskode og DS-retning (Uddannelsesform i ) Netcompany Side 21 af 69

22 Dataområde Underområde Beskrivelse ÅU IDV OU Uddannelsesaktivitet skal have samme aktivitetsgruppekode, delformål, DST-kode, SU-retningskode og DS-retning (Uddannelsesform i ). Uddannelsesaktivitet skal have samme aktivitetsgruppekode. Fag på ordinær uddannelse konverteres til SUEr, for de uddannelser, hvor der er konverteret en uddannelsesstruktur, og hvor faget er opsat i S412. Fag på åben uddannelse konverteres til SUEr, for de uddannelser, hvor der er konverteret en uddannelsesstruktur. Derudover skal én af følgende betingelser være opfyldt: SUE ÅU Faget i SIS skal have tilknyttet et UVM-fag, og UVM-fagkoden på faget skal matche en gyldig UVM-fagkode i. Gyldige UVM-fagkoder bestemmes af SIU og har i forbindelse med konverteringen været de fag, der har fremgået i Takstkataloget fra 2013 og frem. Åbne uddannelser af blandt andet typen Enkeltfag, Meritlærer eller Meritpædagog, skal have opsat fagene i S412. Den fulde liste af aktivitetsgruppekoder, som håndteres på denne måde for åben uddannelse, er vist i afsnit 8.1. IDV Fag på IDV konverteres til SUEr, for de uddannelser hvor der er konverteret en uddannelsesstruktur, og hvor faget er opsat i S412 med én af følgende aktivitetsgruppekoder: 9999 IV-kurser Specialsygeplejerske i kræftsygepleje Specialsygeplejerske i borgernær sygepleje. Følgende betingelser gør sig gældende for konvertering af PUEr på tværs af uddannelsestyper: PUE konverteres, hvis aktiviteten er aktiv, dvs. slutdato er efter konverteringstidspunktet. PUE Generelt PUE konverteres, hvis aktiviteten er planlagt, dvs. både startdato og slutdato efter konverteringstidspunktet. PUE konverteres, hvis faget er opsat på uddannelsesordningen i S412. Alternativt skal faget været opsæt på en uddannelsesordning med samme aktivitetsgruppekode. Den tilhørende SUE skal være konverteret. Aflyste aktiviteter konverteres ikke. OU ÅU Der konverteres kun PUEr fra aktiviteter, med mindst én holdplacering. For åben uddannelse, vil der blive konverteret yderligere PUEr baseret på følgende betingelse: Aktiviteten har været aktiv indenfor forrige 2020 Netcompany Side 22 af 69

23 Dataområde Underområde Beskrivelse indberetningsperiode i forhold til konverteringsdatoen. Oprettes for aktiviteter med startdato fra og med og frem, dvs. også afsluttede aktiviteter. IDV Der konverteres kun aktiviteter på IDV-uddannelser med en af følgende aktivitetsgruppekoder: 9999 IV-kurser Specialsygeplejerske i kræftsygepleje Specialsygeplejerske i borgernær sygepleje. Et konverteret OU studieforløb får oprettet GUE for et fag, hvis følgende betingelser gælder: OU Faget er opsat i S412 på den studerendes uddannelse eller en anden uddannelse under samme aktivitetsgruppekode og der er oprettet en SUE i for faget. Den studerende har en planlagt eller aktiv holdplacering. Derudover skal der være oprettet en PUE for den specifikke aktivitet og skolefag. Den studerende har en bedømmelse, merit eller et praktikophold på faget. GUE Et konverteret ÅU studieforløb får oprettet GUE for et fag, hvis en af følgende betingelser gælder: ÅU Den studerende har en holdplacering for faget, hvor startdato på holdplaceringen er indenfor 6 år fra konverteringstidspunktet. Den studerende har en bedømmelse på faget, hvor bedømmelsesdato er indenfor 6 år fra konverteringstidspunktet. IDV Et konverteret IDV studieforløb får oprettet GUE for et fag, hvis følgende betingelse gælder: Den studerende har en holdplacering på faget med startdato på eller efter , og der skal være oprettet en PUE. Bedømmelser Bedømmelser med karakterværdier, der ikke er mappet i de institutionsspecifikke mappingark, vil ikke blive konverteret. Meritter Meritter med karakterværdier, der ikke er mappet i de institutionsspecifikke mappingark, vil ikke blive konverteret. Meritter uden karakterværdi vil blive oprettet. Praktikophold Praktikophold skal have et tilknyttet skolefag/fagindhold. Endelig indstilling skal være forskellig fra Adm. Annulleret. Studieinaktiv periode Studieinaktive perioder med årsager, der ikke er mappet i de institutionsspecifikke mappingark, vil ikke blive konverteret. Studieinaktive perioder med samme start- og slutdato vil ikke blive konverteret i henhold til gældende forretningsregler Netcompany Side 23 af 69

24 Dataområde Underområde Beskrivelse SU-hændelser UngeDB-hændelser SU-Hændelser skal være af typen 'INDSKRIVNING', 'OPHØR, ORLOV og status skal være enten 'MANUEL' eller 'OK' og der skal være kommet en response XML. Hvis der er SU-hændelse for studerende på gl. regler, så opdateres studieforløbet med: Kontrolstatus sættes til SU-inaktiv, Kontroldato og Ændringsdato til SU. Status skal være 'OK' eller 'OK - SE MEDD.' Adgangsgrundlag Stamdata Enkeltfag Adgangsgrundlaget konverteres for aktive studerende. Enkeltfag konverteres for aktive studerende på en ordinær uddannelse. Der konverteres udelukkede faktureringsgrundlag og faktureringsgrundlagslinjer for ÅU, som ikke er indberettet og står til at skulle indberettes for indeværende indberetningsperiode på konverteringstidspunktet. Faktureringsgrundlag og faktureringsgrundlagslinjer ÅU Der konverteres ikke beløb og debitorer. Der konverteres ikke kreditnotaer eller tilhørende faktureringsgrundlag og faktureringsgrundlagslinjer, da disse ikke er interessante for indberetningen. Der konverteres ikke faktureringsgrundlag og -linjer for aktiviteter, med hak i Ej Opkrevning i SIS Publiceringer Hold Ved konvertering oprettes der én publicering per konverteret PUE. Der oprettes ét hold per PUE der konverteres. Der konverteres kun STÅ indberettet fra og med perioden med startdatoen STÅ indberetninger OU Hvis den studerendes studiestartsdato ligger før indberetningsperiodens startdato konverteres denne indberetning ikke. Rekvirenter Der konverteres kun aktive og fremtidige rekvirenter. 4 Funktionelle områder [KO-8, KO-2] I dette afsnit vil det detaljerede design for konverteringen blive beskrevet og udvidet, efterhånden som det bliver udspecificeret i løbet af projektet. Afsnittet vil i første omgang indeholde et udkast til, hvilke tabeller fra SIS der skal konverteres, og hvor i disse tabeller er planlagt at blive konverteret til. Dette vil senere blive udvidet til at beskrive de konkrete attributter der skal konverteres, regler for konverteringen af de enkelte felter og regler for konvertering af unikke nøgler. Det er også i dette afsnit det vil blive beskrevet, hvis flere tabeller fra SIS skal kombineres og konverteres til én tabel i, eller omvendt hvis én tabel i SIS skal opdeles og konverteres til flere tabeller i. Det er også i dette afsnit, at regler for datavask bliver beskrevet, både automatisk datavask i forbindelse med konverteringen, men også eventuel manuel datavask som skal foretages inden konvertering Netcompany Side 24 af 69

25 Endelig vil der også i dette afsnit fremgå, hvilke forretningsregler, som de forskellige data valideres imod. Alle regler relateret til konverteringen, forventes at blive forbedret løbende, efterhånden som flere prøvekonverteringer og delkonverteringer foretages. Som en del af rapporten som dannes ved afslutning af en konvertering, så vil der fremgå, hvilke regler der er valideret imod. Dette gøres ved at udtrække alle datamappingregler og datatransformationsregler fra Toolkit listerne Datamappinger og Datatransformationsregler inden konverteringen køres, så øjebliksbilledet af regler for en given konvertering er gemt. Derudover vil opsætningen af konverteringsmotoren blive gemt med versionskontrol, så der er fuld historik på de ændringer der er foretaget, og at gamle versioner af opsætningerne kan hentes frem ved behov. 4.1 Mappinger Nedenfor er en tabel med forklaringer og eksempler på data i de enkelte kolonner i listen af Datamappinger på toolkit. Den komplette liste med mappinger vil blive placeret på projektets Toolkit, og kan her filtreres efter forskellige parametre, og udtrækkes til brug i konverteringsmotoren. Kolonne navn Format Forklaring Eksempel SIS Skærmbillede Tekst Angiver nummer på et skærmbillede, hvor data for et specifikt felt vises S412 SIS Skærmbillede Felt Tekst Angiver navnet på feltet, i det skærmbillede som er angivet Semester SIS Datatype Tekst Angiver datatypen på feltet i SIS Tal SIS Tabelnavn Tekst Angiver navnet på den bagvedliggende tabel i SIS databasen, hvor feltet hentes fra SKOLEPERIODER SIS Logisk Feltnavn Tekst Angiver det logiske navn på feltet i den tabel der er angivet SKOLEPERIODE Datatype Tekst Angiver datatypen på feltet i, som bliver udfyldt ved at anvende data fra feltet i SIS Tal Logisk Entitet Tekst Angiver det logiske navn på entiteten i datamodel _uddannelseselement Entitetsnavn Tekst Angiver visningsnavnet på entiteten i datamodel Strukturelt uddannelseselement Logisk Feltnavn Tekst Angiver det logiske navn på feltet i _semester_nummer Esas Feltnavn Tekst Angiver visningsnavnet på feltet i Semester Konverteringspakke Tekst Angiver hvilken konverteringspakke i konverteringsprogrammet, hvor denne datamapping anvendes MainCreateFagSUEr Transformationsregel Link Linker til en transformationsregel, der beskriver specielle anvendelser af data til konverteringen, dvs situationer hvor data ikke overføres en-til-en Tabel 11 - Forklaring af datamappingliste GUE.Studieforløb.opslag 4.2 Afhængigheder til konverteringen I forbindelse med byg af, opsætning af konverteringsmotoren og planlægning af fremtidige konverteringer, skal der skabes et omfattende overblik over afhængigheder i systemet, som vil blive påvirket af at der foretages en konvertering. Når overblikket over afhængigheder er skabt, skal der for hver enkelt afhængighed angives, hvad der skal gøres før, under og efter konverteringen i forhold til afhængigheden, fx: 2020 Netcompany Side 25 af 69

26 Er det en kørsel/integration der skal deaktiveres ved opstart? o o Er der nogle tidspunkter hvor kørsel/integration ikke kan deaktiveres, fx pga. igangværende kørsler/indberetninger? Alternativt, hvordan sikres det at stoppede igangværende kørsler/indberetninger fortsætter korrekt når de startes op igen. Hvis ikke kørsel/integration deaktiveres, hvilke konsekvenser har konverteringen så på brugen af denne kørsel/integration? Hvornår kan funktionaliteten genaktiveres efter afsluttet konvertering? Skal der foretages noget manuelt før, under eller efter konverteringen, for at genaktivere funktionaliteten efter afsluttet konvertering? o Herunder specielt om der skal foretages noget manuelt i lokale systemer hos institutionen, før forbindelsen mellem lokale systemer og kan etableres efter konverteringen. Disse spørgsmål, samt flere, skal besvares og indarbejdes i konverteringsplanen for blandt andet følgende områder: Lokale integrationer Centrale integrationer Planlagte kørsler Indberetninger SU Økonomiske transaktioner i Navision STAT 4.3 Plugins og workflows Mange plugins og workflows bliver i eksekveret synkront, hvilket gør, at for hver post konverteringsprogrammellet enten oprettet eller opdaterer vil skulle afvente færdigbehandlingen af disse inden næste post kan behandles. Konsekvensen af dette er et stort fald i performance og en uforholdsmæssig lang eksekveringstid af hele konverteringen. For at sikre den bedst muligt performance vil alle plugins og workflows opsat i være deaktiveret i forbindelse med en konvertering. Nødvendige valideringer implementeres i stedet direkte i konverteringsmotoren. Ligeledes vil tilslutningen til alle integrationer og 3. parts systemer i perioden for konverteringen være lukket. 4.4 Konverteringsopsætning [KO-1] I denne sektion vil det blive beskrevet, hvordan de enkelte dataområder bliver konverteret. Der er et afsnit for hvert enkelt dataområde, med figurer der illustrerer de anvendte tabeller i kildesystemet og i destinationssystemet. For hele konverteringen kan der forekomme afgrænsning af det konverteret data. I [D0170.1] er de grundlæggende principper for datakonverteringen fra det eksisterende SIS til det kommende. Det anbefales derfor at være orienteret i hhv. [D0170.1] samt afsnit 3 Dataafgrænsning, der beskriver afgrænsningerne for datakonverteringen. I de følgende afsnit vil vi beskæftige os med forskellige entiteter, og hvordan de konverteres fra nuværende SIS. Bemærk at en del af disse entiteter er afhængige af, at andre entiteter er konverteret ind først. Tilsvarende vil der være en bestemt rækkefølge af efterbehandlingspakkerne. Vi henviser her til afsnit 2.7 hvor afhængigheder pakkerne imellem i de tre behandlings flows er beskrevet Netcompany Side 26 af 69

27 4.4.1 Metadata Statisk data er det data der er statisk på indlæsningstidspunktet og typisk heller ikke vil blive ændret efter det er blevet konverteret til. I dette afsnit vil vi gennemgå disse områder. Lande Vi indlæser lande centralt, for at sikre en ensartet liste af lande i. Dette sker som en del af forbehandlingen. Her indlæses data fra en CSV-fil fra cpr.dk og ind i. Filen indeholder data såsom Landenavn og Landekode, som bruges til at standardisere lande i. Hvis landet ikke findes i allerede, oprettes det, ellers ignorerer flowet landet Datamapping En komplet liste over hvordan dataene transformeres over i kan findes i Toolkit på følgende link: Mapping af Lande. Postnumre Vi indlæser postnumre centralt, for at sikre en ensartet liste af postnumre i. Dette sker som en del af forbehandlingen. Her indlæses data fra en CSV-fil, der er hentet direkte fra PostNord, ind i. Filen indeholder data såsom Postnummer, Bynavn og Gade. Dette bruges til at standardisere postnumre i. De indlæste postnumre i dækker kun postnumre i Rigsfællesskabet Datamapping Postnumrene indlæst fra PostNord ønskes mappet præcist med manuelt oprettede postnumre i SIS. Da postnumrene i SIS er manuelt oprettet, kan der være forskel i måden et postnummer (De kan f.eks. være præfixet lande kode, eks. FO- 100) og postdistrikt (forskellige stavemåde, slåfejl mv.) er skrevet i SIS og. Fordi der er en væsentlig mængde postnumre som ikke matcher 1 til 1, er det besluttet at lave en forskelsberegning mellem de to systemers postnumre. Dette gøres primært, fordi der er mange poster i POSTNUMMER tabellen, hvor en stor del reelt matcher 1 til 1 og de resterende er tæt på. For ikke at sætte institutionerne til at mappe hele denne tabel beregnes førnævnte forskel. Der benyttes en n-gram algoritme som sammenligner postnumre fra SIS mod postnumre i på en skal fra 0 til 100%. Efter inspicering af denne forskelsberegner, er der valgt en grænseværdi på 80% ensartethed. Det betyder, hvis et postnummer i SIS ligner et postnummer i med 80%, så accepterer vi den datamapping og bruger den fremadrettet. Ved et match på mindre end 80% anses det som, at der ikke kunne findes et match. Postnummeret vil i stedet blive sat som en del af adressen. På den måde sikres det, at udenlandske postnumre samt postnumre, hvor der ikke kunne findes et match på postnumre i, fortsat bliver konverteret En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af Postnumre. Virksomheder (Institutionsregisteret) Institutioner/Virksomheder minder i nogen grad om SIS. Dog indlæses data omkring Virksomheder (Institutionsregisteret) centralt i og konverteres derfor ikke fra SIS. Derudover oprettes der i både selve institutionen og en juridisk enhed til en institution. Institutioner/Virksomheder er en del af Institutionsregister-flowet, som er en del af PreFlow pakken. Her loades der data ind fra en CSV-fil, som indeholder data såsom institutionsnavn, nummer og vejnavn. Denne CSV-fil er et udtræk fra institutionsregisteret. Hvis en virksomhed eller kommune er blevet nedlagt/fjernet, ignoreres denne i flowet. Det sikres også at der kun bliver oprettet én juridisk institution per CVR-nummer. Institutionerne/Virksomhederne oprettes derefter i. En simplificeret udgave af hovedbehandlings-flowet for Virksomheder er vist på Figur Netcompany Side 27 af 69

28 Pakke starter Er institution nedlagt før 2013? Er institutionen en kommune eller uden CVRnummer? Nej Nej Opret institution Pakken sluttet Ja, ignorer Ja, ignorer Figur 7- Oprettelsen af virksomheder Datamapping En komplet liste over hvordan dataene transformeres over i kan findes i Toolkit på følgende link: Mapping af Virksomheder. Afdelinger og Teams Indlæsning af Afdelinger og Teams foregår, for at bevare institutionernes afdelingsstruktur. Data til indlæsning af Afdelinger og Teams kommer fra en CSV-fil, som er udarbejdet af SIU med udgangspunkt i Institutionsregistret. Første del af flowet opretter Teams i, baseret på afdelingerne i filen. Hvis Teamet for en given afdeling findes i forvejen, ignoreres afdelingen i denne del af flowet. Hvis den juridiske enhed til afdelingen ikke findes, så logges der en fejl, men flowet fortsætter for de resterende afdelinger. Teams oprettes herefter i. Næste del af flowet opretter de enkelte Afdelinger, og tilkobler de teams der er oprettet tidligere i flowet. Hvis en afdelings team eller juridiske enhed ikke findes, logges der en fejl, men flowet fortsætter for de resterende afdelinger. Herefter oprettes Afdelingen i, med den juridiske enhed og Team tilknyttet Underafdelinger fra institutioner Institutionsafdelinger kan have en eller flere underafdelinger tilknyttet. Underafdelingerne dannes på baggrund af et mappingark, som tager afsæt i aktivitetsafdelinger i SIS. Aktivitetsafdelingerne mappes til et institutionsnummer på en af institutionens afdelinger, som de herefter oprettes under i. Underafdelinger anvendes efterfølgende som aktivitetsafdeling på planlægningselementer Netcompany Side 28 af 69

29 Figur 8 Afdelinger hovedbehandlings flow Datamapping En komplet liste over hvordan dataene transformeres ind i kan findes i Toolkit på følgende link: Mapping af Afdelinger og Team SIU ejede Uddannelsesstrukturer I oprettes der SIU-ejede uddannelsesstrukturer ud fra de aktivitetsgruppekoder, der fremgår af den version af takstkataloget, der benyttes i konverteringen. Disse oprettes, så UVM-fagene efterfølgende kan knyttes til den relevante uddannelsesstruktur. Uddannelsesstrukturerne oprettes med SIU som ejer, hvis en uddannelsesaktivitet med samme aktivitetsgruppekode er oprettet. Uddannelsesstrukturen sættes til uddannelsestypen Åben Uddannelse. En simplificeret udgave af behandlings flowet kan ses nedenfor 2020 Netcompany Side 29 af 69

30 Figur 9 - SIU ejede uddannelsesstrukturer Datamapping En komplet liste over hvordan dataene transformeres ind i kan findes i Toolkit på følgende link: Mapping af Uddannelsesstrukturer UVM-Fag UVM-fag minder om UVM-fag i SIS, der ligger i SIS-F. I oprettes de baseret på et ark med data fra takstkataloget samt nedlagte UVM-fag. Arket er udarbejdet af SIU, for at sikre at relevante UVM-fag konverteres. UVM fag bruges til ÅU SUEr, da disse knyttes til et UVM-fag Forbehandling Før konverteringen af UVM-fag, udfylder SIU et ark med UVM-fag, der fortsat er relevante at få konverteret over i, så SUEr på ÅU kan relatere her til. Dette ark skal indeholde både aktive og nedlagte UVM-fag Hovedbehandling I hovedbehandlingen af UVM-fag indlæses den flade fil med alle relevante UVM-fag. Disse indlæses og kobles til relevant uddannelsesstruktur, som ejes af SIU. Efter de er koblet til strukturen får de sat status alt efter om de er aktive eller nedlagte. En simplificeret udgave af hovedbehandlings flowet kan ses i figuren nedenfor Netcompany Side 30 af 69

31 Pakke starter Load takstkatloget inkl. nedlagte UVM-fag Nej, ignorer Ja Findes uddannelsesaktiviteten i? Nej, ignorer Er SIU uddannelsesstruktur sat op? Ja Opret UVM-fag Pakke sluttet Figur 14 UVM-fag hovedbehandlings flow Datamapning En komplet liste over hvordan dataene transformeres ind i kan findes i Toolkit på følgende link: Mapping af Uddannelsesstrukturer Personer Efter forbehandlingen er det første der konverteres til personer, hvor personoplysninger knyttes til. Personer er i centralstyret og i de følgende to afsnit vil konverteringsstrategien for personer og personoplysninger blive forklaret. Personer Personer i minder i høj grad om personer, som det kendes fra SIS-skærmbilledet A582 Personer. Dog er personer i centralt styret data, hvilket betyder, at personer vil genbruges på tværs af institutioner. En Person kan have tilknyttet personoplysninger som er individuelle for hver institution. Behandlingen af dette er beskrevet i Personoplysninger Hovedbehandling Data til personer i kommer fra tabellen PERSONER i SIS. Det første step i dette flow er at frasortere personer jf. vores dataafgrænsning (3). Alder i udregnes på baggrund af personen CPR-nummer, hvis personen har et fiktivt CPR-nummer i SIS med fødselsdato før år 1900 tilføres 100 år til personens alder. Da flere personer med samme fiktive CPR-nummer kan eksisterer i flere af institutionernes systemer, bliver der i de tilfælde, hvor det fiktive cpr-nummer allerede tidligere er oprettet i, dannet et nyt cpr-nummer med formen xxxx, xxxx er et fortløbende serienummer. Personens fødselsdato beregnes fortsat ud fra datoen for det oprindelige CPR-nummer Netcompany Side 31 af 69

32 Som nævnt, er personer delt på tværs af institutioner, hvorfor vi ikke opretter en person to gange, hvis vedkommende skulle være registreret på to forskellige institutioner. Stamdata på person vil automatisk blive ajourført fra CPR-registeret, hvis de findes i cpr-registeret. Ved konverteringen af personer laves et opslag i på CPR-nummer, hvor der tjekkes om personnummeret allerede er oprettet i. Hvis vedkommende er oprettet i forvejen sikres det, at rækken registreres i loggen for unikke nøgler. Findes CPR-nummeret ikke i i forvejen, oprettes personen. Personer, der kun har studieforløb med afgangsårsag 3 eller kun har studieforløb, der er markeret som testpersoner i SIS konverteres ikke til. En simplificeret udgave af hovedbehandlings-flowet for Personer er vist på Figur 10. Figur 10 - Person hovedbehandlings flow Efterbehandling Efter konverteringen er afsluttet vil alle person bliver kørt op mod CPR-registeret. På den måde sikres det, at alle personer med et validt CPR-nummer, opdateres med de nyeste data registeret i CPR-registeret Netcompany Side 32 af 69

33 Åben uddannelse Åben uddannelse personer bliver konverteret ind baseret på præmissen af, at mindst én af deres GUEr, skal operettes. Ellers følger konverteringen de ordinære personer Datamapping En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af Personer. Personoplysninger Personoplysninger er et koncept i, som minder lidt om kontakter i SIS, til Personoplysninger, trækkes der dog også information fra både Elever og Personer i SIS. Personoplysninger entiteten bruges både til at registrere kontaktoplysninger på medarbejdere og studerende i. Personoplysninger er en af de entiteter, hvor der er lavet individuelle tilpasninger for institutionerne, baseret på mappingfiler Hovedbehandling En simplificeret udgave af hovedbehandlings flowet for Personoplysninger er vist på Figur 11. Figur 11 - Personoplysninger hovedbehandlings flow Inden personoplysninger oprettes, sikres det, at personen, som oplysningerne skal knyttes til, eksisterer i. Feltet _lokalt_studienummer mappes forskelligt for hver institution, da det differentiere, hvilket felt, der er benyttet til dette i SIS. Dette gøres ud fra en mapping fil, som institutionerne har udfyldt forud for konverteringen. Derudover har institutionerne også haft mulighed for, at pege på hvilke felter i SIS, de ønsker konverteret til felterne i. Da der er dubletter på nogle personoplysninger i SIS, udvælger koden den senest opdaterede information fra SIS, før den konverterer til Netcompany Side 33 af 69

34 Personoplysninger indeholder et felt til kaldenavn på personen, men der konverteres ikke data til dette felt i konverteringen Datamapning En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af Personoplysninger Studerende I det følgende afsnit vil vi beskrive konverteringen for de områder der omhandler en studerende og dennes forløb igennem studiet. Dette afsnit forklarer den studerendes forløb som helhed, men også tilmelding og gennemførsel af enkelte elementer i studiet. Det første, der konverteres, er studieforløb, der kobles på en person og efterfølgende gennemførelsesuddannelseselement, studieinaktive perioder, rekvirenter og internationalisering. Studieforløb Studieforløb dannes med afsæt i skærmbillede S294 Studerende i SIS Hovedbehandling En simplificeret udgave af hovedbehandlingsflowet er illustreret Figur 12 i herunder: Figur 12 - Studieforløb hovedbehandling flow Data til konverteringen af studieforløb kommer primært fra elever-tabellen i SIS (skærmbillede S294). Et studieforløb er altid knyttet sammen med en person samt en institutionsafdeling og uddannelsesstruktur gennem et aktivitetsudbud. Der tjekkes derfor altid først om den studerende (person) eksisterer i. Skulle en person ikke eksisterer i, (fx på grund af dataafgrænsning [se afsnit: 3 Dataafgrænsning]) bliver studieforløbet ikke konverteret. Efterfølgende tjekkes der om aktivitetsudbudet er oprettet i. Hvis der er fortaget teknisk studieskift fra et studieforløb til et andet, vil det studieforløb der er fortaget teknisk studieskift fra ikke blive oprettet. Det vil blive logget med reference til det studieforløb, der er lavet teknisk studieskift til, så GUEr samles på det nye studieforløb. Studieforløb som er afsluttet eller afbrudt får tilføjet afgangsårsag og afslutningsdato. I SIS har institutionerne selv kunne vedligeholde en lokal liste af afgangsårsager. Disse mappes til afgangsårsager centralt defineret i ved hjælp af en mapping tabel udfyldt af institutionerne forud for konverteringen. Indskrivningsformen sættes kun på studieforløbet, hvis forløbet knytter sig til en ordinær uddannelse. Hvis studieforløbet er relateret til åben uddannelse sættes indskrivningsformen på de enkelte GUEr. Studieforløb angivet med den centrale afgangsårsag 3 Ikke påbegyndt uddannelsen og studieforløb markeret som en teststuderende i SIS konverteres ikke til. Studieforløbets AUDD-kode konverteres kun i de tilfælde, at der er overensstemmelse mellem AUDD-koden i SIS samt én af de AUDD-koder der er tilknyttet uddannelsesaktiviteten i. Der sættes profil på studieforløbet, hvis der er sat en retning på den studerende i SIS. Hvis der er sat flere retninger på en studerende i SIS, vil retningen med den seneste dato for retningsvalg blive brugt til at sætte profil på studieforløbet i Netcompany Side 34 af 69

35 Efterbehandling Når hovedbehandlingen er afsluttet, eksekveres der et efterbehandlingsjob på studieforløbet. Dette job beregner antallet af ECTS-point, der er opnået på studieforløbet. Dette gøres ved at summere ECTS fra alle beståede gennemførelseselementer, som herefter sættes på studieforløbet. Det samme gøres for fartstid for de martimeuddannelser, hvor fartstiden på alle tilknyttede praktikophold summeres og sættes som samlet fartstid på studieforløbet. I efterbehandlingen af studieforløb, bliver der også markeret om der er en rekvirent på studieforløbet, hvis der er konverteret mindst én rekvirent fra SIS til. Der er ved oprettelsen af personoplysninger blevet konverteret et institutionsvalgt studienummer. Denne information bliver kopieret ind på studieforløbet. Alle studieforløb, som ikke har fået konverteret AUDD-kode fra SIS, vil få tilknyttet uddannelsesaktivitetens AUDD-kode, hvis denne kun har én AUDD-kode. Hvis der er ingen eller flere AUDD-koder tilknyttet uddannelsesaktiviteten vil feltet på studieforløbet efterlades blankt. Derudover bliver studieforløb, der under oprettelsen har fået påsat en afgangsårsag, sat til at være inaktiv Åben uddannelse Der er ikke nogen forskel på oprettelsen af et ordinært studieforløb og et studieforløb på åben uddannelse IDV Studieforløb for IDV oprettes, for de elever der er tilmeldt en uddannelse med central uddannelseskode 5180, 5182 og 9999, og hvor der findes mindst én holdplacering for eleven på IDV uddannelsen, hvor slutdato for holdplaceringen er efter Adgangsgrundlag Adgangsgrundlaget konverteres som en del af studieforløbet og data hentes fra studieforløbets tilknyttet ansøgning i SIS. Data kommer fra tabellen ANSOGNINGER i SIS, og der konverteres kun adgangsgrundlag for aktive studieforløb. Det betyder, at kun studieforløb, der ikke har fået sat en afgangsdato, eller afgangsdatoen er sat til en dato efter konverteringsdagen, vil få konverteret deres adgangsgrundlag. Foruden adgangsgrundlaget konverteres også de enkeltfag, som er knyttet til studieforløbets ansøgning, hvilket vil blive beskrevet i Enkeltfag Teknisk Studieskift maritime værkstedsskoler Studieforløbs-flowet indeholder teknisk studieskift for de maritime værksstedskoler. Studieforløbene der skal laves teknisk studieskift til oprettes via det normale flow, mens de strukturer der flyttes (Værkstedsskolerne) i forbindelse med teknisk studieskift, logges via et separat flow. Logningen af det tekniske studieskift sikrer, at andre processer i konverteringen kan finde studieforløbet i logningen, uden at studieforløbet er oprettes i. Den logges derfor med det ELEV_ID studieforløbet originalt har haft i SIS, men med den GUID der hører til det studieforløb, som den skal flyttes over på. På den måde peger flere studieforløb i logningen mod den samme studieforløb i. Mapningen mellem de nye og de gamle studieforløb hos SIMAC kan ses i tabellen herunder. I tilfælde af at andre mapninger er nødvendige, på andre maritime institutioner, ønskes det afleveres via denne type simple opsætning Netcompany Side 35 af 69

36 Udover disse tre er der tilfælde hos SIMAC hvor elever har udført teknisk studieskift fra 5220 og til Disse bliver dog stadig lagt sammen mod 5220, da det er denne uddannelse der består i. Gammel aktivitetsgruppekode (flyttes fra) Ny aktivitetsgruppekode (flyttes til) Tabel 12 Aktivitetsgruppekoder hvor der fortages sammenlægning af studieforløb Teknisk studieskift øvrige Der håndteres også teknisk studieskift for andre institutioner og aktivitetsgruppekoder, end dem der er nævnt afsnit For disse tekniske studieskift logges der i konverteringsloggen, ved at de ELEV_ID i SIS, som der er skiftet væk fra, logges til at pege på det studieforløb, der svarer til det nyeste ELEV_ID fra SIS. Dette gør, at GUEr samles på ét studieforløb, når der har været foretaget teknisk studieskift i SIS Datamapping En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af studieforløb Enkeltfag Enkeltfag i minder meget om enkeltfag i SIS og knytter sig direkte til et studieforløb og gemmer, hvilke enkeltfag den studerende har indsendt i forbindelse med en ansøgning. Information til enkeltfag tages hovedsageligt fra tabellerne ENKELTFAG og BESTAAEDE_ENKELTFAG Hovedbehandling En simplificeret udgave af hovedbehandlings vises i figuren herunder. Enkeltfag konverteres kun for aktive studerende optaget på ordinære uddannelser og hvis studieforløbet ikke er oprettet, vil enkeltfaget heller ikke blive oprettet. Da ansøgninger ikke konverteres til, vil enkeltfag blive oprettet uden henvisning til en ansøgning. Hvis karakter og/eller karakterskalaen benyttet i SIS ikke kan findes i, vil enkeltfaget blive oprettet, men med karakter og karakterskalaen, som det er registret i SIS. Hvis gymnasium institutionen ikke kan findes i, vil det oprettes med institutionsnavn fra SIS Netcompany Side 36 af 69

37 Datamapping En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af Enkeltfag. Gennemførelsesuddannelseselement (GUE) Et Gennemførselsuddannelseselement (fremover GUE) er den studerendes individuelle tilmelding til et konkret Planlægningsuddannelseselement (PUE). En GUE er ikke direkte oversættelig til en funktion i SIS. Eftersom GUE er er personspecifikke, fungerer de som dokumentation for en studerendes tilmelding og gennemførelse af et Strukturelt uddannelseselement (SUE). Funktionen som dokumentation betyder også, at bedømmelser og meritregisteringer er tilknyttet GUE er, hvorpå den studerendes opnåede resultat er angivet. Information om merit i forbindelse med praktik- og udlandsophold er også tilknyttet GUE en. GUEr dannes med afsæt i SIS tabellerne KARAKTERER, SKOLEFAG, FRITAGELSER, PRAKTIKFORLOB, LONNET_PRAKTIKOPHOLD, HOLDPLACERINGER og EVALUERINGSFORM Hovedbehandling En simplificeret udgave af hovedbehandlings flowet for GUEr er vist på Figur 13 nedenfor. Figur 13 - GUE hovedbehandlings flow GUE oprettelsen er i midten af konverteringen og en succesfuld konvertering af GUEr er afhængig af, at der på forhånd er konverteret personer, studieforløb, uddannelsesaktiviteter, uddannelsesstrukturer og SUEr. Data til konverteringen af GUEr kommer overordnet fra fem forskellige kilder i SIS: FRITAGELSER, KARAKTERER, PRAKTIKFORLOEB, LONNET_PRAKTIKOPHOLD og HOLDPLACERINGER. Data fra disse kilder indlæses i nævnte rækkefølge inden selve oprettelsen af GUEn finder sted. Hvis der skulle opstå dubletter i grundlaget for GUEn (f.eks. at GUE-grundlaget findes både i FRITAGELSER og i KARAKTERER), sikres de unikke nøgler fra SIS til via logning af disse (2.8.2), inden der oprettes én enkelt GUE i alt. Før en GUE kan oprettes sikres det desuden, at et studieforløb og tilsvarende SUE er oprettet. For ordinær uddannelse gælder det, at SUEn skal være oprettet på samme uddannelsesaktivitet som eleven er registreret på for at GUEn kan oprettes. Kan SUE ikke findes undersøges om den findes inden for samme aktivitetsgruppekode. Skulle dette ikke være opfyldt ignoreres denne (se afsnit 3 Dataafgrænsning) Netcompany Side 37 af 69

38 Efterbehandling Der sker to efterbehandlinger for en GUE. Marker GUE som bestået Når GUEr, bedømmelser samt meritregistreringer er oprettet i hovedbehandlingen efterbehandles GUEr ved at markere dem som bestået/ikke bestået. En GUE markeres som bestået, hvis den enten har en bedømmelse tilknyttet som er bestået, eller den har en meritregistrering som meriterer GUEn. Bedømmelsesresultatet på GUEn sættes på baggrund af hvad der står på meritten/bedømmelsen. Slutdatoen på en GUE sættes til enten slutdatoen for den relateret PUE eller til bedømmelsesdatoen. I tilfælde af flere bestået bedømmelser sættes datoen til den tidligst bestået. Ligeledes sættes startdatoen for en GUE til slutdatoen (bedømmelsesdatoen), hvis denne ikke er koblet til en PUE, hvor startdatoen kan arves fra, eller hvis bedømmelsesdatoen ligger tidligere end startdatoen for PUEn. Sidstnævnte kan ske i tilfælde af faget har en bedømmelse fra tidligere, som ikke er bestået. Datoer på GUEn bruges til studieforløbslinjen. Tilknyt PUE og Hold til GUE Når GUEr, PUEr og Hold er oprettet i hovedbehandlings flowet kan vi nu sammenkoble disse tre entiteter. Dette sker ved hjælp af logs for unikke nøgler af PUEr og Hold. Dette i kombination med HOLDPLACERING fra sis gør det muligt at sætte lookup felter på en GUE til dens tilsvarende PUE og Hold. På grund af forskelle i datamodellen fra SIS til, bliver der kun sat PUE og Hold på en GUE, hvis GUEn ikke har nogle tilhørende bedømmelser, meritter eller praktikophold. Denne afgrænsning er sat, fordi der ellers er risiko for at koble GUEr på den forkerte PUE. Status på GUE I efterbehandlingen opdateres status på GUErne. GUEr som har en bestået karakter tildeles status Gennemført. Hvis et studieforløb er afsluttet sættes status på til enten Slettet eller Ikke gennemført. Ikke gennemført sættes, hvis der er tilknyttet en ikke bestået bedømmelse. Status sættes til Slettet, i tilfælde af studieforløbet er afsluttet, og der ikke er tilknyttes nogle bedømmelser. I tilfælde med overlap mellem datoer på studieinaktive perioder og GUEr beholdes GUEn status som Aktiv. Dette gøres for at sikre at GUE med eventuelle bedømmelse(r) tilknyttet bevares og tælles med som forsøg IDV IDV GUEr oprettes kun på baggrund af holdplaceringer, kun hvis aktivitetens startdato er efter den og kun, hvis der er oprettet en tilknyttet PUE ligesom for ordinær uddannelse. Tilsvarende ordinær uddannelse gælder det ligeledes, at SUEn skal være oprettet på den uddannelsesstruktur som den studerende er indmeldt på, dvs., at skolefaget skal være opsat i S412 på elevens uddannelse. Alternativt kiggers der efter om SUEn findes inden for samme aktivitetsgruppekode. På andre parametre foregår oprettelsen af IDV GUEr ligesom for ordinær og Åben uddannelse Åben uddannelser En GUE på åben uddannelse bliver genereret baseret på samme kilder som en ordinær uddannelse. Studerende på en åben uddannelse har ret til at tage eksamen i op til seks år efter påbegyndelse af faget, derfor bliver åben uddannelses GUEr konverteret så længe startdatoen ligger maksimalt seks år tilbage i tiden, baseret på følgende datoer for hvert GUE-område: Kilde Dato baseret på Fritagelser/Merit Praktikophold FRITAGELSER.BEDOMMELSESDATO PRAKTIKFORLOB.STARTDATO hvis data er der, ellers 2020 Netcompany Side 38 af 69

39 PRAKTIKPLADSER.STARTDATO Bedømmelser Holdplaceringer KARAKTERER.BEDOMMELSESDATO HOLDPLACERINGER.STARTDATO Derudover frasorteres ÅU GUEr ikke, hvis de ikke har en PUE tilknyttet, som de ordinære, der oprettes via holdplaceringen, gør. For ÅU GUEr gælder det, modsat OU GUEr, at de kan oprettes på trods af, at eleven og aktiviteten i SIS er registreret på to forskellige uddannelser. Hvis dette er tilfældet vil GUEn blive knyttet til et UVM-fag på en uddannelsesstruktur ejet af SIU, der er oprettet i konverteringshenseende Datamapping En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af gennemførrelsesuddannelseselement. Studieinaktive periode Studieinaktive perioder er et koncept i som minder meget om orlovsperioder i SIS. Dog er fraværdsårsagerne, som registreres, gået fra at være lokalt til centralt styret. En studieinaktive periode bruges til at registrere en studerendes SUog ikke SU-berettiget fravær fra studiet. Studieinaktive perioder svarer til vinduet S001 Orlovsperioder for studerende i SIS Hovedbehandling En simplificeret udgave af hovedbehandlings flowet for Bedømmelser er vist på Figur 14. Pakke startet Map orlovsårsager i SIS til fraværsårsager i Findes studieforløb? Nej, ignorer Ja Opret studieinaktiv periode Pakke sluttet Figur 14 - Studieinaktiv periode hovedbehandlings flow Inden oprettelsen af studieinaktiv perioder sker, sikres det, at orlovsårsager (institutions specifikke) fra SIS er mappet korrekt mod de præoprettede og centralt styrede fraværsårsager som findes i. Forud for hver konvertering, vil der være oprettet en liste af fraværsårsags poster i, som en studieinaktiv periode post har et opslag til Netcompany Side 39 af 69

40 Data til studieinaktive perioder kommer primært fra orlovsperioder-tabellen i SIS. Hvis der er oprettet et studieforløb tidligere i flowet oprettes der en studieinaktiv periode, hvis ikke, ignoreres rækken Datamapning En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af Studieinaktive perioder. Internationalisering Internationalisering i er en entitet hvor en studerendes udlandsophold registreres. Dette gælder både for indgående og udgående studerende. Ved konverteringen af internationaliseringer bliver der ikke påsat institution. Dette skyldes at virksomheder ikke konverteres fra SIS til og det er derfor ikke muligt at sætte denne værdi. Det har den konsekvens, at hvis internationaliseringen skal indberettes, eller hvis der skulle være behov for senere at ændre i en eksisterende, konverteret internationalisering, vil der skulle påføres en institution. For at beholde opholdets land bliver dette sat som en del af navnet Hovedbehandlingen Internationaliseringer tages fra SIS-tabellen med samme navn og flyttes over til. Ja Nej Findes studieforløb for studerende? Ja Opret Internationalisering Pakke sluttet Pakke startet Findes internationaliseringen i forvejen? Nej Figur 15 Internationalisering hovedbehandlings flow Datamapping En komplet liste over, hvordan tabeller og felter i SIS mappes over i, kan findes i Toolkit på følgende link: Mapping af Internationalisering. Rekvirent Rekvirent i er en entitet, der for et studieforløb registrerer en periode og en debitor, der betaler for studieforløbet i den angivne periode. Debitor kan være en offentlig myndighed, fx et jobcenter eller en kommune, en privat virksomhed, der agerer på vegne af en offentlig myndighed, eller en privatperson (for udenlandske selvbetalingsstuderende) Ved konvertering af rekvirenter, vil det i mange tilfælde ikke være muligt at tilknytte den korrekte debitor til rekvirentposten. Dette skyldes, at der kun er oprettet institutioner i fra Institutionsregistret, og mange af debitorerne, der er anvendt i SIS, er ikke fra institutionsregistret. Derfor skal hver uddannelsesinstitution selv sørge for at tilkoble debitorer til relevante rekvirenter efter konverteringen Hovedbehandlingen Rekvirenter tages fra SIS-tabellen REKVIRENTER_FOR_STUDERENDE og konverteres til 2020 Netcompany Side 40 af 69

41 Ja Pakke startet Nej Findes studieforløb for studerende? Ja Findes rekvirenttype i? Ja Opret Rekvirent Pakke sluttet Findes rekvirent i forvejen? Nej Nej Figur 16 Rekvirenter hovedbehandlings flow Datamapping En komplet liste over, hvordan tabeller og felter i SIS mappes over til Rekvirent i, kan findes i Toolkit på følgende link: Mapping af Rekvirent Bevisgrundlag Bevisgrundlag i er en entitet, som bliver dannet for at persistere data ved gennemførelse af et element og til senere brug ved dannelsen af beviser. Der skal dannes bevisgrundlag for alle GUEr der er bestået og som har en relateret SUE, der er angivet som et fag der skal på beviset. Derudover dannes der bevisgrundlag for alle studieforløb, der har en eller flere beståede GUEr. Dette gør at antallet af bevisgrundlag kommer op på flere hundred tusinde. På grund af mængden af bevisgrundlag, behandles oprettelsen af disse som et batchjob, der kører i dagene efter institutionerne er blevet konverteret ind i. For at sikre at bevisgrundlagene er ens, sammenlignet med bevisgrundlag dannet af, vil batchjobbet gøre brug af samme kode som anvender til dannelsen af disse. Da batchjobbet skal køre over flere dage, bliver oprettelsen af bevisgrundlaget udført efter følgende prioritering: 1. Studieforløb med ældste studiestartsdato 2. Gennemførelseselement med nyeste bedømmelse Dette sikrer, at de studieforløb som enten lige er afsluttet eller er ved at blive afsluttet, får dannet deres bevisgrundlag først Uddannelser I nærværende afsnit vil konverteringsstrategien for funktionelle områder relateret til Uddannelse blive beskrevet. Først og fremmest sættes de centralt administreret dele af uddannelserne op i af SIU som uddannelsesaktiviteter, hvorpå den enkelte institutions uddannelsesstrukturer tilknyttes. Efterfølgende konverteres strukturelle uddannelseselement og planlægningsuddannelseselement Uddannelsesaktivitet Uddannelsesaktivitet er en entitet i, som svare til uddannelser i SIS. Uddannelsesaktiviteten er centralt administreret og opsættes manuelt af SIU, inden den resterende data konverteres. Der er til alle uddannelsesaktiviteter tilknyttet en bekendtgørelse, som danner baggrund for en uddannelsesaktivitet. Kun aktive og for konverteringen historiskrelevante uddannelsesaktiviteter bliver oprettet i. Uddannelsesstruktur Uddannelsesstrukturer er et nyt koncept i. Disse er en kombination af forskellige koncepter i SIS som uddannelser, cøsa formål, og centrale koder. I er bekendtgørelser og studieordninger afspejlet i uddannelsesaktiviteter og uddannelsesstrukturer. En uddannelsesstruktur er den systemmæssige opbygning af en studieordning samt relevante betingelser fra uddannelsesbekendtgørelsen og øvrige bekendtgørelser Netcompany Side 41 af 69

42 Regler for uddannelsesstrukturer, jf. bekendtgørelser, er håndholdt på uddannelsesaktiviteter og uddannelsesstrukturer udvider denne ved at tilkoble strukturelle uddannelseselementer (SUEr). Der oprettes en SUE for hvert semester der eksisterer på uddannelsesstrukturen, hvorpå uddannelsens kurser (fag SUEr) bliver koblet på. Figur 17 viser et eksempel på dette Forbehandling Figur 17 - Eksempel for uddannelsesstrukturer Før konverteringen af Uddannelsesstrukturer kan gennemføres, præopretter SIU førnævnte uddannelsesaktiviteter forud for konverteringen. Dette indebærer at angive korrekte indberetningskoder, uddannelsestype, bekendtgørelser mv. Dette skal gøres, da det netop er disse data som konverteringen benytter til at koble uddannelsesstrukturerne på uddannelsesaktiviteten Hovedbehandling En simplificeret udgave af hovedbehandlings flowet for Uddannelsesstrukturer er vist på Figur 18. Data til Uddannelsesstrukturer kommer primært fra tabellen UDDANNELSER i SIS. Der benyttes dog også referencer til cøsa formål-tabellen samt tabellen for centrale koder. Hvis uddannelsesaktiviteten er oprettet i på forhånd, oprettes der en lokal uddannelsesstruktur, hvis ikke ignoreres rækken. Efterfølgende oprettes der SUEr svarende til det antal semestre, der er på uddannelsen. Disse navngives med semesternummer + semester og kobles på uddannelsesstrukturen som vist i ovenstående model Efterbehandling Efter fuldendt konvertering foretages der, som det sidste job, en oprydning af konverteret uddannelsesstrukturer, som har en slutdato. Disse strukturer vil blive slettet fra systemet, hvis følgende er opfyldt: En uddannelsesstruktur har angivet en slutdatoen, der er overskredet på konverteringsdagen, og Der ikke eksisterer nogle tilknytning til hverken studieforløb, gennemførselselementer eller planlægningselementer. I forbindelse med sletningen af uddannelsesstrukturen bliver relaterede strukturelle uddannelseselementer og aktivitetsudbud ligeledes slettet Netcompany Side 42 af 69

43 Figur 18 - Uddannelsesstruktur hovedbehandlings flow Teknisk Studieskift for de maritime uddannelser Uddannelsesstruktur-flowet indeholder en speciel håndtering af teknisk studieskift for de maritime værksstedskoler. Alle andre tekniske studieskift involverer ikke nogle ændringer til uddannelsesstrukturer, men for udvalgte strukturer på de maritime uddannelser, laves der en sammenlægning af flere uddannelser fra SIS, som samles på uddannelsesstrukturer i. Uddannelsesstrukturerne der skal laves teknisk studieskift til oprettes via det normale flow, mens de strukturer der flyttes (Værkstedsskolerne) i forbindelse med teknisk studieskift, logges via et separat flow. Logningen af det tekniske studieskift sikrer, at andre processer i konverteringen kan finde uddannelsesstrukturen i logningen, uden at Uddannelsesstrukturen er oprettet i. Den logges derfor med det UDDA_ID uddannelsesstrukturen originalt har haft i SIS, men med den GUID der hører til den uddannelsesstruktur, som den skal flyttes over på. På den måde peger flere uddannelsesstrukturer i logningen mod den samme uddannelsesstruktur i. Mapningen mellem de nye og de gamle uddannelsesstrukturer på de maritime uddannelser kan ses i tabellen herunder. I tilfælde af at andre mapninger er nødvendige, ønskes det afleveres via denne type simple opsætning. Gammel aktivitetsgruppekode (flyttes fra) Ny aktivitetsgruppekode (flyttes til) Netcompany Side 43 af 69

44 Datamapning En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af uddannelsesstruktur. Aktivitetsudbud Aktivitetsudbud i er bindeleddet imellem uddannelsesstruktur, institutionsafdeling og studieforløb. Det skal derfor i konverteringen sikres, at der oprettes alle de aktivitetsudbud, der er behov for i forhold til konverteringen af studieforløb. Dette gøres ved at bruge ELEVER tabellen i SIS, til at oprette aktivitetsudbud for alle de kombinationer af uddannelser og institutionsafdelinger, som studerende er indskrevet på. Hertil oprettes der aktivitetsudbud baseret på AKTIVITETERtabellen, som har en holdplacering tilknyttet Hovedbehandling Fra ELEVER tabellen i SIS indlæses alle unikke kombinationer af uddannelser og institutionsafdelinger. Resultaterne valideres mod data i, for at sikre, at der ikke oprettes duplikerede data og, at de påkrævede felter er udfyldt. Felter til perioder på aktivitetsudbuddet nedarves fra de standardværdierne, der kan være udfyldt på den juridiske afdeling. I det tilfælde den relateret institutionsafdeling er markeret som inaktiv (svarende til ophørt) tilføjes aktivitetsudbudet en ophørsdato. Datoen sættes til dagen før konverteringsdagen. En forsimplet udgave af flowet er illustreret i Figur Efterbehandling Figur 19 - Aktivitetsudbud hovedbehandlings flow Efter endt konvertering foretages der en oprydning af konverteret aktivitetsudbud. Disse poster slettes hvis den tilhørende uddannelsesstruktur har en overskredet slutdato og derfor ikke benyttes. Dette er nærmere beskrevet i afsnit Datamapning En komplet liste over hvordan tabeller og felter mappes over i kan findes i Toolkit på følgende link: Mapping af aktivitetsudbud 2020 Netcompany Side 44 af 69

45 Profiler Profiler i vil fungerer som en specialisering af studieforløb, som går ud over angivelsen af AUDD koder. I konverteringssammenhæng konverteres data fra RETNINGER tabellen i SIS over til Profiler i Hovedbehandling I hovedbehandlingen af profiler læses data fra RETNINGER tabellen i SIS. Det kontrolleres for hver række, om denne allerede er oprettet i forbindelse med konvertering. Inden data oprettes i, laves der datavask på BETEGNELSEN fra SIS. Hvis betegnelsen starter med Retning:, fjernes denne del af teksten, og den resterende tekst anvendes som navnet på Profilen i. En forsimplet udgave af flowet er illustreret herunder, i Figur 20: Pakke startet Er Profil allerede oprettet? Pakke sluttet Nej Opret Profil Ja, ignorer Figur 20 - Profil hovedbehandlings flow Datamapping En komplet liste over hvordan tabeller og felter mappes over i kan findes i Toolkit på følgende link: Mapping af profil UVM-Fag UVM-fag minder om UVM-fag i SIS, der ligger i SIS-F. I oprettes de baseret på et ark med data fra takstkataloget Arket indeholder både aktive og nedlagte UVM-fag, og er udarbejdet af SIU, for at sikre at relevante UVM-fag opsættes i. UVM-fagene bruges ifm med konverteringen af SUEr udbudt på åben uddannelse, da disse knyttes til et UVM-fag Forbehandling Før konverteringen af UVM-fag, udfylder SIU et ark med UVM-fag, der fortsat er relevante at få konverteret over i, så SUEr på ÅU kan relatere til dem, hvis nødvendigt. Dette ark skal indeholde både aktive og nedlagte UVM-fag Hovedbehandling I hovedbehandlingen af UVM-fag indlæses det udarbejet ark med alle UVM-fag. Disse indlæses og kobles til en specifik uddannelsesstruktur, som ejes af SIU. De indlæste UVM-fag får sat status efter om de er aktive eller nedlagte. En simplificeret udgave af hovedbehandlings flowet kan ses i figuren nedenfor Netcompany Side 45 af 69

46 Pakke starter Load takstkatloget inkl. nedlagte UVM-fag Nej, ignorer Findes uddannelsesaktiviteten i? Ja Nej, ignorer Er SIU uddannelsesstruktur sat op? Ja Opret UVM-fag Pakke sluttet Figur 21 UVM-fag hovedbehandlings flow Strukturelt uddannelseselement (SUE) SUE kan oversættes til fagindhold i SIS. De strukturerer uddannelsen og sikrer, at den efterlever formelle krav fra bekendtgørelsen. SUEr er altså byggesten som skaber struktur i uddannelsen. Disse byggesten fås i forskellige typer, hvoraf det i konverteringen anvendes tre typer: Fag SUEr, Semester SUEr samt Grupperings SUEr. Et eksempel på dette kan ses på Figur 22. Først gennemgår vi konverteringen af SUEr for ordinære uddannelser og nedenfor vil strategien for åbne uddannelser blive beskrevet. Fag SUE (markeret med blå) Beskriver et fag og det er disse SUEr som planlægges (PUE) og derigennem tilmeldes studerende til (GUE). Et fag i denne sammenhæng kan både være obligatoriske fag og valgfag. Disse vil findes i A890 i SIS. Semester SUE (markeret med orange) SUEr som inddeler Fag SUEr og dannes i forbindelse med oprettelse uddannelsesstrukturer. Antallet af semester SUEr er oprettes er angives fra centralt hold på uddannelsesaktiviteten. Grupperings SUE (markeret med grøn) SUE som grupperer de valgfag (Fag SUEr), som den studerende har mulighed for at vælge. En gruppering er altså obligatorisk, men der kan vælges mellem de underliggende SUEr. Denne data hentes fra S412 i SIS Netcompany Side 46 af 69

47 Semester 1 Pædagogik Didaktik Kreative kurser Musik Billedkunst Figur 22 - SUE typer eksempel Hovedbehandling En simplificeret udgave af hovedbehandlings flowet for SUEr er vist på Figur 23 Figur 23 - SUE hovedbehandlings flow Data til SUEr kommer primært fra Fagindhold på uddannelsesordning-tabellen i SIS (S412), og det vil være denne tabel som Fag-SUEr oprettes på baggrund af. I løbet af dette flow kan der, som en side effekt, oprettes andre typer SUEr Netcompany Side 47 af 69

48 Inden oprettelsen af SUEr sker, sikres det, at Resultatformer (institutionsspecifikke) fra SIS er mappet korrekt mod de valgmuligheder, som er sat op på en SUE i. Et skolefag i SIS har relation til en eller flere resultatformer, og derigennem evalueringsformer. Mapningen fra disse bruges til at sætte de(n) korrekte bedømmelsesform når SUEn oprettes. Hvis der er flere resultatformer tilknyttet et skolefag, vælges én karakterskala i følgende prioriterede rækkefølge: 7-trin, Bestået/Ikke Bestået, Godkendt/Ikke Godkendt eller 13-skalaen. Bedømmelsestype prioriteres i følgende rækkefølge: ekstern, intern. Efterfølgende sikres det, at den tilhørende uddannelsesstrukturer er oprettet. Hvis ikke dette er tilfældet ignoreres rækken. Endvidere sikres det, at der er oprettet en Semester SUE på uddannelsesstrukturen, hvis ikke dette er tilfældet, oprettes der en ny semester SUE kaldet Ukendt semester. Formålet med Ukendt semester er, at FagSUEr altid har en tilknytning i strukturen. Dette gøres, da det ikke ønskes, at elementer, der repræsenterer fag, ligger som det øverste lag i uddannelsesstrukturen. For linjefag oprettes en grupperings SUE for alle linjefag på samme semester, grupperings SUEn vil have den tilsvarende semester SUE som overordnet SUE. Hvis et linjefag ikke har et semester i SIS, oprettes der en grupperings SUE med navnet Linjefag ukendt semester, der vil have en overordnet semester SUE med navnet Ukendt semester, ligesom for almindelige fagsuer. Hvis et linjefag har påsat en retning i S412, vil denne blive påsat som profil på SUEN, såfremt profilen er oprettet i. Se Profiler. Herefter undersøges det om givne fagindhold er et valgfag eller et linjefag, hvis dette er tilfældet, sikres det, at der eksisterer en grupperings SUE, som valgfaget/linjefaget placeres under. Når de fornødne andre SUEr er oprettet bliver Fag SUEn oprettet. Valgfag og linjefag Nogle uddannelser indeholder flere valgfag eller linjefag. For at holde dem samlet vil SUEr der oprettes som en af disse altid blive grupperet sammen under enten en valgfaggruppering eller linjefagsgruppering. Når en uddannelsesordning i SIS har fagindhold angivet som linje- eller valgfag oprettes der i, foruden en fag- SUEn, en SUE med typen Gruppering. For linjefagsgruppering oprettes der en gruppering for hvert semester, hvorpå der i S412 er placeret et fagindhold med fagkategorien LINJE. Valgfag får oprettet én gruppering indeholdende alle fagindhold med fagkategorien VALG. Herudover oprettes der en SUE til udbud af valgfag, som knyttes til hvert semester, hvorpå der i SIS er angivet et valgfag Efterbehandling Efter konverteringen af SUEr tilføjes de et unikt nummer til identifikation. SUEr, som er dannet på baggrund af samme fagindhold i SIS, får sat samme nummer, og en relation mellem SUErne tilføjes. SUErne fra samme fagindhold vil alle pege på den samme relateret SUE, som sættes til den første SUE der fik tilføjet SUE-nummeret. Nummerserien der dannes er unik serie inden for samme aktivitetsgruppekode, hvorfor det kræver, at alle SUEr er indlæst inden der kan sættes et nummer IDV IDV SUEr oprettes for alle IDV fag, der er opsat i S412 på en uddannelse med centraluddannelseskode Disse SUEr vil blive oprettet på det SIU ejede aktivitetsudbud med navnet Indtægtsdækket virksomhed og aktivitetsgruppekode Åben uddannelse En fag SUE på åbne uddannelser er det samme som en fag SUE på ordinære uddannelser. For fag på åbne uddannelser med en af aktivitetsgruppekoderne i listen i afsnit 8.1, så håndteres konverteringen til SUE på samme måde 2020 Netcompany Side 48 af 69

49 som for ordinær uddannelse, se afsnit For de resterende åbne uddannelser håndteres konvertering af SUEr som beskrevet nedenfor i dette afsnit. Forskellen i konverteringen er, at en SUE for Åben Uddannelse ikke kobles på en semester SUE, men på et af de UVMfag der er oprettet på en SIU-ejede struktur. SUEr for åben uddannelse konverteres udelukkende, hvis det kan kobles på et UVM-fag, derfor oprettes der ikke Ukendt semester SUE, som der gøres på ordinær uddannelse. Da der i SIS kan være oprettet flere fag for samme UVM-fagkode, vil hver af disse fag blive oprettet som fag SUE. Da et UVM-fag kan være tilkoblet flere åbne uddannelser, vil fag SUErne blive oprettet på alle lokale strukturer på disse uddannelser. Inden oprettelsen af ÅU SUEr sker, sikres det desuden, at Resultatformer (institutionsspecifikke) fra SIS er mappet korrekt mod de valgmuligheder, som er sat op på en ÅU SUE i. Et skolefag i SIS har en relation til resultatformer, og derigennem evalueringsformer. Mapningen fra disse bruges til at sætte den korrekte bedømmelsesfrom når ÅU SUEn oprettes. Hvis der er flere resultatformer tilknyttet et skolefag, vælges én karakterskala i følgende prioriterede rækkefølge: 7-trin, Bestået/Ikke Bestået, Godkendt/Ikke Godkendt eller 13-skalaen. Bedømmelsestype prioriteres i følgende rækkefølge: ekstern, intern Hovedbehandling En simplificeret udgave af hovedbehandlings flowet for SUEr på ÅU er vist på Figur 24. Pakke starter Map resultatformer fra SIS til bedømmelsesformer i Nej, ignorer Findes UVM-faget i? Ja Nej, ignorer Er uddannelsesstrukturen for SUEn oprettet i? Ja Sæt fagtype på SUEn Opret Fag SUE Pakke sluttet Figur 24 - ÅU SUE flow Efterbehandling Efter fuldendt konvertering foretages der en oprydning af konverteret strukturelle uddannelseselementer. Disse poster slettes, hvis den tilhørende uddannelsesstruktur har en overskredet slutdato og ikke benyttes og derfor. Dette er nærmere beskrevet i afsnit Netcompany Side 49 af 69 Figur 25 - ÅU SUE

50 Teknisk Studieskift for de maritime værkstedsskoler SUE-flowet indeholder teknisk studieskift for de maritime værksstedskoler. Alle andre tekniske studieskift foretages der ikke nogen ændring til, i forhold til SIS. Det tekniske studieskift af SUEr kræver, at de maritime institutioner har sat deres fag, der i SIS alene ligger på en værkstedsskole-uddannelsesstruktur, op i S412, på den uddannelsesstruktur, som de skal flyttes til. Alle SUEr oprettes derved via det normale flow, da de er sat på i S412. De SUEr som før lå på et værkstedsskoleuddannelsesstruktur logges der desuden detaljer omkring, via et separat flow. Logningen af det tekniske studieskift sikrer, at andre processer i konverteringen kan finde SUEn i logningen, uden at SUEn er oprettet i på den gamle uddannelsesstruktur. Den logges derfor med det FAGUDD_ID fagindholdet originalt har i SIS, men med den GUID, der hører til den SUE, som det flyttes over på (som er oprettet i S412). På den måde peger flere SUEr i logningen mod den samme SUE i. Aktivitetstypen på SUEn i sættes efter hvad der står i SIS. Aktivitetstypen Værkstedsskole sættes når der i området for fagindholdet er angivet værkstedsskole. Mapningen mellem de nye og de gamle uddannelsesstrukturer, og derved SUEr, ser hos maritime ud som i tabellen herunder. I tilfælde af at andre mapninger er nødvendige, på andre maritime institutioner, ønskes det afleveres via denne type simple opsætning. Gammel aktivitetsgruppekode (flyttes fra) Ny aktivitetsgruppekode (flyttes til) Datamapning En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af uddannelseselement. Planlægningsuddannelseselement (PUE) PUEr i er konverteret baseret på Hold i SIS, hovedsageligt med data fra tabellen AKTIVITETER - Skærmbillede A326 i SIS, men er ikke direkte oversættelig til en funktion i SIS. PUE en er et specifikt udbud og kan anvendes til at skabe overblik over tilmeldte studerende til en SUE (fag). Aktiviteter i SIS konverteres til både PUE og Hold i. For hver PUE, der bliver oprettet, oprettes der ligeledes ét Hold i. En aktivitet i SIS kan blive til flere PUEr i. Hvis der på en aktivitet i SIS er lavet holdplaceringer med flere fag, vil der blive oprettet en PUE for hvert af disse fag. Det vil sige, at hvis en aktivitet i SIS har holdplaceringer fordelt over fire forskellige fag, vil der blive oprettet fire PUEr i, ud fra dette ene Hold i SIS. Ud over fagene på aktiviteten i SIS, så har de tilmeldte studerendes uddannelser også indflydelse på, hvor mange PUEr der bliver oprettet for en aktivitet ved konverteringen. Hvis der på en aktivitet er tilmeldte studerende fra to forskellige uddannelse, på 3 forskellige fag, vil der således blive oprettet 6 PUEr for denne ene aktivitet Netcompany Side 50 af 69

51 Der er kun konverteret PUEr baseret på Hold fra SIS, hvis holdet i SIS er aktivt eller planlagt, og har mindst én aktiv eller fremtidig holdplacering. Der oprettes publiceringer samtidig med at der oprettes PUEr Hovedbehandling En simplificeret udgave af hovedbehandlings flowet for PUEr er vist på Figur 16. Figur 26 - PUE hovedbehandlings flow Når en PUE for en ordinær uddannelser eller IDV skal tilknyttes en SUE bliver der først lavet et tjek om faget er opsat på aktivitetens uddannelsesordning. Er dette ikke tilfældet undersøges, om faget er opsat på en anden uddannelsesordning under samme aktivitetsgruppekode. Eksisterer samme fag på flere uddannelsesordninger under samme aktivitetsgruppekode vælges den som senest er blevet tilføjet. Kan faget ikke findes under samme aktivitetsgruppekode bliver PUE ikke oprettet. For aktiviteter på Åben uddannelser tjekkes først om UVM-faget eksisterer på aktivitetsgruppekode. Hvis dette ikke er tilfældet prøves det er finde UVM-fag i hele og tilknyttet til dette. Er det ikke muligt bliver PUEn ikke oprettet. Der tilknyttes en aktivitetsafdelingen ud af aktivitetsgruppen i SIS. Afdelingen findes ud fra et mappingark institutionerne på forhånd har udfyldt, med relationen mellem aktivitetsgruppen og underafdelingen i Efterbehandling Når konverteringen af data i er afsluttet, eksekveres der tre efterbehandlingsjob der har indvirkning på PUEr: Tilknyt SUE Til PUE Denne efterbehandling relaterer PUEn til en SUE og sætter bedømmelsesform, bedømmelsestype, ects, karakterskala, status, uddannelsestype samt indskrivningsform på PUEn. Tilknyt PUE til GUE Denne efterbehandling sætter PUE på GUE og derved gør de tilknyttede GUEr synlige på PUEn. Opret PUE holdere til historiske GUEr Til de GUEr, der ikke har fået tilknyttet en konverteret PUE, oprettes der nogle overordnede PUE holdere, som disse GUEr tilknyttes. Der oprettes én PUE holder per SUE, hvis der findes mindst én GUE tilknyttet denne SUE, hvor GUEn ikke har tilknyttet en konverteret PUE. Sæt PUEnummer I denne efterbehandling oprettes PUEnummer og løbenummer og sættes på PUEn IDV PUEr for IDV oprettes på samme måde og med samme vilkår som for ordinær og åben uddannelse. For IDV gælder det dog, at aktivitetens startdato skal være efter den 1. januar Netcompany Side 51 af 69

52 Datamapping En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af planlægningsuddannelseselement Karaktergivende elementer I har vi tre typer karaktergivende elementer, som alle relaterer sig til gennemførslen af et fag. Bedømmelser som er registrering af et eksamensforsøg samt karakteren givet, merit og praktikophold. I de følgende afsnit vil den konkrete konverteringsstrategi for dette område blive gennemgået. Bedømmelse Bedømmelser er et koncept i som ikke direkte findes i SIS, men minder meget om Karakterer. Bedømmelser er et eksamensforsøg eller prøveforsøg hvor den studerende er blevet bedømt, ikke nødvendigvis den afgørende bedømmelse. Bedømmelses entitet bruges både til at registrere fejlede bedømmelsesforsøg samt den gældende bedømmelse for en given gennemførsels uddannelseselement. Bedømmelser i kan blive oprettet på baggrund af to forskellige elementer i SIS :karakterer registreret i A477 eller Endelig Indstilling på et praktikforøb Hovedbehandling Forud for hver konvertering, vil der være oprettet en liste af karakterposter i, som en bedømmelsespost har et opslag til. Hver institution har udfyldt et konverteringsark som mapper karakterværdier i SIS til et ensartet format. Tilsvarende mappes bedømmelsesformer fra et konverteringsark som hver institution har udfyldt. Igen går formatet fra at være institutions specifikt til at være centralt styret. En simplificeret udgave af hovedbehandlings flowet for Bedømmelser er vist på Figur 27. Figur 27 - Bedømmelse hovedbehandlings flow Data til bedømmelser kommer primært fra karakter-tabellen i SIS. Hvis der er oprettet en GUE tidligere i flowet oprettes der en bedømmelse, hvis ikke, ignoreres rækken Bedømmelser oprettet på Endelig Indstilling Bedømmelser oprettet baseret på en Endelig Indstilling afviger på enkelte områder på et praktikophold minder på de fleste punkter om oprettelsen af en bedømmelse baseret. SIU har lavet mapping af Endelig Indstilling i SIS til karakter og karakterskala i, som bedømmelserne vil blive oprettet ud fra. Denne mapping kan ses i Tabel Netcompany Side 52 af 69

53 Endelig_indstilling ESAS_KARAKTER KARAKTERSKALA NULL Oprettes ikke Ikke gennemført IG Ikke godkendt Godkendt/Ikke godkendt Ikke bestået IG Ikke godkendt Godkendt/Ikke godkendt Ikke godkendt IG Ikke godkendt Godkendt/Ikke godkendt Gennemført G Godkendt Godkendt/Ikke godkendt Godkendt G Godkendt Godkendt/Ikke godkendt Bestået G Godkendt Godkendt/Ikke godkendt Admin. Annulleret Konverteres ikke Ikke vurderet II Ikke Indstillet Godkendt/Ikke godkendt Tabel 13 - Mapping af endelig indstilling til karakterer i. Data til oprettelse af bedømmelse baseret på Endelig Indstilling kommer fra praktikforløbs tabellen og feltet Endelig Indstilling. I flowet tjekkes det om GUEn allerede har en bedømmelse, hvis den har oprettes der ikke en på baggrund af endelig indstilling, hvis den ikke har oprettes bedømmelsen. En simplificeret udgave af hovedbehandlings flowet for Bedømmelser oprettet baseret på Endelig indstilling er vist på Figur 28. Figur Håndtering af flere beståede bedømmelser på samme GUE I SIS kan der være registreret flere beståede bedømmelser på samme fag for den samme studerende. Da det ikke er understøttet at have flere aktive, beståede bedømmelser på den samme GUE i, håndteres dette ved at konvertere ekstra beståede bedømmelser til med status Annulleret. Hvis en GUE har flere beståede bedømmelser, vil alle beståede bedømmelser, bortset fra den nyeste, blive markeret som Annulleret 2020 Netcompany Side 53 af 69

54 Datamapning En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af Bedømmelser. Meritregistreringer Hvis en studerende før har gennemført uddannelseselementer (GUE), som svarer til dele af den uddannelse den studerende er i færd med at tage, kan den studerende få godkendt meritregistreringer. I SIS var meritregistrering delt op i Fagmerit, Semestermerit og Praktikmerit. I oprettes merit på en GUE, og svarer derfor til fagmeritter Hovedbehandling Inden oprettelsen af meritregistreringer, sikres det, at Karakterværdier (institutionsspecifikke) fra SIS er mappet korrekt mod de præoprettede og centralt styrede karakterer som findes i. Dette gøres også i forbindelse med Bedømmelser og det er den samme liste der bruges. Forud for konverteringen, vil der være oprettet en liste af karakterposter i, som en meritpost har et opslag til. Tilsvarende mappes bedømmelsesformer fra et andet konverteringsark, som hver institution har udfyldt på forhånd. Igen går formatet af dette data fra at være institutions specifikt til at være centralt styret. En simplificeret udgave af hovedbehandlings flowet for Meritregistreringer er vist på Figur 29. Pakke starter Findes meritregistreringen Er studieforløb og GUE allerede i? oprettet? Er meritregistreringen Findes den mappede Findes SUE i? bestået? karakterskala i? Ja Nej Ja Ja Ja Opret meritregistrering Pakke sluttet Nej, Ignorer Ja, ignorer Nej, ignorer Nej, ignorer Nej, ignorer Figur 29 - Hovedbehandlings flow for meritregistrering Meritregistreringer i bruger hovedsaligt data fra SIS tabellerne KARAKTERER og FRITAGELSER. Disse tabeller bruges til at udfylde meritregistreringer med informationer fra SIS, der kobles op på tidligere indlæste GUE. Inden en meritregistrering konverteres, sikres det, at studieforløb og GUE er blevet konverteret ind i. Hvis dette ikke er tilfældet bliver meritregistreringen ignoreret. Hvis en meritregistrering ikke har en bedømmelse i SIS, sættes karakterværdien i til G Godkendt på karakterskalaen Godkendt/Ikke Godkendt. Ligeledes, hvis en meritregistrering ikke har angivet en merittype i SIS, vil den blive konverteret ind i med merittypen Merit Startmerit. Årsagen til dette er, at begge felter er påkrævet i. I de tilfælde, hvor der er oprettet en meritregistrering i SIS, hvor bedømmelsen ikke svarer til bestået dette kan være både dumpe karakterer, ikke godkendt, ej mødt mv. bliver meritten ikke konverteret. Dette skyldes, at det ikke er muligt at meriterer fag, som ikke er bestået. Hvis et fag er tildelt flere bestået meritregistreringer i SIS, konverteres de alle til. Ofte vil meritregistreringerne have samme bedømmelsesdato, hvorfor det derfor ikke muligt at adskille registreringerne fra hinanden Netcompany Side 54 af 69

55 Datamapning En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af meritregistrering. Praktikophold Hvis en studerende, som en del af sin uddannelse, tager et praktikophold hos en virksomhed eller institution og modtager ECTS-point for det, registreres det som et praktikophold. I SIS var praktik registreret i tabellen PRAKTIKFORLOB og PRAKTIKPLADSER, i er det samlet under Praktikophold. Det er i også muligt at registrere, om praktikken er lønnet eller ej, så der kan tages forbehold i forbindelse med SU Hovedbehandling Inden oprettelsen af praktikophold, får institutionerne mulighed for at mappe mængden af specialiseringsområder i SIS til selvvalgte praktikområder i for at mindske mængden af praktikområder. Forud for konverteringen, vil der være oprettet en liste af specialiseringsområder i SIS, som er brugt på minimum ét praktikforløb. Disse mapningsark bruges til at oprette institutionsspecifikke praktikområder i og mappe dem med specialiseringsområderne i SIS. I forbindelse med fartstidspraktikophold for de maritime institutioner, er der udarbejdet et mapningsark af på hvilke skolefag og hvilken uddannelse 1. praktik og 2. praktik ligger. Dette ark bruges til at mappe hvilke fartidsnoter fra SIS, som skal ligge på hvilke GUEr i. En simplificeret udgave af hovedbehandlings flowet for Praktikophold er vist på Figur 30. Figur 30 - Praktikophold hovedbehandlings flow. Praktikophold i bruger hovedsaligt data fra SIS tabellerne PRAKTIKFORLOB, PRAKTIKPLADSER og PRAKTIKPERIODER. Disse tabeller bruges til at udfylde Praktikophold med informationer fra SIS, der kobles op på tidligere indlæste gennemførselsuddannelseselementer Lønnet praktik Lønnet praktik kommer fra SIS tabellen LONNET_PRAKTIKPERIODER og oprettes i som et praktikophold. For at undgå alt for mange dubletter, opretter der kun praktikophold baseret på lønnet praktik for de institutioner, der bruger lønnet praktik aktivt. Der er i nogle tilfælde blevet oprettet et praktikophold i både LONNET_PRAKTIKPERIODER og PRAKTIKFORLOB tabellerne, vil der stadig oprettes dubletter i de tilfælde hvor de institutioner der bruger lønnet praktik, har oprettet praktikopholdet begge steder. Dette er en kendt begrænsning og kommer ikke til at blive ændret. GUEn som et lønnet praktikophold skal lægges på har kilden LONNET_PRAKTIKPERIODER(ELEV_ID,SKFA_ID) Netcompany Side 55 af 69

56 Fartstid Fartstid ligger i på et praktikophold på en GUE. Men da de maritime uddannelser ikke bruger praktikophold på en måde der konverteres, opretter vi disse for dem, i selve konverteringen. Data på fartstid ligger i tabellerne NOTER og NOTETYPER i SIS. Disse tabeller lægges sammen med data fra bedømmelser på uddannelsesordninger og SKOLEFAG, hvor fartstid ligger på. Derved kan vi oprette et praktikophold og lægge det på den karakter-gue med kilden KARAKTERER(ELEV_ID,SKFA_ID). Denne opsætning er baseret på SIMAC, som den eneste maritime institution vi endnu har prøvekonverteret for. Der vil muligvis blive bruge for individuelle opsætninger, til de andre maritime institutioner Datamapping En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af praktikophold Indberetninger [KO-14] I dette afsnit bliver konverteringsstrategien fremlagt for forskellige administrative og økonomiske elementer, der konverteres. Det er data for indberetninger, som både gælder STÅ, Ungedatabasen, SU-hændelser og faktureringer. SU-Hændelser Ved konverteringer af SU-hændelser tages kun en reduceret mængde af data bestående af hændelser med typen Indskrivning, Orlov og Ophør. Herudover konverteres kun de hændelser som i SIS har status angivet som godkendt eller manuelt. Dette gøres, da de er nødvendige for, at funktionaliteten til fremtidige indberetninger til US2000 i kan eksekveres problemfrit. Dertil konverteres også oplysninger til felterne kontrolstatus, kontroldato og ændringsdato for studieforløb med SUhændelser for aktivitetskontrol gamle regler, men selve SU-hændelsen konverteres ikke. I oprettes der ikke et link mellem relaterede SU-hændelser med ny status, da alle den studerendes SU-hændelser er koblet sammen og relateret på CPR-nr Hovedbehandling Data til SU-hændelser kommer primært fra SU_HANDELSER tabellen i SIS og suppleres med data fra relateret tabeller for selve transaktionen: SU_TRANSAKTIONER og SU_INDSKRIVNINGER. I tilfælde en person har skiftet CPR-nummer vil der i SIS være oprettet 2 simultane hændelse med et ophør og indskrivning på det gamle hhv. nye CPR-nummer. For at adskille og sikre at hændelsen indskrivningen i tid ligger efter ophøret tillægges der 6 minutter til indskrivningens oprettelsestidspunkt. En simplificeret udgave af hovedbehandlings flowet for SU-Hændelser er vist på Figur 31: 2020 Netcompany Side 56 af 69

57 Figur Datamapning En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af SU-hændelser. Ungedatabase-Hændelser (UDB-hændelser) UDB-Hændelser i konverteres fra to forskellige tabeller i SIS: UDB_HANDELSER og UDB_TRANSAKTIONER. Kun allerede godkendte hændelser på aktive studieforløb konverteres til, for at sikre, at der ikke dobbeltrapporteres. Hvis en person har afbrudt uddannelsen og påbegyndt den præcis samme uddannelse igen, vil der også blive oprettet UDB-hændelser for første optag på studiet. I linkes der ikke til en tidligere hændelse, med en anden status, da UDB-hændelser er koblet sammen og relateret på CPR-nr Hovedbehandling En simplificeret udgave af hovedbehandlings flowet for UDB-Hændelser er vist her: 2020 Netcompany Side 57 af 69

58 Data til UDB-hændelser kommer fra de førnævnte tabeller i SIS. Denne information kobles på tidligere indlæste studieforløb, institutionsafdeling og uddannelsesstruktur. For konverteringen af UDB-hændelser gælder det, at UDB_STATUS skal være 1 svarende til Optaget og STATUS skal være OK eller OK SE MEDD.. Hændelser med en anden status eller type konverteres ikke. Navngivningen i består af SIS+CPR_NUMMER fra SIS. Integrationsstatus, annullering og afbrudsårsagskode sættes ikke i forbindelse med konverteringen Datamapning Figur 32 En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af UDB-hændelser. Indberetningsgrundlag (STÅ) Der konverteres kun STÅ indberetninger relateret til ordinære uddannelser, og derfor oprettes indberetningsgrundlag i kun på baggrund af indholdet fra SIS tabellen: INB_ORD_END. Der oprettes kun ét indberetningsgrundlag for den juridiske institution samt et for hver institutionsafdeling i samme indberetningsperiode i Indberetningsgrundlagene er ikke en en-til-en overførelse fra SIS til. Kun den seneste indberetningslinje konverteres, hvilket vil sige, at hvis der er fortaget en supplerende indberetning til en linje, vil det kun være nyeste supplering der medtaget. Der er altså ingen historik konverteret. Status på alle poster som relaterer sig til data fra SIS sættes derfor til Indberettet. Eventuelle rettelser til det indberettet skal foregå gennem SIS/Manuelt Hovedbehandling SIS tabellen INB_ORD_END indeholder kun indberetninger på ordinær uddannelse. Tabellen bliver grupperet på felterne INSTITUTIONSAFDELING, PERIODESTART og PERIODESLUT. Derved optræder en indberetningsperiode kun én 2020 Netcompany Side 58 af 69

59 gang for hver institutionsafdeling. På baggrund af hver indberetningsperiode bliver der dannet et indberetningsgrundlag for hver afdeling. Derudover dannes der for hver indberetningsperiode et juridisk indberetningsgrundlag, som alle institutionsafdelingernes indberetningsgrundlag tilknyttes. En forsimplet udgave af flowet til oprettelse af indberetningsgrundlag kan findes i Figur 33 nedenfor Efterbehandling Figur 33: En forsimplet illustration af flowet til oprettelse indberetningsgrundlag I efterbehandlingen oprettes der indberetningsgrundlag. Dette sker for ordinære uddannelser både bagud og fremad i tid, hvor der ikke tidligere er blevet oprettet indberetningsgrundlag. Dette sker ved, at alle GUEr grupperes efter start- og slutdato samt institutionsafdeling. Herefter beregnes der, hvilke indberetningsperioder de fordeler sig over. På baggrund af dette oprettes de nødvenlige indberetningsgrundlang for både juridiske afdelinger og institutionsafdelinger Datamapping En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af indberetningsgrundlag Indberetningsgrundlagslinjer (STÅ) Der konverteres kun tidligere indberettet STÅ, relateret til ordinære uddannelser. Konverteringen af indberetningsgrundlagslinjer (grundlinjer) tager udgangspunkt i indholdet af SIS tabellen: endelige_indberetninger, der suppleres med informationer fra relaterede tabeller, som er nærmere beskrevet i feltmapping på Toolkit. Grundlagslinjerne er ikke en en-til-en overførelse fra SIS til, men en summering af allerede indberettet STÅ. Der konverteres udelukkede seneste indberette grundlagslinje til uden henvisning til historik om tidligere/supplerende indberetninger/ændringer i indberetningen. Status på alle poster som relaterer sig til data fra SIS sættes derfor til Indberettet, og uden nogen angivelse om indberetningstypen er oprindelig eller supplerende. Eventuelle rettelser til det indberettet skal foregå gennem SIS/Manuelt Hovedbehandling Inden selve konverteringen begynder udvælges de indberetninger, som skal konverteres. Dette gøres ved, at de seneste hændelser, som ikke har en efterfølgende relateret indberetningen tilknyttet, findes for hver studieforløb. Hver af disse hændelser bliver herefter tilknyttet dets respektive indberetningsgrundlag og studieforløb. Konverteringen vil variere alt efter indberetningens opgørelsesmetode: UDVSTU: Konverteringen af grundlagslinjer ifm. med internationalisering sker ved, at der laves et look-up efter den relateret internationaliser i. Hvis dette ikke er muligt efterlades relationen blank. Andre oplysninger om internationaliseringen konverteres fortsat som angivet ved indberetningen i SIS. SEM: Indberetningsgrundlagslinjer der indberettes som semester-stå, vil i være baseret på indberetningslinjer i for for alle GUEr på det angivne semester. Eftersom det ikke er muligt at finde en tilsvarende sammenhæng i SIS, bliver der ved konverteringen oprettet en GUE kaldet Teori STÅ x. semester, Praktik STÅ x. semester eller Merit STÅ x. semester afhængigt af aktivitetstypen. X et angivet det semester som STÅen er indberettet for. Dette vil ikke være den 2020 Netcompany Side 59 af 69

60 fremadrettet praksis i, men vil alene blive oprettet i forbindelse med konverteringen. Alle GUEr, der oprettes på denne måde vil blive tildelt en bedømmelse med karakteren G Gennemført og være sat til ikke at fremgå på bevis. EKSSTÅ: Ved konverteringen af indberettet eksamensstå, findes det tilhørende skolefag i SIS opsat i S412 Fagindhold på den studerendes uddannelsesordning (Alternativt en uddannelsesordning med samme aktivitetsgruppekode), således at SUEn i kan tilknyttes grundlagslinjen. Tilsvarende gøres for GUEn. Hvis disse informationer ikke kan findes oprettes grundlaget med disse felter blanke. Når alle indberetningsgrundlagslinjer er konverteret, bliver indberetningsgrundlagene opdateret med det akkumuleret STÅ indberettet fordelt på aktivitetstype. I Figur 34 er vist hvordan flowet for oprettelse af indberetningsgrundlag forløber Efterbehandling Figur 34 En forsimplet illustration af flowet til oprettelse indberetningsgrundlagslinjer I efterbehandlingen oprettes fremtidige indberetningsgrundlagslinjer. Det vil sige, der oprettes indberetningsgrundlagslinjer for den ved konverteringen indeværende indberetningsperiode og frem i tid. Dette sker ved, der for alle GUEr og internationaliseringer med slutdato efter indeværende indberetningsperiodens start, oprettes en indberetningsgrundlagslinje efter reglerne opsat i Datamapping En komplet liste over hvordan tabeller og felter i SIS mappes over i kan findes i Toolkit på følgende link: Mapping af indberetningsgrundlagslinjer. 4.5 Dataejerskab og deling Data omkring personer, studieforløb mv. kan være relevante for flere institutioner ad gangen, men da disse entiteter samtidigt har en følsom karakter, kan disse data ikke være tilgængelige for alle institutionerne hele tiden. Derfor skal en persons data potentielt kunne læses af mindst én og op til flere yderligere institutioner. Dette gøres ved, at tildele ejerskabet af en person til én institution, og dele personens data med de resterende institutioner, der har behov for adgang til disse data Dataejerskab af person For at bestemme hvilken institution, der skal være ejer af en person, anvendes data for studieforløb til at prioritere institutionerne i forhold til dataejerskab for personen. For hver person prioriteres studieforløb på følgende måde: 2020 Netcompany Side 60 af 69

61 1. Aktive studieforløb, dvs. ingen afgangsdato, på ordinær uddannelse. Den seneste studiestart (indskrivning) har prioritet ved flere studieforløb. 2. Aktive studieforløb på ÅU. Den seneste studiestart har prioritet ved flere studieforløb. 3. Aktive studieforløb på IDV. Den seneste studiestart har prioritet ved flere studieforløb. 4. Inaktive studieforløb, dvs. har afgangsdato, med seneste afgangsdato har prioritet Den institution, hvor det højest prioriterede studieforløb hører til, bliver sat som ejer af den person Deling af personer For at alle institutioner har adgang til personer der har studieforløb hos dem, selvom de ikke er ejer af personen, udføres der en automatisk deling af personer lige efter dataejer på personerne er sat. Delingen giver læseadgang til personens stamdata. Denne deling foregår ved at udtrække data for alle studieforløb som er ejet af en anden institution end den institution der er dataejer af personen på studieforløbet. For hver kombination af person og institution der fremkommer på denne liste, vil den person blive delt med institutionen Deling af studieforløb og gennemførelsesuddannelseselementer på ÅU Nogle studerende kan være indskrevet på en åben uddannelser på flere institutioner, og den studieadministrative medarbejder har behov for at kunne danne sig et overblik over en studerendes ÅU studieforløb og personens gennemførelser på tværs af institutioner. Der opsættes derfor en automatisk deling af den studerendes GUEr og studieforløb mellem alle institutioner, hvor vedkommende har en ÅU indskrivning. 5 Tidsplan for konvertering Herunder er angivet tidsplanen for konverteringen i projektet. Konverteringerne til produktionsmiljøet er opdelt i én pilotkonvertering samt fire efterfølgende konverteringer opdelt i udrulningsbølgerne 1 og 2, som hver er inddelt i gruppe a og b. Pilotkonverteringen vil indeholde minimum én af hver type institution. I Tabel 14 på side 64 findes en oversigt over hvilke institutioner der er inkluderet i hver bølge Netcompany Side 61 af 69

62 Figur 35 - Tidsplan for konverteringsaktiviteter frem mod Go-Live. (Revideret: ) 5.1 Leverance af data fra kunden Det er blevet aftalt, at leverancer af data ikke vil være filer, men i stedet vil blive gjort med læseadgang til en eller flere Oracle databaser, med det datasæt som skal leveres. Det vil dog være påkrævet, løbende at afprøve opsætningen af konverteringsmotoren med de rigtige data. Derfor skal der, når det interne konverteringsmiljø er opsat, gives adgang til en ikke-anonymiseret kopi af en SIS database, som prøvekonverteringer kan foretages imod. Til pilotkonverteringer og delkonverteringer anbefales det, at der laves en fuld kopi af den eller de Oracle databaser, som Netcompany skal have læseadgang til, og derefter give direkte læseadgang til databaser med disse kopier. Det anbefales en kopiering, så der ikke skal udstilles direkte læseadgang til en SIS database i produktion, af hensyn til performance i produktionsmiljøet for SIS. Ved den endelige konvertering vil det vurderes, om det er bedre at give læseadgang direkte til og lukke for PROD af relevante SIS databaser, så det sikres, at alt data konverteres over til, og der ikke laves ændringer under konverteringen, der ikke kommer med. 5.2 Prøvekonverteringer [KO-11] Godkendt: Kell Kvist Dato: 18/05/2018 Der vil blive udført prøvekonverteringer løbende under opsætningen af konverteringsmotoren, i det omfang udviklerne har behov for at afprøve mappinger, transformationer, afstemninger eller lignende funktionalitet. Der vil dog også blive udført mere omfattende prøvekonverteringer i forbindelse med udviklingen af ny funktionalitet i og i forbindelse med større udvidelser af konverteringsmotoren. Disse prøvekonverteringer udføres i samarbejde med de relevante institutioner, som får mulighed for at kontrollere deres egne data i, og derved opdage uhensigtsmæssigheder i deres egne data og hjælpe konverteringsteamet med at forbedre konverteringsmotoren og kvaliteten af institutionens konverterede data. For at sikre kvaliteten af konverteret data, vil nogle prøvekonverteringer blive fortaget på ikke anonymiseret persondata. Dette vil blive gjort på en konverteringsserver opsat internt hos SIU, hvor adgangen er afgrænset til enkelte udviklere (se afsnit 7.2) Netcompany Side 62 af 69