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.

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 og vil typisk kun arbejde på en forretningsmæssig entitet, eksempelvis afholdte samtaler. En Domæneservice indeholder en til flere Get-metoder, typisk indeholdt de fulde dataobjekter. Antallet af Get-metoder på en Domæneservice er bestemt af de forretningsmæssige behov. Ydermere indeholder en Domæneservice en GetHistory-metode, hvorpå historiske data for Domæneservicen er udstillet.

Domæneservicen bør ikke have metoder, som ikke alle forventes opdaterede samtidig.

Regelsæt for en Domæneservice

• En Domæneservice hører kun til ét forretningsdomæne, eksempelvis DFDG kontaktforløb
• En Domæneservice arbejder typisk kun på en enkelt forretningsmæssig entitet, eksempelvis afholdte samtaler
• En Domæneservice understøtter forretningsmæssige hændelser og GRUD, hvor dette giver en forretningsmæssige mening
• En Domæneservice har selvstændige Get-metoder til at hente de enkelte forretningsmæssige entiteter, forretningsmæssige kollektioner af entiteter samt historik, hvor STAR ser behovet for dette

Create- Update- og Deletemetoder - Ønsket er metoder, som understøtter forretningsmæssige hændelser

Er "klassiske" på domæneservicen, bruges til at inddatere data til DFDG.

Designpatterns

Create-metoder, 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).

Get-metoder

Metoder til udtræk af det fulde datasæt på et domæne. Dette værende sig både enkelte entiteter samt forretningsmæssige kollektioner af entiteter.

Herunder liste-services med opremsning af objekter over tid.

Designpatterns

Skal understøtte udhentning af data pr. GUID, som er udsendt i WSRM beskeder.

Bør indeholde enkle metadata om opretter: Myndighedstype, Myndighedskode og Sagsbehandler ID. Af GDPR-hensyn (dataminimering) ønskes oplysninger om navn på sagsbehandler ikke medtaget, hvor dette 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-metoder

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. Det er vigtigt at skelne imellem revisionshistorik og liste-services med opremsning af objekter hvor hvert element kun fremstår i seneste revision.

Search-metoder

¤Dette indhold er under afklaring.

RuleServices

En RuleService indeholder metoder, der udstiller forretningsregler, som er implementeret i DFDG gælende for det givne domæne, eksempelvis hvilke fravær, der kan oprettes på de enkelte kontaktgrupper.

Regelsæt for en RuleService

• En RuleService er ikke person- eller virksomhedsspecifik
• En RuleService udstiller aktuelle forretningsregler, som er implementeret i DFDG

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 på moderniserende DFDG webservice) med overblik over domænerne og deres services.

Gennemgang af forretningsdomæner - STARs økosystem som uddyber domæneoverblikket.