Stamdata
Løsningsbeskrivelse



Indholdsfortegnelse
1 Formål
2 Løsningsbeskrivelse for Stamdata
2.1 Delspecifikation A: Stamdata Register på NDP DoDi
2.1.1 Stam-1 Etablering af stamdataregister på NDP
2.1.2 Stam-2 Mekanismer til opsamling af stamdata
2.1.3 Stam-3 Stamdataparser
2.1.4 Stam-4 Initielt load
2.1.5 Stam-5 Angivelse af kilde til data i stamdataregistret
2.1.6 Stam-6 Historik for stamdata
2.2 Delspecifikation B: Service enabling af stamdata
2.2.1 Stam-7 Service enabling af hele registre
2.2.2 Stam-8 Returnering af registre fra servicen
2.2.3 Stam-9 Administrationsinterface til håndtering af publikationsrettigheder
2.2.4 Stam-10 Service enabling af autorisationsregistret
2.3 Generelle Krav
2.3.1 Stam-11 Overholdelse af operatørkrav
2.3.2 Stam-12 Overholde af krav til teknisk dokumentation
2.3.3 Stam-13 Performance
2.3.4 Stam-14 Open Source JAVA komponenter
2.3.5 Stam-15 Anvdendelse af SOSI biblioteket
2.3.6 Stam-16 Monitoreringssnitflade
2.3.7 Stam-17 Log
2.3.8 Stam-18 Standarder
2.4 Leverance og Test
2.4.1 Stam-19 Test af Stamdataregistret
2.4.2 Stam-20 Performancetest
2.4.3 Stam-21 Tidsplan
2.4.4 Stam-22 Afviklingsmiljøer
2.4.5 Stam-23 Løsningsbeskrivelse
3 Ændringslog

Formål

En præliminær beskrivelse af projektets tilgang til kravspecifikationen, der giver en kort beskrivelse af de løsningselementer, der vil blive brugt til at opfylde kravene i kravspecifikationen.
Dette dokument giver et overordnet overblik over hvordan de enkelte krav forventes imødekommet. For detaljer henvises til den tekniske dokumentation af produktet, hvor de enkelte løsningselementer er beskrevet i detaljer.

Løsningsbeskrivelse for Stamdata

Hvert krav i kravspecs refereres til ved krav-id og overskrift, efterfulgt af enten en tekstuel beskrivelse af hvordan kravet imødekommes, eller en reference til et specifikt løsningselement. For den fulde kravsbeskrivelse henvises til kravspecifikationerne.

Delspecifikation A: Stamdata Register på NDP DoDi

Stam-1 Etablering af stamdataregister på NDP

Den eksisterende løsning, der kører hos LMS i dag, vil blive genbrugt så vidt som muligt. En stor del af leverancen vil være dokumentation af datamodel, workflow, schemaer m.m.

Stam-2 Mekanismer til opsamling af stamdata

Stamdata fra kildedataleverandørene bliver leveret af operatøren på forskellige måder. Nogle hentes dagligt af operatøren via FTP, andre leveres af kildedataleverandøren på andre måder. Overførselen afhænger af den enkelte leverandør. Når operatøren har modtaget data, placeres de i Stamdatas data-indbakke for parserne. Driftoperatøren står samtidig for arkivering og backup af indkommende filer, så data i Stamdatas database kan føres tilbage til kilden. Der er ingen afvigelser fra den eksisterende løsning hos LMS.

Stam-3 Stamdataparser

De eksisterende parsere fra LMS genbruges, og der udvikles 2 nye parsere til hhv "Sikrede" og Doseringsforslag. Løsningen er allerede klargjort til at løbende kunne udvides med nye datakilder, og de enkelte stamdata kilder ender i hver deres tabel, så der er ingen restriktioner på evt. nye datakilder.

Stam-4 Initielt load

Det forventes at den eksisterende stamdata-database kan replikeres fra LMS til NSI regi. Da det er samme driftsleverandør og MySQL der bruges, forventes opgaven at være minimal, omend der skal laves en grundig aftestning af at alle data er korrekt replikeret.
Der eksisterer gratis værktøjer til denne slags sammenligninger. Det vil være op til operatøren at afgøre om en sammenligning overhovedet er nødvendig alt efter hvordan de har kopieret data fra LMS til NSI.

Stam-5 Angivelse af kilde til data i stamdataregistret

Da hver datakilde ender i sin egen tabel(er), og driftsleverandøren sørger for backup af alle indkommende filer, er det altid muligt at spore en enkelt række i stamdata registeret.

Stam-6 Historik for stamdata

Dette krav er opfyldt af den eksisterende LMS løsning.

Delspecifikation B: Service enabling af stamdata

Stam-7 Service enabling af hele registre

Kravet opfyldes af en DGWS 1.0.1 beskyttet webservice, der udstiller de ønskede håntag til kopiering af registre (inkl. historik). Autorisation til registret styres via en simpel web-gui, hvor administratorer kan give adgang på CPR+CVR-niveau, samt oprette nye administratorer.
Ved at lade administrationen foregå på den centrale DoDi vil rettigheder til at tilgå systemet blive propageret ud til alle NSP'er vha. MySQL replikering. Derved skal man kun administrere adgang et sted, og hvis en NSP går ned, kan requests uden videre rediregeres til en anden NSP.

Stam-8 Returnering af registre fra servicen

Data kan overføres i to formater, XML og FastInfoset. Der er mulighed for at tilføje andre output formater hvis det bliver nødvendigt. Da de data mængder der skal overføres i nogle tilfælde er meget store (millioner af data rækker), er det nødvendigt at effektivt kunne tilgå sevicen.
DGWS vil blive anvendt som bootstrap af et registerudtræk. DGWS bliver derved brugt til autentifikering og autorisering af anvendersystemer og deres publikationsrettigheder. Når anvendersystemet er godkendt tildeles det en sikker token som bruges til alle kald til servicen. Denne token vil give adgang til et enkelt register og man skal hente en ny token for hvert register man ønsker at tilgå. En adgangstoken er gyldig i samme tidsperiode som det STS ID-kort der blev brugt til bootstrap. Dette sikrer at den høje sikkerhedsgrad fra DGWS bebeholdes mens alle servicekald kan behandles af kopi-register-servicen meget hurtigt.

Stam-9 Administrationsinterface til håndtering af publikationsrettigheder

Der udstilles som nævnt en web-gui til at administrere publikationsrettigheder.

Stam-10 Service enabling af autorisationsregistret

Den ønskede service udstilles som en DGWS 1.0.1 beskyttet webservice. Det antages at input kun er cpr-nummer, og output fra servicen er en liste af autorisationer der er knyttet til cpr-nummeret samt deres tilhørende uddannelseskode. Hvis kravet om navn som søgekriterier fastholdes, vil servicen nødvendigvis skulle returnere en liste af 0-n autorisationer og m mulige personer der matcher forespørgselen.

Generelle Krav

Stam-11 Overholdelse af operatørkrav

De nuværende operatørkrav forventes at blive revideret når den nye operatør kommer dertil. Som udgangspunkt forventes det at samtlige krav i det nuværende dokument vil blive opfyldt, dog er der ikke nogen support-aftale på plads endnu. Det anbefales at man starter op på at få en support-aftale på plads inden den endelige idræftssættelse af produktet.

Stam-12 Overholde af krav til teknisk dokumentation

Alle krav til teknisk dokumentation opfyldes, pånær kravet om en brugervejledning til de brugervendte systemer, da der ikke findes nogle af disse.

Stam-13 Performance

Der udarbejdes en testplan i samarbejde med kunden, der vil sikre at de nævnte krav til performance vil blive sikret ved faktiske tests.

Stam-14 Open Source JAVA komponenter

Når kunden har bestemt sig for hvilken licens der ønskes brugt, sikres det at de rigtige headers vil blive en del af alt sourcekode og dokumentation.

Stam-15 Anvdendelse af SOSI biblioteket

SOSI Seal er den eneste SOSI komponent det giver mening at bruge, men denne bruges selvfølgelig.

Stam-16 Monitoreringssnitflade

Der udstilles en web-baseret monitoreringssnitflade, efter driftens ønske, der kan bruges til at overvåge de enkelte komponenter i stamdata registret.

Stam-17 Log

NSP-Util v2 bruges til at sikre en ensartet SLA logning på tværs af de udstillede services.

Stam-18 Standarder

Kravet opfyldes.

Leverance og Test

Stam-19 Test af Stamdataregistret

Kravet opfyldes vha unittests med >80% code coverage, målt i number-of-instructions, og integrationstests, der dækker de user stories der bliver identifiseret i løbet af projektet. Der trækkes rapporter ud af Hudson som dokumentation for både code coverage og funktionalitetsunderstøttelse.

Stam-20 Performancetest

Der udarbejdes en testplan i samarbejde med kunden, der vil sikre at de nævnte krav til performance vil blive sikret ved faktiske tests. Det forventes at alle performancetests vil blive afviklet i 3 miljøer
udviklermiljø
Formål: kvalitetssikring af testen, samt at fange evt. Leaks/bottlenecks tidligt
testmiljø hos operatøren/driften
Formål: afprøvning af komponenterne i et rigtigt NSP setup, for at fange evt. NSP- bottlenecks eller kompatibilitetsproblemer.
præproduktionsmiljø hos operatøren/driften
Formål: endelig trykprøve at komponenterne i forhold til de nævnte load-krav

Stam-21 Tidsplan

Som en del af kontrakten mellem Trifork og Kunden er der committet til en tidsplan. Der henvises til kontrakten for de endelige detaljer. De udførende personer på projektet er som følger
Brian Graversen – Projektleder
Thomas Børlum – Udvikler

Stam-22 Afviklingsmiljøer

Det forventes at operatøren/driften stiller de nævnte afviklingsmiljøer til rådighed, og der assisteres med deployment i alle de nævnte miljøer. De endelige tests bliver afviklet i præproduktionsmiljøet som nævnt tidligere.

Stam-23 Løsningsbeskrivelse

Dette dokument udgør løsningsbeskrivelsen, og dækker dermed dette krav.

Ændringslog

Kilden til dette dokument kan findes på:
https://svn.softwareborsen.dk/stamdata/trunk/Dokumentation