Page Comparison

...

Formålet med Staging komponenten er at tilbyde en løsning til myndigheder, der ikke har teknisk mulighed for at udstille data på en snitflade, der kan tilgås af Orkestreringskomponenten, således at data kan sammenstille sammenstilles med data fra øvrige datakilder og leveres til visningsklienter. Forhold hos myndigheder er typisk grundet i tekniske forhold, fx at fagsystem fagsystemer er placeret på et lukket netværk, der ikke kan tilgås fra ekstern systemer. 

...

Staging er endvidere beskrevet i Referencearkitektur for Digitalt overblik under Staging-komponent, hvor det er et implementeringsscenarie, der udstiller alle integrationslagets services og kan anvendes på lige fod med andre realiseringer af integrationslaget.

Overordnet omfatter Staging komponenten følgende: 

• Staging komponenten udstiller data på vegne af myndigheden, fx til Orkestreringskomponenten og i henhold til standard datamodeller og snitflader gældende for Orkestreringskomponenten, fx standard snitflade for BorgervendtSag.

• Opbevaring af en kopi af myndighedsdata der skal vises i Mit Overblik. 

• Der er snitflader, hvor myndigheder kan aflevere data til staging, henholdsvis oprettelse, opdatering og slette.

• Omfatter den fornødne sikkerhed for opbevaring og udstilling af data, så data kan opbevares sikkert og kun kan tilgås af Orkestreringskomponenten.

Funktionelle kapabiliteter

• Staging komponent kan opbevare data fra forskellige myndigheder.

• Staging komponent kan opbevare data fra samme myndighed for forskellige datamodeller.

• Staging komponent understøtter de standardiserede snitflader specificeret for Orkestreringskomponenten, dvs. udstille udstiller de samme services for de forskellige datamodeller som andre datakilder udstiller.

• Staging komponent udstiller snitflader, så myndigheder kan opdatere data opbevaret i Staging komponenten. Det skal være muligt at lave deltaopdateringer af data, dvs. opdatere en delmængde af data, slette eller tilføje nye dataobjekter.

• Staging komponent kan udgangspunkt i udgangspunktet ikke tilbyde transformation af data. Ansvaret for tranformation fra myndighedens interne datamodeller til standard datamodel (model fra Orkestreringskomponent) ligger hos den dataansvarlige myndighed.

• Staging komponent kan nemt udvides med understøttelse af nye datamodeller i takt med , at disse implementeres i Orkestreringskomponenten.

• Data skal teknisk valideres inden de opdateres i Staging komponenten, men der skal ikke foretages nogen forretningsmæssig validering af data.

Funktionalitet er illustreret i nedenstående ArchiMate diagram diagram:

...

Non-funktionelle kapabiliteter

• Gennem REST og SFTP udstilles operationer til at opetteoprette, slette og opdatere data for datakilder. Således , således at datakilder kan lægge data op i Stagingkomponenten. Operationerne vil godtage JSON format.

• Staging komponent har den fornødne tilgængelighed, dvs. en tilgængelighed tilsvarende OrkestreringskomponentenOrkestreringskomponentens.

• Staging komponent kan deployeres som en selvstændig komponent - også uden for Orkestreringskomponentens miljø.

• Staging komponent har brugerstyring på opdatering af data, så en myndighed ikke kan opdatere data tilhørende en anden myndighed.

• Staging komponent har høj sikkerhed, da der opbevares personhenførbare og potentielt personfølsomme data. Diskene hvor data lagres er krypteret med AES-256, dvs. stærk kryptering.

• For at sikre sporing af data fra datakilde til bruger, hvor Stagingkomponenten står som datakilde, logger vi de svar, der sendes til Orkestreringskomponenten i en krypteret log. Den krypterede svar-log gemmes i minimum 30 dage.

Opbygning af Staging komponenten

...

For at kunne opbevare data sikkert fra forskellige myndigheder, benyttes en postgreSQL database. Data i databasen er krypteret , og lever derfor op til kravene om opbevaring af personfølsomme data. Krypteringen er AES-256, så der er tale om stærk kryptering.

For at sikre, at der kan opbevares data fra samme myndighed for forskellige datamodeller, lagres data således, at det skal fremsøges på datamodel og myndighed. Med en nøgle bestående af datamodel, version, myndighed og CPR-nummer sikres det, at men man kun får data fra den ønskede datamodel og i den version, der ønskes for liste data. For detalje data tilføjes også id på det dataobjekt, der ønskes. (se Orkestreringskomponent for liste og detalje data).

Udstilling af data

For at Orkestreringskomponenten skal kunne kalde Staging komponenten på samme måde som en hver anden dataservice, vil snitfladerne blive implementeret helt som var det en datakilde, der skulle udstille data. For hver borgervendt datamodel udstilles liste og detalje snitflade. For hver myndighedsvendt datamodel udstilles en snitflade.

Forespørgsler om data må kun komme fra Orkestreringskomponenten. Kun forespørgsler med gyldigt certifikat indeholdende korrekt CVR-nummer vil Stagingkomponenten acceptere og svare på. Dette klargør også Stagingkomponenten til at kunne blive flyttet over i eget miljø eller blive driftet hos 3. tredje part.

Identifikation af dataobjekter

For at Staging komponenten unikt kan identificere de objekter, datakilderne lægger op i Stagingkomponenten, skal datakilderne levere et unikt id indenfor inden for deres domæne sammen med hvert objekt. (uniktID + dataobjekt). Datakilderne har ansvaret for at vedligeholde sammenhængen mellem uniktID og dataobjekt.

For at sikre, at datakilder kun kan opdatere egne data, skal opdatering kun kunne foregå på objekter, der matcher ens eget domæne. Så alle nøgler til fremsøgning skal indeholde datakildens identifikator for at sikre afgrænsning mellem datakilderne.

...

For at myndigheder skal kunne udstille data gennem Stagingkomponenten, vil denne udstille tre REST endpoints til opdatering af data. 

• Overwrite . - Overwrite overskriver alt eksisterende med den liste, der forespørges med.

• Add - Add tilføjer den liste man forespørger med , til det data, der allerede er lagt ind i Stagingkomponenten.

• Delete - Delete sletter data fra den liste, man forespørger med i . I dette tilfælde , vil listen være objekt identifikatorer og ikke data objekter.

Operationerne implementeres, så de er idempotente, dvs. at man kan kalde delete eller add på de samme objekter flere gange, uden at operationen fejler.   

...

For at myndigheder, der ønsker at udstille data gennem Stagingkomponenten, kan uploade ved hjælp af SFTP udstilles en SFTP-server til dette. Serveren vil blive sat op med sikker brugeradgang og med en dedikeret folder til hver bruger/datakilde.

De operationer, der skal være tilgængelige gennem SFTP er overwrite, add og delete, hvilket spejler de operationer, der er tilgængelige gennem REST. Filformatet vil være JSON og for hver operation, skal der bruges et specifikt skema. Skemaet skal være ”operation”; ”data”. For operationerne overwrite og add er data en liste af dataobjekter med unikke identifikator identifikatorer for datakilden. For delete operationen er data en liste af unikke identifikatorer. Når filen er læst, vil den blive transformeret til et format, der stemmer overens med det, der benyttes i Stagingkomponenten, og det samme flow som for en REST operation, vil blive brugt. Når operationen er afsluttet, vil den originale fil blive slettet, og der vil blive genereret og lagt en kvittering til myndigheden. Skemaet for de tre operationer er indeholdt i snitflade-beskrivelsesdokumentet nedenfor.

...

Staging komponenten skal ligesom Orkestreringskomponenten kunne udvides. Så det at opbevare og udstille data fra flere datamodeller skal bygges efter samme principper, hvor det er konfigurationsbestemt. Data skal opbevares så generisk som muligt, således at data i det omfang det er muligt, er indkapslet og uafhængigt af specifik datamodel. For hver borgervendt datamodel skal det være cpr-nummer sammen med datamodel og dataservice, der kan bruges som nøgle til fremsøgning af objekter. For hver myndighedsvendt datamodel skal det være datamodel og dataservice, der kan bruges som nøgle til fremsøgning af objekter.

...

For at sikre at dataobjekter kan anvendes afi af Orkestreringskomponenten og visningsklienter, skal disse skema-valideres skemavalideres ved indlæggelse. Ved valideringsfejl vil der blive svaret med ”bad request” til datakilden, der ligger lægger data op. 
Der foretages ikke nogen form for forretningslogisk validering i Staging komponenten. 

Sammenhængen mellem liste data og detalje data bliver ikke valideret. Dette gør det også muligt , for datakilder selv at vælge, om de vil udstille begge typer data , (liste og detalje, ) eller kun en enkel enkelt type gennem Staging komponenten.

...

For at sikre sporing af data på tværs af de forskellige systemer, skal der være en unik referencesreference, der ikke indeholder personfølsomme data. Datakilderne skal vedligeholde et uniktID for objekter, der lægges op. Dette ID kan sammen med datakilde identifikation bruges på tværs af Staging komponent og datakilde. Mellem Staging komponent, Orkestreringskomponent og visningsklient kan korrelationsnøglen anvendes til at identificere forespørgsel og data. På den måde er der sporbarhed fra visningsklient til datakilde, også gennem Staging komponenten.  

...