Indholdsfortegnelse

Arkitekturoverblik

SOR2 SEB importeren er en del af en række opdateringer vedrørende Sundhedsvæsenets Organisationsregister (SOR). Denne service forbedre server-to-server integration med registeret, gør det lettere at automatisere abonneringen på ændringer i dette.komponent som bruges til at importere nationale sundhedsroller fra SEB. Disse anvendes bl.a. af STS'en til udstedelse og veksling af tokens.

Data kommer SEB, og bliver leveret til SEB importeren som en XML-filDe eksisterende SOR interne services genererer og udstiller allerede et ekstrakt af SOR databasen. Dette kan findes på filer.nsi.dk. Der er dog ønske om at udstille yderligere typer, samt være i stand til at lave forskellige typer af udtræk og opslag. At udnytte den eksisterende Stamdata Kopi Register Service (SKRS) kan dække mange af de forskellige udtræk fra de forskellige data typer. Mere avancerede opslag vil skulle foretages i SOR Opslag Servicen (SORLS). Datagrundlaget for begge disse integrationsmuligheder kommer af SOR2 importeren, som indlæser og indsætter data i den fælles stamdata database. Data kommer nede fra SOR udtræk servicen, og bliver afleveret til SOR2 importeren som en zip fil med en række CSV filer over SFTP. Når data er langt ind i stamdata databasen, så står automatiseret replikering for, at det kommer ud til alle centrale og decentrale NSP installationer.

Design

Teknologi og design

...

For at lægge en service på NSP, så skal Husregler for udvikling til NSP overholdes. I projektet er der gået ud fra version 2.1 af disse. Derudover følger importeren også rammerne udstukket af Implementering af Stamdata Import Modul version 0.6.

Statisk konfiguration i property fil

Importeren benytter standard-funktionaliteten til implementering af stamdata-importere. Projektet arver således fra sdm-parent projektet, og anvender funktionaliteten fra sdm-core til parsing, persistering mv. Dette er yderligere dokumenteret her.

Dataformat

Importeren forventer at der leveres én xml-fil indeholdende ét element, som indeholder et antal seb-roller formateret som en JSON-liste. Nedenfor er vist et eksempel på dette format.

<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">
  [
    {
      "cvr": "33257872",
      "rid": "37138663",
      "guuid": "d8b4326c-1ad6-466c-ba83-47b05f1980af",
      "rolename": "nspSundAssistR1",
      "unittype": "sorunits",
      "unit": "0",
      "unitoption": "unitandchildunits"
    },
    {
      "cvr": "33257872",
      "rid": "41542832",
      "guuid": "",
      "rolename": "nspSundAssistR1",
      "unittype": "sorunits",
      "unit": "0",
      "unitoption": "unitandchildunits"
    },
    {
      "cvr": "25450442",
      "rid": "1231593107593",
      "rolename": "nspSundAssistR1",
      "unittype": "sorunits",
      "unit": "0",
      "unitoption": "unitandchildunits"
    }
  ]
</string>

Importeren indlæser filen, og importerer hvert enkelt rolle-objekt. Attributten guuid er ikke påkrævet, og indeholder et globalt uuid for et medarbejdercertifikat. Hvis attributten er til stede i et rolle-objekt, indsættes der to rækker i databasen: En med SubjectSerialNumber dannet ud fra cvr- og rid-attributterne, og en med SubjectSerialNumber dannet ud fra guuid-attributten.

Fejlhåndtering

Importeren tjekker at filen har det korrekte format, herunder at længderne på værdierne i felterne cvr, rid, guuid og rolename ikke overstiger database felternes længder. Og bruger sdm-core bibliotekets standardfunktionalitet til at importere roller til databasen. Fejlsituationer skrives til applikationsloggen.

Statisk konfiguration i property-fil

Importeren bruger en række konfigurationsfiler til opsætning af importeren og dens logs. Alle disse filer forventes Importern bruger en række konfigurations filer, til opsætning af importeren og dets logs. Alle disse filer er forventet at ligge i et Wildfly modul unikt for importeren, og alle ændringer til disse kræver at importeren genstartes.

Importeren har standard værdier standardværdier for alle de properties som kan sættes i config.properties, så denne fil bruges til lave lokale overskrivninger af disse.

Brug af Docker under udvikling

NSP har et fremtidig ønske om, at kunne benytte Docker til fremtidige deployments af services på platformen. Der er allerede udstillet nogle images, således at serviceudviklere kan opstille et miljø der ligner produktion, til test og udvikling af deres services. For at understøtte denne retning, så er der blevet lavet et Docker image af SOR2 importeren, baseret på images leveret af NSP.

Flowchart

Nedenfor ses et processering forløb af en zip fil.

Gliffy DiagramnameSOR2 importer flowdiagrampagePin1