Changelog
Dato | Version | Ændring |
---|---|---|
31/12-2016 | 1.0.0 | Initiel release af Dynamisk Testdata Generator |
03/03-2017 | 1.0.1 | Web interface tilføjet |
23/03-2017 | 1.0.2 | Environment tilføjet til generator. Webservice-modul opdateret til at gøre brug af json-1.0.4 i stedet for json-1.0.3. |
Indhold
1. Eksisterende løsning med statiske testdata
I den eksisterende løsning ligger data, der definerer tilknytningen mellem ejere og CPR-numre, i en særskilt database (bestillingsdatabasen). Disse data bruges af testdata-generator-ny version 1.1.5 til at generere data til stamdata databasen (personer og autorisationer). Det er ikke muligt at ændre i disse data efterfølgende, og der kan således som eksempel ikke ændres adresse for en person. Til gengæld kan alle testdata til enhver tid genskabes ved at køre testdatageneratoren.
2. Dynamiske testdata
Dynamiske NSP Testdata er designet til at tillade leverandører til NSP at oprette og ændre testdata. Førhen har det ikke været muligt at ændre i eksisterende data, og det har heller ikke været muligt at angive specifikke oplysninger som navn, adresse, egen læge osv. Disse data blev deterministisk genereret ud fra det valgte CPR nummer.
Alle relevante data til projektet Dynamiske NSP Testdata gemmes i DTG databasen og det skal være muligt i fremtiden at ændre forskellige relevante oplysninger for personer (som eksempelvis adresse og egen læge). Dette gør sig også gældende for data, der eksisterer i den nuværende løsning. Disse data skal altså flyttes til den nye løsning, så leverandører kan fortsætte med brugen af testdata, som de allerede har fået oprettet.
3. Databaser
Der indgår en del forskellige databaser i projektet idet der både skal hentes data fra den eksisterende stamdata database, læses fra bestillingsdatabasen fra det tidligere system samt skrives til en modeldatabase hvor alle tilstande og tilstandsskift skal opbevares. Ydermere skal der skrives til en ny stamdatadatabase således at den gamle og den nye database kan sammenlignes inden der skiftes over til udelukkende at bruge den nye database.
- Eksisterende stamdatabase (E-SDM) indeholder stamdata skrevet af testdata-importeren på baggrund af data produceret af testdata-generator-ny
- Ny stamdatadatabase (SDM) indeholder stamdata skrevet af CPR2importeren, Sikredeimporteren, Autorisationsimporteren og Yderimporteren på baggrund af filer produceret af den nye dynamiske testdata generator.
- Bestillingsdatabase (BST) indeholder ejerinformationer produceret af det gamle front-end system udviklet af Netic.
- Model database (DTG) indeholder al tilstand og skift mellem tilstande produceret dels af Bootstrapperen og dels af Webservicen i Dynamisk Testdata projektet.
4. Algoritme for delta og revisionsstyring
4.1. Løsningsdesign
Alle tilføjelser til og opdateringer af tilstandsdata i DTG databasen, bliver persisteret som hændelser (events). Alle hændelser persisteres i den samme tabel i databasen, hvor CPR-nummeret bruges som primær identifikation, og hvor der på hver hændelse er angivet en type.
Der bliver på den måde aldrig ændret noget i allerede eksisterende data, hvilket betyder, at det til enhver tid vil være muligt at fremsøge den komplette hændelseshistorik for en given dataentitet.
Visning af aktuelle data opnås ved at afspille alle hændelser for en given dataentitet. Det vil altså sige, at den oprindelige record indlæses som et objekt. Dette objekt bliver så efterfølgende opdateret ved at alle senere hændelser for objektet indlæses i kronologisk rækkefølge, med de relevante opdateringer til følge.
Systemet er designet til at gemme alle hændelser i den samme tabel i DTG databasen, tabellen indeholder revisionsnummer, ejer, CPR-nummer, typeangivelse samt et JSON tekst object som indeholder alle nødvendige informationer om den specifikke hændelse. Dette gør det nemmere i fremtiden at udvide systemet med flere typer af hændelser, samt at lave ændringer til eksisterende hændelser uden at skulle modificere tabeldefinitionen.
Før anvendere af NSP kan drage nytte af testdata, skal data fra DTG databasen behandles og eksporteres til et format, som kan læses af importerne til de forskellige registre. Dette gøres med en generator der kører med en fast frekvens. Hver gang generatoren kører, kontrolleres det i DTG databasen, om der er sket nye hændelser baseret på revisionsnummeret. Hvis det er tilfældet, trækkes de nye hændelser ud, hvorefter de konverteres til det relevante format og leveres til importerne. Generatoren holder styr på hvilke revisioner, der er blevet konverteret og importeret, og sikrer derfor en lineær generering af data i importerne.
4.2. Eksempel
Når en person oprettes gennem web-klienten, persisteres de af brugeren specificerede oplysninger som en InitielPerson hændelse. Når brugeren på et senere tidspunkt ønsker at ændre eksempelvis personens adresse, kan dette gøres via web-klienten. Ændring af personens adresse opretter en NyAdresse hændelse. Hvis personen efterfølgende fremsøges i web-klienten, vil webservicen sørge for at den seneste revision af personens tilstand præsenteres for brugeren.
5. Bootstrap
For at sikre at ikke alle eksisterende personer og autorisationer fra E-SDM skal oprettes i hånden, skal alle eksisterende data oprettes i DTG og SDM databaserne via en bootstrap proces. Processen tager udgangspunkt i BST databasen og henter derefter alle relevante data i E-SDM databasen og opretter dem som hændelser i DTG databasen. Herefter tager generatoren over som om hændelserne var oprettet via web servicen.
6. Integration til MitID Simulator
Ifm. oprettelse af testpersoner er der blevet lavet en integration til Digitaliseringsstyrelsens MitID Simulator.
Det skal understøtte anvenderes behov for at have sammenhængende data på tværs af systemerne, uden manuelt først at skulle oprette i DTG og derefter i MitID Simulatoren (eller vice versa) og potentielt løbe ind i problemer med allerede brugte personnumre.
Simulatoren udstiller dens egen API-beskrivelse via en OpenAPI specifikation.
Denne specifikation bruges til at generere den programmtiske klient, som DTG anvender, jvf. Husregler for udvikling til NSP#Webservices § 2.9.2.1
En kopi af specifikationen findes i kildekoden, i modules/webservice/src/main/resources/mitid-simulator.json