...
Selve opdelingen følger nedenstående figur og for nærmere beskrivelse af de enkelte domæner se Gennemgang af forretningsdomæner - STARs økosystem (Rebecca og Knud modellen)
...
Selvom STAR deler DFDG i en række interne forretningsdomæner, kan DFDG fra serviceaftager stadige betraktes som DFDG i samlet forretning.
Generelle regler for webservices i forretningsdomæner
Følgende er overordnede regler for oprettelse af webservices:
- En webservice snitflade og fejlkoder er på dansk (Bemærk der er undtagelser og DFDG classic SOAP service er på engelsk)
- En webservice hører til et forretningsdomæne
- Kun undtagelsesvis kan der oprettes webservices der går på tværs af forretningsdomæner, disse skal oprettes som composite services i forretningsdomænet Komposit.
- En webservice vil typisk arbejde på en enkel entitet eller en lille gruppe at af tæt knyttede entiteter. Navnet på webservicen skal vil typisk beskrive hvilken hovedentitet der arbejdes med.
- 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).
- På den måde er Dette betyder at de enkelte services komplette og selvstændigt afgrænsede.
- For hvert forretningsdomæne kan der efter behov oprettes status-webservices, der returnerer aktuel status for udvalgte forretningsområder under forretningsdomænet.
- 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 serviceaftagerer
- 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 . Serviceaftagerer behøver ikke at aftage disse kodelister men kan nøjes med at aftage de primære kodelister.
- For hvert forretningsdomæne kan der efter behov oprettes regelservice, der returnerer et aktuel status forretningsregelsæt anvendt i forretningsdomænet. Serviceaftager kan anvende dette regelsæt i egen kode eller som reference rammereferenceramme.
- Et forretningsdomæne kan udløse en puchbesked på ændringer fortaget via webservice eller anden i de forretningsdata domænet ejer
- Disse pushbeskeder erstatter WSRM i DFDG classic
Status-services inden for et forretningsdomæne
For hvert forretningsdomæne (de områder 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.
...
- Visitering og StatusService
VisiteringOgStatus.VisiteringOgStatusStatusService - Kontaktforløb
Kontaktforloeb.KontaktforloebStatusService - Borgerkommunikation
Borgerkommunikation.BorgerkommunikationStatusService - Borgerindsats
TBD - JobSøgning og CV
TBDJobSearch.PersonJobSearchStatus - Virksomhedindsats
TBD - Match
Ingen status service i dette domæne pt forventes - Taxonomy
Ingen status service i dette domæne pt forventes - Ydelsesudstilliing
Ingen status service i dette domæne pt forventes - Eksterne data
EksterneData.PersonStatusService - Komposit
Ingen status service men se afsnit Tværgående status-services - TaxonomyEksternkommunikation
Ingen status service i dette domæne pt forventes
Tværgående status-services
Tværgående status services
Regelservice
For hvert forretningsdomæne (de områder 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ære der er lovlige for givne kontaktgruppe og personkategorier.
...
- Business rules
- Data quality rules
- Valid values for reference data (code lists,..)
- Wikis
- Collaboration software
Business rules:
Kodelister
For hvert forretningsdomæne (de områder 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:
...
- Visitering og StatusService
VisiteringOgStatus.CodeLists - Kontaktforløb
Kontaktforloeb.CodeLists - PersonCommunicationCodelistService
- Borgerkommunikation
EksterneData.PersonStatusService - Borgerindsats
Borgerindsats.CodeLists - JobSøgning og CV
JobSearch.CodeLists - PersonActivityCodelistService
- PersonJobSearchCodelistService
- Virksomhedsindsats
Virksomhedsindsats.CodeLists - Ekstern dataMatch
EksterneDataMatch.PersonStatusServiceCodeLists - Taxonomy
- Taxonomy.CodeLists
- MatchYdelsesudstilliing
MatchYdelsesudstilling.CodeLists - Ekstern data
EksterneData.PersonStatusService - Komposit
Komposit.CodeLists - Eksternkommunikation
EksternKommunikation.CodeLists
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å kladet beskedtyper) en giver organisationstype må modtage og efter hvilke regler f.eks. et jobcenter på egne borgere eller en a-kasse på egnemedlemmer 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 sikre 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 modtager. Dette sikre en høj grad af selvbetjening for serviceaftager.
STAR vil udstille webservice snitflader (og evt. et GUI interface !! Dette er ved at blive afklaret i STAR !!) således serviceaftager kan administrere sine webservicebesked abonnementer.
Genafsendelse ved fejl, skift af leverandøre 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
Bemærk: Disse vil erstatte WSRM beskeder for transition se Transitionsprincipper for DFDG service.