...

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.

...

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.

...

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.

...

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

...

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

...

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

...

3   Ændringslog

Kilden til dette dokument kan findes på:

...