Open

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

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)

Denne model baserer afsendelsen af WSRM beskeder på at benytte de egentlige forretningsmæssige hændelser, altså de events, som er ejet af og publiceres fra forretningsdomænet selv.

Kendetegnet for disse events er:

• at de udvikles til brug for det enkelte forretningsdomænet med henblik på at fortælle andre forretningsdomæner, hvad der er sket i forretningsdomænet, eksempelvis at en tilmelding er opdateret

• at de udvikles i en til forretningsdomænet selvstædig event NuGet pakke, som kan genbruges på tværs af forretningsdomæner

• at de har nok datamæssigt indhold til, at forretningsdomænet Ekstern kommunikation kan konvertere indholdet fra eventet til den WSRM besked, der skal afsendes

• at de ikke indeholder målrettet information om, hvem der skal modtage WSRM beskeden (dette afgøres af forretningsdomænet, som er ansvarlig for afsendelse af WSRM beskeder)

• at de ikke indeholder målrettet information om, hvordan WSRM beskeden ser ud (dette afgøres af forretningsdomænet, som er ansvarlig for afsendelse af WSRM beskeder).

Modellen er illustreret i nedenstående figur.

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.

Ulemper:

• Forretningsdomænet Ekstern kommunikation skal implementere én EventReceiver pr. forretningsdomæne, der publicerer egentlige forretningsmæssige hændelser (events), hvorpå der skal afsendes WSRM beskeder.

• Forretningsdomænet Ekstern kommunikation skal implementere én EventHandler (sker i de enkelte EventReceivers) pr. egentlig forretningsmæssig hændelse (event), hvorpå der skal afsendes WSRM beskeder.

• Forretningsdomænet Ekstern kommunikation skal kunne konvertere de egentlige forretningsmæssige hændelser (events) til relevante WSRM beskeder. Dette er kun gældende for de egentlige forretningsmæssige hændelser (events), som giver anledning til afsendelse af WSRM beskeder.

• Det publicerende forretningsdomæne har ingen indflydelse på, hvem der må få WSRM beskeder i forhold til GDPR. Dette er ene og alene forretningsdomænet Ekstern Kommunikations ansvar.

Model 2: Afsendelse af WSRM beskeder via eventet SendExternalMessage fra Star.Foundation

Denne model baserer afsendelse af WSRM beskeder på at benytte et standard event (message) fra Star.Foundation til at kommunikere, at forretningsdomænet ønsker en WSRM besked afsendt. Dette standard event er navngivet SendExternalMassage, hvor Message er et udtryk for, at det er noget, som forretningsdomænet ønsker skal ske. Dette modsat de events, hvor navnet slutter med Event, som fortæller, at noget er sket i et forretningsdomæne.

SendExternalMessage er ene og alene udviklet til at kunne notificere eksterne såvel som interne aftagere med målrettet information (typisk en WSRM besked) fra det forretningsdomæne, hvorfra events publiceres. Dermed er det også givet, at forretningen i de øvrige forretningsdomæner ikke påvirkes, når dette event publiceres.

Kendetegnet for SendExternalMessage er:

• at det indeholder målrettet information om, hvilken WSRM beskedtype (ServiceId), der ønskes sendt.

• at det indeholder målrettet information om, hvem der skal modtage WSRM beskeden (det er således forretningsdomænet selv, som er ansvarlig for, hvem der skal have og må få WSRM beskeden i forhold til GDPR)

• at det indeholder målrettet information om, hvordan WSRM beskeden ser ud, idet eventets datamæssige indhold (Payload) skal være selve WSRM beskeden, som ønskes sendt.

Modellen er illustreret i nedenstående figur.

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.

Ulemper:

• Det publicerede forretningsdomæne skal kende samt angive, hvem der er modtagere af de enkelte WSRM beskeder. Dette er ensbetydende med, at det publicerende forretningsdomæne skal kende borgeres jobcenter tilknytning, a-kasse medlemskab, bopælskomme og på sigt andre myndigheder, som måtte ønske at få tilsendt WSRM beskeder.

• Det publicerende forretningsdomæne skal kende den datamæssige struktur for WSRM beskeden, som skal afsendes. Dette skyldes, at både WSRM beskedens datamæssige struktur og indhold er en del af eventet SendExternalMessage.

• Hvert publicerende forretningsdomæne kan risikere at skulle implementere samme forretningslogik (samme regler) i forhold til, hvem der må få WSRM beskeder i forhold til GDPR.

• Hvert publicerende forretningsdomæne skal implementere fejlhåndtering, eksempelvis hvis en borgere ikke er tilknyttet et jobcenter, som skal have WSRM beskeden.

• Forretningsdomænet Ekstern kommunikation skal mappe den datamæssige struktur og indhold for WSRM beskeden, som er medsendt i event SendExternalMessage, til forretningsdomænets egen repræsentation af WSRM beskeden. Dette er ensbetydende med, at den datamæssige struktur for WSRM beskeden skal implementeres i både det publicerende forretningsdomæne samt i forretningsdomænet Eksterne kommunikation.

Model 3: Afsendelse af WSRM beskeder via eventet DataOpdateretEvent fra Star.Foundation

Denne model baserer afsendelse af WSRM beskeder på at benytte standard eventet DataOpdateretEvent fra Star.Foundation til at kommunikere, at en dataentitet er blevet oprettet, opdateret eller slettet i det forretningsdomæne, hvorfra eventet publiceres.

DataOpdateretEvent kan med sit datamæssige indhold fortælle:

• hvilken dataentitet (eksempelvis tilmelding X), der er blevet oprettet, opdateret eller slettet

• hvilken operation, der er tale om, eksempelvis oprettelse, opdatering eller sletning

• hvilken type dataentiteten er (eksempelvis en tilmelding)

• hvilket forretningsområde dataentiteten befinder sig i (eksempelvis tilmeldinger)

• hvilket forretningsdomæne dataentiteten ejes af (eksempelvis Visitation og status).

Dette er ensbetydende med, at eventet er forholdsvist tyndt (få Properties), men indeholder nok data til at kunne notificere et til flere andre forretningsdomæner om, at en given dataentitet er blevet oprettet, opdateret eller slettet i det forretningsdomæne, hvorfra det publiceres. Eventet vil kunne publiceres og aftages fra alle forretningsdomæner.

DataOpdateretEvent er i forbindelse med afsendelse af WSRM beskeder tiltænkt brugt, når eksterne såvel som interne aftagere skal have en tynd WSRM besked, altså en besked uden egentligt forretningsmæssigt indhold. De tynde WSRM beskeden vil give aftager nok information til at kunne udføre et servicekald for at få mere information om den dataentitet, som er blevet oprettet, opdateret eller slettet.

Kendetegnet for DataOpdateretEvent er:

• at det kan publiceres fra alle forretningsdomæner med henblik på at fortælle andre forretningsdomæner, at en given dataentitet er blevet oprettet, opdateret eller slettet

• at det har nok datamæssigt indhold til, at forretningsdomænet Ekstern kommunikation kan danne den tynde WSRM besked, der skal afsendes

• at det ikke indeholder målrettet information om, hvilken tynd WSRM besked, der skal afsendes (dette afgøres af forretningsdomænet, som er ansvarlig for afsendelse af WSRM beskeder)

• at det ikke indeholder målrettet information om, hvem der skal modtage den tynde WSRM besked (dette afgøres af forretningsdomænet, som er ansvarlig for afsendelse af WSRM beskeder)

• at det ikke indeholder målrettet information om, hvordan den tynde WSRM beskeden ser ud (dette afgøres af forretningsdomænet, som er ansvarlig for afsendelse af WSRM beskeder).

Modellen er illustreret i nedenstående figur.

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.

Ulemper:

• Forretningsdomænet Ekstern kommunikation skal kunne konvertere DataOpdateretEvent til relevante tynde WSRM beskeder.

• Det publicerende forretningsdomæne har ingen indflydelse på, hvem der må få de tynde WSRM beskeder i forhold til GDPR. Dette er ene og alene forretningsdomænet Ekstern Kommunikations ansvar.