Indhold
Introduktion
Formål
Formålet med dette dokument er at beskrive systemarkitekturen for DDTV.
Læsevejledning
Nærværende dokument er tiltænkt udviklere og IT-arkitekter med interesse i DDTV og dens opbygning.
Overblik over DDTV
Løsningens afhængigheder
DDTV anvender NSP libraries:
- Digital Post Adapter
- audit-api
- security-api
- SOR enkeltopslagsservice (til SOR verifikation og navn på tandlægeklinikker)
- PersonInformationService (til kontrol af CPR, alder, død og navn på borger)
Øvrige afhængigheder:
- EDI Portal API
Løsningens overordnede opbygning
Nedenstående diagram viser opbygningen af DDTV services:
Den aktive del af DDTV lever udelukkende i NSP backend, og alle oplysninger opbevares i én simpel database (DDTV DB, se 5. Udkast til ER-model)
Der er i praksis er tale om 3 typer af services:
- DDTV-citizen: En OIOIDWS service hvor borgeren kan angive og anmode om ny tandlæge eller blot registrere eksisterende tandlæge. Borgeren kan også se status på tandlægevalg baseret på data fra denne service.
- DDTV-dentist: En DGWS service hvor tandlæger kan acceptere eller afvise en anmodning om optagelse
- DDTV-jobs: EN række forskellige asynkrone jobs, der bl.a.
- Finder de "snart 22 årige" og opretter dem i DDTV databasen
- Et oprydningsjob, der bl.a. fjerner alle oplysninger om døde borgere 1 år efter deres død
- Sender digital post til borgere med opfordringer, besked om statusændring mv.
- Et påmindelsesjob der finder de borgere, der skal have en påmindelse om valg af ny tandlæge
- Et "EDI-job" der finder de tandlæger, er blevet valgt siden sidste jobkørsel og som skal kontaktes via EDI
OIOIDWS og DGWS servicen udstilles gennem DCC på cNSP instanser og bør kun anvendes gennem DCC.
Services og jobs anvender i varierende grad CPR og SOR oplysninger til dels at validere eksistens af borger/organisation, søge status på borger/organisation og finde oplysninger knyttet til borger/organisation. Det sker udelukkende gennem anvendelse af services på NSP (PersonInformationService for CPR og SORES for SOR).
Digital Post sendes gennem Digital Post Adapteren.
EDI sendes gennem EDI-portalens API.
For yderligere indflyvning, sekvensdiagrammer, state-diagrammer mv. henvises til Arkitektur og design.
Moduler og driftsarkitektur
De tre services er 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 tre services har tilsammen følgende moduler i maven:
| Modulnavn | Beskrivelse |
|---|---|
| ddtv-schemas | Dette modul definerer API'en for de 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. |
| ddtv-common | Fælles kode for de services, primært utility-funktioner, bl.a. til logning, samt DAO-klasser. |
| ddtv-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 alle services installeret i BackOffice. Det er også her at alle ændringer bliver persisteret til databasen.
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 DdtvActor" kan man se, hvordan værdierne bliver gemt i DdtvActor-klassen i Java-koden.
| Brugertypen: Borger | Verifikation | Mapning til DdtvActor | ||
| SecurityContext | Ticket | Audience | Skal matche audience for IDWS servicen, defineret i property ddtv.audience i application.properties | |
| Validity | Er valid | |||
| Message | Verificeres ikke - må gerne være der | |||
| ActingUser | UserType | Skal være Citizen | actorType | |
| Identifier | Skal være der | actorIdType | ||
| IdentifierFormat | Skal være der | 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 | Identifier | Hvis angivet, skal der være givet fuldmagt (PowerOfAttorneyPrivileges) | procurationGiverId | |
| Organisation | Identifier | Må ikke være der | ||
| IdentifierFormat | Må ikke være der | |||
| Client | Verificeres ikke - må gerne være der | |||
| Brugertypen: System | Verifikation | Mapning til DdtvActor | ||
| SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
| Validity | Er valid | |||
| Message | Verificeres ikke - må gerne være der | |||
| ActingUser | Må ikke være der | |||
| PrincipalUser | Må ikke være der | |||
| Organisation | Identifier | Skal være der. Hvis der i property'en whitelisted.cvrs i application.properties er angivet en ikke-tom kommasepareret liste af cvr-numre skal actorId kunne findes i listen. | actorId | |
| IdentifierFormat | Skal være der | actorIdType | ||
Beslutninger
På NSP har man flere brugertyper, herunder følgende, som er relevante for DDTV:
- Citizen er en borger
- System er en systembruger
Servicen DDTV-Citizen kan kun anvendes af Citizen med OIOIDWS-kald. En borger kan selv anvende servicen, eller den kan anvendes af en fuldmagtshaver.
Servicen DDTV-Dentist kan kun anvendes af System, dvs. der kaldes med DGWS systemkald.