Image Modified

Læsevejledning

Denne Wiki side tager udgangspunkt i, at det er forretningsdomænet Ekstern kommunikation, der afsender WSRM beskeder. Det er p.t. DFDG Classic, hvor dette er implementeret, men forretningslogikken til WSRM abonnementer samt afsendelse af WSRM beskeder vil blive flyttet til forretningsdomænet Ekstern kommunikation.

Wiki siden fokuserer på afsendelse af WSRM beskeder, som på sigt erstattes af begrebet Webservicebeskeder. Dette vil p.t. ikke ændre på modellerne, idet modellerne sidestiller afsendelse af WSRM beskeder med Webservicebeskeder.

Modeller for afsendelse af WSRM beskeder via events

[TBD]Nedenstående beskriver de modeller og principper, der ønskes brugt, når et forretningsdomæne skal afsende WSRM beskeder via events.

Anbefalinger i forhold til brugsscenarier

...

Nedenstående tabel angiver den anbefalet brug af de tre modeller.

Model 1: Afsendelse af WSRM beskeder via egentlige forretningsmæssige hændelser (events)	Modellen anbefales som 1. prioritet og brugt når: Der er udviklet en forretningsmæssig hændelse (event), hvis datamæssige indhold giver nok information til at danne WSRM beskeden, der skal afsendes. Der ikke er særskilte forretningsregler for, hvem der må få WSRM beskeden i forhold til GDPR, udover de udover de regler, som implementeres i Ekstern kommunikation og som vil være gældende for alle WSRM beskeder.
Model 2: Afsendelse af WSRM beskeder via eventet SendExternalMessage fra Star.Foundation	Modellen anbefales som 3. prioritet og brug når: Hverken Model 1 eller Model 3 er dækkende for det forretningsmæssig behov for afsendelse af WSRM beskeden. Der er tale om WSRM beskeder, hvis datamæssige indhold er rige og/eller meget forretningsnært. Der er særskilte forretningsregler for, hvornår WSRM beskeden skal afsendes og/eller hvem der må få WSRM beskeden i forhold GDPR. Det værende sig forretningsregler udover dem som implementeres i Ekstern kommunikation.
Model 3: Afsendelse af WSRM beskeder via eventet DataOpdateretEvent fra Star.Foundation	Modellen anbefales som 2. prioritet og brugt når: Der ikke er udviklet ej heller skal udvikles en forretningsmæssig hændelse (event), som giver information om, hvad der er sket i forretningsdomænet. Der er tale om afsendelse af tynde WSRM beskeder, som kan dannes på baggrund af event DataOpdateretEvent. Der ikke er særskilte forretningsregler for, hvem der må få WSRM beskeden i forhold til GDPR, udover de udover de regler, som implementeres i Ekstern kommunikation og som vil være gældende for alle WSRM beskeder.

Model 1: Afsendelse af WSRM beskeder via egentlige forretningsmæssige hændelser (events)

...

Brugsscenarier:

Ovenstående begrundes med:

...

• at der ikke er grund til at kode og lade forretningsdomænet bestemme WSRM beskedens datamæssige indhold, når den egentlige forretningsmæssige hændelse indeholder nok information til at danne WSRM beskeden.

• at der ikke er grund til at lade forretningsdomænet bestemme, hvem der må få WSRM beskeden i forhold til GDPR, hvis forretningsregler herfor alene svarer til de regler, som bliver implementeret i Ekstern kommunikation.

Fordele:

• WSRM beskeder dannes på baggrund af de egentlige forretningsmæssige hændelser.

• Det publicerede forretningsdomæne behøver ikke at kende til ej heller angive, hvem der er modtagere af WSRM beskeder.

• Forretningslogik der afgør, hvem der må få WSRM beskeder i forhold GDPR, implementeres kun ét sted. Dette i forretningsdomænet Ekstern kommunikation.

• Fejlhåndtering, eksempelvis hvis en borgere ikke er tilknyttet et jobcenter, som skal have WSRM beskeden, kan håndteres ét sted. Dette i forretningsdomænet Ekstern kommunikation.

...

Brugsscenarier:

...

Det anbefales, at brugen af denne model minimeres og kun tages i brug i forhold til de situationer, der er nævnt i ovenstående.

Fordele:

• Forretningsdomænet Ekstern kommunikation skal kun implementere én EventReceiver, som kan aftage eventet SendExternalMessage (denne er allerede implementeret).

• Forretningsdomænet Ekstern kommunikation skal kun implementere én EventHandler, der kan aftage eventet SendExternalMessage (denne er allerede implementeret). Der skal således ikke laves nye EventHandlers til Ekstern kommunikation, for at forretningsdomænet kan afsende helt nye WSRM beskeder, idet WSRM beskedens datamæssige struktur og indhold er en del af eventet SendExternalMessage.

...

Brugsscenarier:

...

Ovenstående begrundes med:

• at der ikke er grund til at kode og lade forretningsdomænet bestemme WSRM beskedens datamæssige indhold, når der skal afsendes en tynd WSRM besked, som vil kunne dannes på baggrund af event DataOpdateretEvent.

• at der ikke er grund til at lade forretningsdomænet bestemme, hvem der må få WSRM beskeden i forhold til GDPR, hvis forretningsregler herfor alene svarer til de regler, som bliver implementeret i Ekstern kommunikation.

Fordele:

• Det publicerede forretningsdomæne behøver ikke at kende til ej heller angive, hvem der er modtagere af de tynde WSRM beskeder.

• Forretningslogik der afgør, hvem der må få de tynde WSRM beskeder i forhold GDPR, implementeres kun ét sted. Dette i forretningsdomænet Ekstern kommunikation.

• Fejlhåndtering, eksempelvis hvis en borgere ikke er tilknyttet et jobcenter, som skal have den tynde WSRM besked, kan håndteres ét sted. Dette i forretningsdomænet Ekstern kommunikation.

• Forretningsdomænet Ekstern kommunikation skal kun implementere én EventReceiver, som kan aftage eventet DataOpdateretEvent.

• Forretningsdomænet Ekstern kommunikation skal kun implementere én EventHandler, der kan aftage eventet DataOpdateretEvent. Der skal således ikke laves nye EventHandlers til Ekstern kommunikation, for at forretningsdomænet kan afsende helt nye/fremtidige tynde WSRM beskeder. Dog skal forretningsdomænet Eksterne kommunikation kunne understøtte, at eventet DataOpdateretEvent kan mappes til en helt ny/fremtidig tynd WSRM besked, hvilket vil kræve implementering i forretningsdomænet.

...