Indholdsfortegnelse


Arkitekturoverblik

SOR Opslag servicen er implementeret til at søge gennem SDM databasen og hente de relevante data som ønskes med de angivne søge parameter.

Hver opslag request returnerer data fra SOR2 registereret i NSP Stamdata modulet, som opdateres hver nat og det betyder at ændringer først vil være tilgængelige dagen efter når opslag servicen benyttes.

Denne service bruger SOAP protokollen og SOAP besked som kommunikation mellem hver klient og service endpoint. Opslag servicen er forsynet med fire SOAP operationer, nemlig:

  • GetSorEntity
  • ShakSorMap
  • SorShakMap 

Ovennævnte operationer er hovedsagelig læse operationer som henter data fra back-end SDM databasen. Følgende diagram viser en overordnede arkitektur:

Opslag-Arkitektur

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.


* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.

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
  • ActingUserType - system user eller healthcare professional user
  • OrganisationName - organisationens navn på det certifikat, som er brugt til at signere forespørgslen
  • OrganisationIdentifier - typisk organisationens CVR
  • OrganisationIdentifierFormat - format for organisationens identifier
  • ClientName - klientens navn
  • ClientPersistentUniqueKey - typisk CVR-FID/UID
  • Roles - listen af roller forespørgslen har tilladelse til at bruge, som sendt med i User elementet i forespørgslen
  • Entities - listen af SOR ID'er forespørgslen har tilladelse til at redigere i/under, som sendt med i User elementet i forespørgslen

Yderligere logges for ikke-systembrugere:

  • ActingUserIdentifier - typisk CPR
  • ActingUserIdentifierFormat - format for user identifier
  • ActingUserGivenName - fornavn
  • ActingUserSurName - efternavn
  • UserPersistentUniqueKey - typisk CVR-RID

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: sorls.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 af databaser

Opslag servicen bruger kun dynamisk konfiguration et enkelt sted, og det er i forbindelse af autorisering af forespørgsler i Sor databasen og selve forespørgsler i SDM Sor databasen. Hver enkel forespørgsel foretages mens servicen kører, uden at en genstart er nødvendig og autorisering foretages for enhver forespørgsel. Disse to databaser bliver udelukkende brugt til CVR whitelisting af forespørgsler og de tre soap operationer GetSorEntity, SorShakMap og ShakSorMap.

Servicen forventer at datasources til disse to databaser er sat op igennem Wildfly, og er tilgængelig via Java Naming and Directory Interface (JNDI).


* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.

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

Adgang

Servicen tillader niveau 3 og 4 forespørgsler for både OCES2 og OCES3. 'På vegne af' for MOCES tillades ikke adgang.

Flowchart

Nedenfor ses et eksempel på de fire forskellige kald igennem servicen for operationerne GerSorEntity, SorShakMap, ShakSorMap. Flowet vil være det samme for alle operationer, hvor udelukkende kald og svar til og fra SdmDBClient er anderledes.

SequenceDiagram-SorLookUpService

Klassen SorDBClient  laver kald til Sor databasen, som ikke er tegnet med.



  • No labels