Page History
...
Moduler og driftsarkitektur
===== Ole tager over herfra :) =======
De tre services er ret forholdsvis ens opbygget, og har en del fælles kode som de deles om via et maven-modul, har samme programstruktur og bruger samme database-modul.
De fire tre services har tilsammen følgende moduler i maven:
| Modulnavn | Beskrivelse |
|---|---|
| idsasddtv-apischemas | Dette modul definerer Selve API'en , for de tre eksterne services, defineres i dette modul som WSDL-filer. Modules to services, der kan kaldes ekternt, hhv. en OIO-IDWS WSDL fil for den borgervendte service DDTV-citizen, samt en DGWS WSDL fil for DDTV-dentist-servicen. Modulets primære formål er at generere Java-kode ud fra WSDL'erne, som kan bruges i de andre moduler. |
| idsasddtv-common | Fælles kode for de to modulerservices, primært utility-funktioner og, bl.a. til logning, samt DAO-klasser. |
| idsasddtv-integration-tests | En modul som indeholder alle integrationstests for begge services. |
| idsas-integrations | Et modul som indeholder integrationer, pt. kun "personinformation". Anvendes af "idsas-services". |
| idsas-services | Forretningslogik til alle services findes i dette modul, samt forretningslogik til de to batchjobs i "idsas-operations-web". |
| idsas-lookup-web | Web-modulet til Opslag, som håndterer opstart af service og producerer den war-fil, der skal deployes. |
| idsas-registration-web | Web-modulet til Slørring, som håndterer opstart af service og producerer den war-fil, der skal deployes. |
| idsas-salt-web | Web-modulet til hentning af salt, som håndterer opstart af service og producerer den war-fil, der skal deployes. |
| idsas-operations-web | Web-modulet med endpoints til automatiske jobs: Fornyelse af salt, sletning af inaktive sløringer. |
...
| integrations | Modul som indeholder integrationer:
|
| ddtv-citizen-service | Modul, som implementerer den borgervendte OIO-IDWS webservice. |
| ddtv-dentist-service | Modul, som implementerer den DGWS webservicen til brug for tandlæger. |
| ddtv-batch-service | Modul, som implementerer de 5 batchjobs nævnt ovenfor. |
| ddtv-integrationtest | Modul som indeholder integrationstests for de services, der kan kaldes eksternt. |
Driftsarkitektur
I praksis er de forskellige services fordelt på BackOffice og en eller flere Frontend-miljøer. Registration, Lookup og Salt kører alle på et NSP Frontend-miljø, og via en Kafka-kø, bliver alle ændringer sendt igennem MirrorMaker til Operations-servicen på NSP alle services installeret i BackOffice. Det er også her at alle ændringer bliver persisteret til databasen.Dog vil der i en overgangsperiode også være en Registration-service kørende på NSP BackOffice, som skriver direkte til databasen, når den bliver kaldt. Dette er for er være bagudkompatibel med de anvendere, som tog IDSAS i brug, før der blev omlagt til at sende alle ændringer igennem en Kafka-kø.
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Sikkerhed
Brugertyper
De enkelte brugertyper bestemmes ud fra modellen, der udstilles i Security API. Disse regler er opsummeret i skemaerne herunder. Sikkerhedsmodellen tager udgangspunkt i Security API - Guide til anvendere.
I kolonnen "Mapning til IdsasActor" kan man se, hvordan værdierne bliver gemt i selve IdsasActor-klassen i Java-koden.
| Brugertypen: HealthcareProfessionalBorger | Verifikation | Mapning til IdsasActor | ||
| SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
| Validity | Er valid | |||
| Message | Verificeres ikke - må gerne være der | |||
| ActingUser | UserType | Skal være HealthcareProfessional | actorType | |
| IdentifierFormat | Skal være CPR | actorIdType | ||
| Identifier | Skal være sat | actorId | ||
| GivenName | Verificeres ikke - må gerne være der | |||
| SurName | Verificeres ikke - må gerne være der | |||
| Credentials | Verificeres ikke - må gerne være der | |||
| PrincipalUser | Må ikke være der | |||
| Organisation | Identifier | Skal være der | ||
| IdentifierFormat | Skal være der og skal være CVR | |||
| Client | Verificeres ikke - må gerne være der | |||
...