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:

NSP services > DDTV - Design- og Arkitekturbeskrivelse > DDTV_Komponentarkitektur_kun_komponenter.png

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: PersonInformation til CPR-opslag SORES til opslag af tandlæger i SOR DigitalPost til afsendelse af digital post til borgere EDIMessage til afsendelse af EDI beskeder til tandlæger
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 IdsasActor" kan man se, hvordan værdierne bliver gemt i selve IdsasActor-klassen i Java-koden.

Brugertypen: Borger			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

Brugertypen: System			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		Må ikke være der
	PrincipalUser		Må ikke være der
	Organisation	Identifier	Skal være der	actorId
		IdentifierFormat	Skal være der og skal være CVR	actorIdType
	Client	name	Skal være der ved kald til GetBlurredOrganisations, og må også gerne være der ellers (men verificeres ikke). Bruges aktuelt til at tjekke at det er STS'en der kalder, og ingen andre.	clientSystemName
		persistentUniqueKey	Skal være der ved kald til GetCurrentSalt, og må også gerne være der ellers (men verificeres ikke) Bruges til whitelisting af de anvendersystemer der skal hente salt til pseudoanonymisering.	clientKey

Beslutninger

På NSP skelner man imellem brugertyperne HealthcareProfessional (sundhedsfaglig person) og Citizen (borger). IDSAS kan kun anvendes af HealthcareProfessional. Alle HealthcareProfessional har adgang til at kalde IDSAS, uanset om de har en gyldig autorisation eller ej.

Som det ses i skemaet under sikkerhed, skelnes der i praksis på, om der er tale om en systembruger eller ej. Ved systembrugere må der ikke angives en ActingUser, og derfor heller ingen UserType. Kaldende til getCurrentSalt (pt. kun fra MinLog) og lookup (kun STS) må kun være systembrugerkald.