Stagingkomponent

Formål med Stagingkomponenten

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

Stagingkomponenten tilbyder en stagingfunktionalitet, 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 Stagingkomponent, hvor det er et implementeringsscenarie, der udstiller alle integrationslagets services og kan anvendes på lige fod med andre realiseringer af integrationslaget.

Overordnet omfatter Stagingkomponenten følgende: 

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

• Stagingkomponent kan opbevare data fra forskellige myndigheder.

• Stagingkomponent kan opbevare data fra samme myndighed for forskellige datamodeller.

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

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

• Stagingkomponent kan 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.

• Stagingkomponent 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 Stagingkomponenten, 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 oprette, slette og opdatere data for datakilder, således at datakilder kan lægge data op i Stagingkomponenten. Operationerne vil godtage JSON format.

• Stagingkomponent har den fornødne tilgængelighed, dvs. en tilgængelighed tilsvarende Orkestreringskomponentens.

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

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

• Stagingkomponent 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 Stagingkomponenten

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 det, at 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 Stagingkomponenten 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 tredje part.

Identifikation af dataobjekter

For at Stagingkomponenten unikt kan identificere de objekter, datakilderne lægger op i Stagingkomponenten, skal datakilderne levere et unikt id 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.

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

Transformation af data

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

Den transformation, der foregår i Stagingkomponenten, er mellem afleveringsformat, opbevaringsformat og svarformat. Så forretningsdata ændres.

Udvidelse med flere datamodeller

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

Validering af dataobjekter

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

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 enkelt type gennem Stagingkomponenten.

Håndtering af fejlbeskeder fra Orkestreringskomponenten

Fejlbeskeder fra Orkestreringskomponenten vil blive opsamlet og logget i Stagingkomponenten. 

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

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

Snitflader til Stagingkomponenten

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