Det nye servicelandskab
Siden her er en skitse som skal videreudvikles i samforståelse med serviceaftagerne, i særdeleshed KSS leverandørerne.
Fælles designpatterns for alle servicetyper er nævnt i strategien for modellering af webservices på siden Den gode webservice
StatusService
En service, som skaber overblik over en borgers primære attributter indenfor et domæne (/forretningsområde). Dette primært med henblik på dashboardpopulering, overblik og aktuel status for borgeren. Statusservicen kan anvendes til at se, om det er relevant at læse yderligere oplysninger fra de fulde objekter i Get-metoder i Domæneservices.
Servicen har typisk kun personnummer som input og output er invariabelt.
Foreløbig regelsæt for data i en StatusService:
- Kun data for den aktuelle status (ingen historiske data)
- Kun data til at skabe et overblik over registrerede data i domænet (minimum af data i kollektioner)
- Nok data til at kunne afgøre, om der skal hentes yderligere oplysninger på Get-metoder i de enkelte domæneservices
- Data er filtreret i forhold til aftagers GDPR mæssige adgang hertil
Domæneservice
En service som med forskellige metoder stiller funktionalitet til rådighed for et givet domæne. I en Domæneservice indeholder Get-metoderne typisk de fulde dataobjekter.
Domæneservicen bør ikke have metoder, som ikke alle forventes opdaterede samtidig.
Create- Update, Deletemetoder - Ønsket er metoder som understøtter forretningsmæssige hændelser
Er "klassiske" på domæneservicen, bruges til at inddatere data til DFDG.
Designpatterns
Createmetoderne som opretter objekter returnerer den oprettede GUID i response. Denne er efterfølgende nøglen til opdatering og sletning.
Al oprettelse, opdatering og sletning af data der er direkte relaterede til en borger skal indeholde personnummer som en del af input (af hensyn til såvel sikkerhed som sporbarhed).
GetInfo-metoder
Metoder til udtræk af det fulde datasæt på et domæne.
Designpatterns
Skal understøtte udhentning af data pr. GUID som er udsendt i WSRM.
Bør indeholde enkle metadata om opretter: Myndighedstype, myndighedskode og sagsbehandler-id. Af GDPR-hensyne (dataminimering) ønskes oplysninger om navn på sagsbehandler ikke medtaget hvor det ikke er nødvendigt.
Metadata kan erstattes af forretningsmæssige data som med henblik på udvidet samarbejde imellem myndigheder udvides målrettet til den givne situation.
GetHistory
Metode til udtræk af historik på området. Vil ikke være tilstede på alle områder, men kun på specifikke områder hvor STAR ser behovet for historik.
Search-metoder
¤Dette indhold er under afklaring.
RuleServices
¤Dette indhold er under afklaring.
Beskedservice - WSRM
Al beskeddistribution - WSRM udsendelse samles i WSRMMessageService.
Designmønstre
WSRM'er gøres om muligt "tynde", dvs. laves til at indeholde et minimum af information af hensyn til GDPR-hensynes om at man sender information ud som aftager ikke specifikt har bedt om. Der gås i særlig grad efter at fjerne følsomme data fra WSRM'er.
WSRM'er skal indeholde en GUID som man i Get-metoder kan bruge til at hente den fulde information.
Det gamle servicelandskab
Kort optegning af det servicelandskab som vi er på vej væk fra, med henblik på at definere nogle begreber:
StatusService: Det var PersonStatusService
HistorikService: Det var PersonHistoryService
Domæneservice: (med det forbehold at de kun delvist levede op til begrebet som det ser ud nu). Det er fx. BookingService, AbsenceRegistrationService
RegistreringsService: PersonRegistrationService. Dens rolle bliver overtaget af domæneservices.
Huller i dette landskab
CompositeServices. Disse må anses for til tider at være et nødvendigt onde, som vi om muligt omgår ved at designe så de kan undgås.
Uddybende relevant læsning
Webservice-struktur (TO-BE) med overblik over domænerne og deres services.
Gennemgang af byggeblokke som uddyber domæneoverblikket.