/
Webservice-struktur (TO-BE på moderniserende DFDG webservice)

Webservice-struktur (TO-BE på moderniserende DFDG webservice)

I det følgende beskrives den struktur som alle webservices, der udstilles af DFDG, er opdelt efter i forhold DFDGs i 2025 afsluttede modernisering. Strukturen baserer sig på den logiske serviceopdeling i forretningsdomæner og er inspireret af microservice. Selve udrulningen er sket gennem projektforløbet for moderniseringsprojektet - se DFDG moderniserings og forretnings roadmap for serviceaftagere for eksterne og DFDG moderniseringsroadmap Version 1.4 - KUN INTERN for interne - eller når der sker omlægning/modernisering i tilknytning til forretningsprojekter. 

Selve opdelingen følger nedenstående figur og for nærmere beskrivelse af de enkelte domæner se Gennemgang af forretningsdomæner - STARs økosystem

Baggrunden for denne domæneopdeling er at opnå for en bedre understøttelse af forretningen, en mere enkel og mere vedligeholdelsesbar systemportefølje, hvor ny/ændret forretning kan etableres hurtigt, effektivt og med minimal risici. En systemportefølje der er mere robust i drift og samtidig skalerbar i forhold til aftageres kaldemønstre. At STAR systemporteføljen lever op til anderkendte arkitekturstandarder og principper for offentelige it-løsninger. For flere detaljer se Principper og baggrund for DFDF forretningsdomæner og DFDG principper.

Selvom STAR deler DFDG i en række interne forretningsdomæner, kan DFDG fra serviceaftager stadige betragtes som DFDG i samlet forretning.

Generelle regler for webservices i forretningsdomæner   

Følgende er overordnede regler for oprettelse af webservices:

  1. En webservice snitflade og fejlkoder er på dansk (Bemærk der er undtagelser)

  2. En webservice hører til et forretningsdomæne

    1. Kun undtagelsesvis kan der oprettes webservices, der går på tværs af forretningsdomæner. Disse oprettes som composite services i forretningsdomænet Komposit.

  3. En webservice vil typisk arbejde på en enkel entitet eller en lille gruppe af tæt knyttede entiteter. Navnet på webservicen vil typisk beskrive hvilken hovedentitet, der arbejdes med.

  4. En webservice skal understøtte de operationer eller actions, der er behov for for at tilgå og behandle data. Det kan være Create, Read, Update og Delete operationer eller forretningsoperationer, der foretager en handling eller registrerer en hændelse (typisk actions).

    1. Dette betyder, at de enkelte services er komplette og selvstændigt afgrænsede.

  5. For hvert forretningsdomæne kan der efter behov oprettes status-webservices, der returnerer aktuel status for udvalgte forretningsområder under forretningsdomænet. 

  6. For hvert forretningsdomæne er der udstilling af kodelister anvendt i forbindelse med de forretningsdata, der er ejet af domænet. Disse kodelister er de primære kodelister, der skal anvendes af serviceaftagere.

    1. Anvender forretningsdomæne kodelister til data de ikke ejer, vil disse være sekundærer kodelister og vil følge indholdet af den primære kodeliste. Serviceaftagerer behøver ikke at aftage disse kodelister, men kan nøjes med at aftage de primære kodelister.

  7. For hvert forretningsdomæne kan der efter behov oprettes regelservice, der returnerer et aktuel forretningsregelsæt anvendt i forretningsdomænet. Serviceaftager kan anvende dette regelsæt i egen kode eller som referenceramme.

  8. Et forretningsdomæne kan udløse en pushbesked (WSB) på ændringer fortaget via webservice eller anden  i de forretningsdata domænet ejer 

Status-services inden for et forretningsdomæne

For hvert forretningsdomæne (de områder der er illustreret i ovenstående figur) oprettes efter behov services indeholdende f.eks. status- eller metadata opslag, hvis relevant for serviceaftager. Status-service som returnerer nøgledata om personen eller virksomheden for hele forretningsdomænet samlet. Målet med disse domæne specifikke status-services er at give serviceaftager et hurtigt overblik over de registrerede data, så serviceaftager slipper for at hente data fra mange forskellige services for f.eks. at kunne tilpasse en brugergrænseflade til den aktuelle status.

En sådan domæne Status-services kan f.eks. indeholde data som aktuel ledighed, kontaktgruppe, startdato for ledighed, personkategori osv. Det kan også være statusflag eller nøgledata. Ønskes et fuldt datasæt skal disse data skal hentes fra de enkelte services getmetoder eller hvis historik også ønskes fra gethistorikmetoder fra de enkelte services.

Følgende er principper for status-webservices for borger eller virksomhed:

  1. Kan returnere nøgledata om en entitet, som id, subtype, revisionsdato

  2. Kan indeholde statusflag, der fortæller om borgers/virksomheds status/tilstand, eller et flag, der indikerer, om der kan hentes flere relevante data andet steds.

  3. Kan i begrænset omfang indeholde lister af aktuelle data, som f.eks. om borger har et aktuelt fravær

    1. Generelt bør sådanne ligge i servicen, der understøtter adgang til entiteten, f.eks. i fraværs servicen

Disse principper kan dog fraviges, såfremt der som helhed giver en bedre understøttelse af borgeren og/eller sagsbehandlerens arbejdsgang og serviceaftager aftaler dette med STAR. 

De tværgående webservices er som følger:

Tværgående status-services

Tværgående status services

Regelservice

For hvert forretningsdomæne (de områder der er illustreret i ovenstående figur) oprettes efter behov services indeholdende regelmetadata. Regelmetadata-service returnerer forretningsregler som strukturerer data for givet delområde af forretningen f.eks. hvilke fravær, der er lovlige for givne kontaktgrupper og personkategorier.

Eksempler på regelmetadata er:

  • Business rules

  • Data quality rules

  • Valid values for reference data (code lists,..)

  • Wikis

  • Collaboration software

 

Kodelister

For hvert forretningsdomæne (de områder der er illustreret i ovenstående figur) oprettes efter behov services indeholdende f.eks. status- eller metadata opslag. Status-service som returnerer nøgledata om personen eller virksomheden for hele forretningsdomænet samlet. Målet med disse domæne specifikke status-services er at give serviceaftager et hurtigt overblik over de registrerede data, så serviceaftager slipper for at hente data fra mange forskellige services for f.eks. at kunne tilpasse en brugergrænseflade til den aktuelle status.

Codelist:

Webservicebeskeder

DFDG vil sende beskeder til serviceaftager som push beskeder. En webservicebesked vil i udgangspunktet være tynd og kun indeholde tilstrækkeligt indhold til at serviceaftager kan hente de nødvendige data i DFDG. Webservicer vil som udgangspunkt derfor ikke indholde forretningsdata.

Ud fra en webservicebesked kan det identificeret f.eks. hvilke borger det drejer sig og om hvilke data det drejer sig om man kan så hente borger aktuellet tilstand/data i DFDG på en getmetode. Har man som serviceaftager brug alle transaktioner mellem man sidst hentede i DFDG og den aktuelle tilstand/data, får man ved hver besked et transaktionsid. Dette kan så anvendes på en gethistorikmetode således alle trin kan hentes.

Adgang til webservicebeskeder

STAR vil stille generelle regler op for hvilke beskeder (også kaldet beskedtyper) en giver organisationstype må modtage og efter hvilke regler f.eks. et jobcenter på egne borgere eller en a-kasse på egne medlemmer, der er dagpengemodtager. Derudover opstiller STAR regler for hvilke beskeder et bestemt system hos en bestemt myndighed må modtage f.eks. bookinger til et plannersystem i Århus Jobcenter.

Med dette sikrer STAR, at ingen organisationer og systemer kan modtage beskeder de ikke lovligt må behandle.

Abonnement på Webservicebeskeder

En servicemodtager, der repræsenterer en bestemt myndighed og system, kan efter adgang er etableret derefter opsætte sit abonnement på de beskeder man netop i sin egen sammenhæng vil modtage. Dette sikre en høj grad af selvbetjening for serviceaftager.

STAR vil udstille webservice snitflader (og en brugergrænseflade i LSS) således, at serviceaftager selv kan administrere sine webservicebesked abonnementer.

Serviceaftager skal selv udvikle funktionalitet for at kalde webservicesnitflader, hvormed der kan bestilles genafsendelse af webservicebeskeder.

Genafsendelse ved fejl, skift af leverandører eller andet

I DFDG etableres service, hvor det er muligt at se de afsendte beskeder og deres status. Ved fejl vil DFDG forsøge at gensende beskeden og indtil dette lykkes vil spærre for yderlige beskeder på den pågældende borger.

En serviceaftager vil via service også kunne bede om at få gensendt webservicebeskeder f.eks. for en periode. Dette forudsætter dog at der er adgang til at modtage de ønskede beskeder i den pågældende periode for den pågældende borger.

 

 

 

 

Tilgængelighed: https://starwiki.atlassian.net/was