Stagingkomponent

Formål med Staging komponenten

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 med data fra øvrige datakilder og leveres til visningsklienter. Forhold hos myndigheder er typisk grundet i tekniske forhold, fx at fagsystem er placeret på et lukket netværk, der ikke kan tilgås fra ekstern systemer. 

Staging komponenten tilbyder en staging funktionalitet, hvor staging i denne sammenhæng betyder, at data som en myndighed vil levere til Mit Overblik, placeres eksternt i forhold til myndighedens it-miljø og udstilles på en standardiseret snitflade i henhold til standard datamodeller og snitflader for Orkestreringskomponenten.

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 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 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 

Non-funktionelle kapabiliteter

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

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

• 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

Opbevaring af data

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, 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. 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 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.

Opdatering af data gennem REST

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 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.   

Opdatering af data gennem SFTP

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 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.

Transformation af data

Staging komponenten transformerer ikke data. Data skal leveres som dataobjekter, der kan udstille gennem de snitflader, der er defineret for de forskellige datamodeller.

Den transformation der forgår i Staging komponenten er mellem afleveringsformat, opbevaringsformat og svarformat. Så forretningsdata ændres.

Udvidelse med flere datamodeller

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 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.

Validering af dataobjekter

For at sikre at dataobjekter kan anvendes afi Orkestreringskomponenten og visningsklienter skal disse skema-valideres ved indlæggelse. Ved valideringsfejl vil der blive svaret med ”bad request” til datakilden der ligger 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 type gennem Staging komponenten.

Håndtering af fejlbeskeder fra Orkestreringskomponenten

Fejlbeskeder fra Orkestreringskomponenten vil blive opsamlet og logget i Staging komponenten. 

Sporing af data på tværs af datakilde, Staging komponent, Orkestreringskomponent og visningsklient

For at sikre sporing af data på tværs af de forskellige systemer skal der være en unik references, 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.  

Snitflader til Staging komponenten

Teknisk beskrivelse af snitflader til Staging komponenten er beskrevet i nedenstående dokument.