Indholdsfortegnelse

Arkitekturoverblik

SOR Opdatering Servicen (SORUS) 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 opdateringer af dette.

SOR interne services eksisterer allerede, men kan ikke udstilles direkte til brug for regioner, kommuner, og andre interessenter. Derfor bliver der udstillet en Opdater Webservice i SOR miljøet, som kan nåes fra NSP, og ligeledes bliver der udstillet en service i NSP, som kan nåes udefra. SORUS' primære funktionalitet er derfor at håndtere autentificere brugerne af systemet, og tillade gennemstilning af opdatering forespørgelselser ned til SOR miljøet. Opdater Webservicen sørger så for adgangskontrol til den/ specifikke resurse(r) som bliver berørt af forespørgelsen, samt transformationen af forespørgelserne til interne formater.

Design

Teknologi og design i forhold til NSP's Husregler

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.

Audit logning

For audit logning bliver følgende logget specifikt:

• MessageID - som listet i standard DGWS headers
• Operation - navnet på den SOAP operation der er kaldt
• Name - ejerens navn på det certifikat, som er brugt til at signere forespørgelsen; listet i AlternativeIdentifier i security DGWS headeren
• Organization - organisationens navn på det certifikat, som er brugt til at signere forespørgelsen; listet i AlternativeIdentifier i security DGWS headeren
• CVR - organisationens CVR på det certifikat, som er brugt til at signere forespørgelsen; listet i AlternativeIdentifier i security DGWS headeren
• CertID - FID/UID/RID på det certifikat, som er brugt til at signere forespørgelsen; listet i AlternativeIdentifier i security DGWS headeren
• CertType - typen af det certifikat, som er brugt til at signere forespørgelsen; listet i AlternativeIdentifier i security DGWS headeren
• Roles - listen af roller forespørgelsen har tilladelse til at bruge, som sendt med i User elementet i forespørgelsen
• Entities - listen af SOR ID'er forespørgelsen har tilladelse til at redigere i/under, som sendt med i User elementet i forespørgelsen

Statisk konfiguration i property fil

Servicen bruger to konfigurations filer, en til applikationen og en til logning. Fælles for de to konfigurations filer er, at det forventes de ligger i mappen system variablen jboss.server.config.dir peger på. Fælles for konfigurations filerne er også, at servicen skal genstartes, hvis den skal opfange ændringer i disse.

Applikation konfigurationen indeholder alle de parametre servicen har brug for, for at kunne operere. Indlæsningen af konfigurationen er konstrueret på en måde, således at de kan overskrives af andre sat via system variable. Dette kan være praktisk i forhold til eksekvering af integration tests, og eksempel på hvordan det kan gøres kan ses her: Integration tests. Selve de værdier man kan finde i applikation konfiguration filen, inklusiv deres standard værdier, kan findes her: sorus.properties.

Logning konfigurationen sørger for alt fejl- og info-logning kommer ned i en enkelt fil. Der benyttes biblioteket Log4J til logning, og er indstillet i forhold til NSP's husorden.

Dynamisk konfiguration i database

SORUS bruger kun dynamisk konfiguration et enkelt sted, og det er i forbindelse af autorisering af forespørgelser. CVR numre skal kunne tilføjes og fjernes løbende imens at servicen kører, uden at en genstart er nødvendig. Denne database bliver udelukkende brugt til CVR whitelisting af forespørgelser.

Servicen forventer at datasource til denne database er sat op igennem Wildfly, og er tilgængelig via Java Naming and Directory Interface (JNDI).

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 SORUS, baseret på images leveret af NSP.

Ikke tillade virksomheds OCES-certifikater

På trods af, at servicen skal tillade niveau 3 og 4 forespørgelser, så er det kun funktions OCES-certifikater fra niveau 3 som er tilladt. Der har været ønske om ikke at tillade virksomheds OCES-certifikater.

Flowchart

Nedenfor ses et succesfuldt kald igennem servicen for operationen CreateSorEntity. Flowet vil være det samme for alle operationer, hvor udelukkende kald og svar for SORUpdateServiceClient er anderledes.

Klasserne SorDBClient og SORUpdateServiceClient begge laver kald til eksterne systemer, som ikke er tegnet med.