Implementere automatisk refresh av dialog ved endring

[elsand]

Introduksjon

Dialogporten skal la sluttbrukersystemer får en push notification hvis en dialog endres

Beskrivelse

For å kunne støtte bl.a. #331 og andre scenarioer der det er nødvendig for arbeidsflate/SBSer å kunne laste inn dialogen på nytt når den er endret, trenger vi å bygge støtte i DIalogporten for at det pushes en event til SBS-et om at en endring har blitt foretatt, slik at SBS-et da gjennom standard API kan laste dialogen på nytt. Dette gjelder i første omgang kun for detaljvisning av dialogen.

Implementasjon

Vi ser på å bruke GraphQL subscriptions for dette. https://chillicream.com/docs/hotchocolate/v13/defining-a-schema/subscriptions

Løsningen vil basere seg på Azure Service bus. Outbox-pattern anses som unødvendig, siden dette ikke handler om å sikre konsistens (i motsetning til Altinn Events, hvor vi faktisk skal skrive til et API og gjøre en tilstandsendring).

Det vil fungere som følgende (BFF vil proxy mellom react og DP, dette er utelatt her for enkelhets skyld):

1. Bruker åpner en dialog. I en og samme graphql request hentes dialogen, og det åpnes en graphql subscription som oppgir dialogId-en som korrelerings-id
2. Dialogporten mottar requesten, og oppretter en subscription til en forhåndsdefinert topic i Service Bus. Subscriptionen er satt med et korreleringsfilter, slik at kun events knyttet til den aktuelle dialog-iden konsumeres. Det holdes oppe en connection til klienten (enten for SSE eller websocket)
3. Tjenesteeier gjør en endring på dialogen gjennom tjenesteeier-API. Så fort endringen er commited til database, legges ut en melding på Azure Service bus som oppgir den aktuelle dialogId-en som korrelerings-id. Meldingen har kort TTL (<5 sekunder)
4. Alle tråder på alle replicas som har en subscription med filter som treffer denne dialogId-en får melding om dette, og omsetter dette til en event på GQL-subscriptionen.
5. Frontend laster dialogen på nytt.

Merknad:

• Innenfor TTL på meldingen vil en ny subscription føre til at meldingen mottas på nytt. Dvs. at for hver gang frontend laster en dialog som det er gjort en endring på innenfor TTL, vil det gjøre at en event mottas. Frontend må unngå at dette fører til reload-loops innenfor TTL. En måte er å skille på "loadDialogAndSubscribe" og bare "loadDialog", og bare gjøre sistnevnte ved mottatt event. Eventet vil også kunne inneholde informasjon om UpdatedAt, slik at frontend kan sammenligne med lastet dialog (hvis lastet dialog er nyere, ignorer event)

Gammel SignalR-basert tilnærming (ikke aktuell)

Vi implementerer en SignalR-hub som tilgjengeliggjøres sluttbrukern med biblioteket som tilbys av Microsoft for ASP.NET Core. Dette endpunktet konfigureres av arbeidsflate, og benyttes av statisk frontend. Dialogtoken blir benyttet for å autorisere requesten fra statisk frontend.

Når requesten mottas, sjekkes tokenet for gyldighet. Hvis tokenet er utløpt, indikeres dette med en 401 tilbake til statisk frontend, som da trigger en full refresh av siden som da vil innebære at et nytt dialogtoken blir benyttet.

Når tokenet er validert, hentes aktuell dialogId ut fra JWT-payloaden, og tilkoblingen blir lagt inn i en SignalR-gruppe som representerer dialogen, med noe ala await Groups.AddToGroupAsync(Context.ConnectionId, dialogIdFromJwt);. SignalR vil automatisk håndtere fjerning fra gruppen når connection faller bort av en eller annen grunn.

Ved endring av dialogen (når DialogportenService mottar domeneventet) kjøres det en notifikasjon om at dialogen er oppdatert, med noe ala await Clients.Group(dialogIdThatHasChanged).SendAsync("dialogUpdated", "");.

Dette vil underrette eventuelle lyttere, og react-frontenden vil da initiere en relasting av hele dialogen gjennom et kall til BFF-en.

Verdt å merke seg at så lenge brukeren holder oppe dialogen og ble autorisert ved registrering, vil den få notifikasjoner om at dialogen er oppdatert selv om dialogtokenet kan være utløpt eller til og med tilgang til dialogen er mistet. Dette anses som akseptabelt, siden man bare får informasjon om at dialogen er endret, og ikke hva endringen går ut på (dette må lastes på vanlig måte og er dermed gjenstand for vanlig autoriasjon)

Oppgaver

Preview Give feedback

1. Håndtere utsending av notifikasjoner ved endring av dialog
2. Utarbeide dokumentasjon (hvis relevant - enten oppdatere arbeidsdokument, eller legg inn ny fil i docs)
3. Legge inn e2e-test (hvis relevant)

[elsand]

Vurdere å bruke GraphQL subscriptions for dette. Edit: endret beskrivelse