Link til epics: 

MOD-5382: 1005.20.1 Webservicebeskeder STAR infrastruktur til afsendelse og modtagelse - Intern DFDG/STAR @2023-2DONE

MOD-5387: 1005.20.2 Webservicebeskeder Pilot til afsendelse og modtagelse med serviceaftager @2023-3
MOD-5394: 1005.20.3 Webservicebeskeder Drift af på udvalgte afsendelser og modtagelser med serviceaftager @2023-4

Forretningsbeskrivelse

Som en bruger/system vil jeg gerne kunne sende webservice beskeder til alle brugere/systemer der har oprettet et abonnement til en specifik beskedtype.

Beskedtyper oprettes, hentes og vedligeholdes gennem EksternKommunikation.BeskedtypeService (2023-3).

Abonnementer oprettes, hentes og vedligeholdes gennem EksternKommunikation.AbonnementService (2023-3).

Gensendelses logik (link: SPIKE)

Det ønskes at fejl af en webservicebesked afsendelse skal håndteres på en god måde. Hvis afsendelsen af en besked fejler, så skal events for samme borger og samme myndighed blokeres så at vi ikke risikerer at sende beskeder i forkert rækkefølge.

Der skal også laves en background windows service der tjekker en tabel der indeholder events der er blokerede i forbindelse med fejl. Denne skal køre konstant og håndtere events og prøve at afsende disse igen i korrekt rækkefølge, for hver borger og myndighed.

Teknisk analyse:
Hovedpunkterne for flowet af event fejlhåndtering er følgende:

1. Der skal oprettes ny event/message kø (f.eks. “MessageQueue”) tabel

2. Bloker afsendelse af webservice beskeder hvis der findes events på beskedkøen på baggrund af borger og myndighed

3. Ny windows service (f.eks. QueuedMessageDispatchService) skal konstant køre der henter events i MessageQueue og forsøger at afsende dem, i korrekt rækkefølge

4. Retry logik for beskedafsendelse i windows servicen ud fra RetryCount og timestamp for sidste forsøgt afsendelse

Der skal testes problematikken over at der muligvis kan opstå problemer med deadlocks f.eks. hvis et stort system fejler og der ophobe sig event beskeder på køen.

Løsningsmodel: 

Der skal oprettes en tabel der indeholder beskederne der bliver blokeret for borgeren og sat på kø, eller beskeder der fejler (f.eks. timeout).

Flow for webservicebesked afsendelse fejlhåndtering

Flow for QueuedMessageDispatchService (Windows service)

MessageQueue tabel skitse:

Returkoder og fejlhåndtering (link: Noter til webservicebeskeder)

Aftagere af webservicebeskeder skal for hver enkelt webservicebesked, som modtages fra DFDG, returnerer en HTTP status kode, der indikerer, hvorvidt webservicebeskeden er modtaget og færdigbehandlet eller om webservicebeskeden er fejlet. Dette på grund af, at det forretningsdomæne, som fra DFDG afsender webservicebeskeder, agerer på HTTP status koder og sørger for, at genfremsendelsespolitikken træder i kraft for fejlende webservicebeskeder.

Som serviceaftager må jeg først forretningsmæssigt processere modtagene beskeder efter jeg har kvitteret overfor DFDG.

Aftagere af webservicebeskeder skal benytte nedenstående intervaller af HTTP status koder for at indikere, hvorvidt en given webservicebesked er succesfuldt modtaget og behandlet eller om den er fejlet:

• Successful responses (200 – 299), der betragtes som værende, at den afsendte webservicebesked er succesfuldt modtaget hos aftager.

• Client error responses (400 – 499), der betragtes som værende, at den afsendte webservicebesked er fejlet hos aftager grundet en formodet fejl i DFDG. Serviceaftager kan oprette en FogBugz-sag hos STAR/DFDG. Det anbefales at medsende beskrivende fejlbesked i HTTP response body (samt i FogBugz).

• Server error responses (500 – 599), der betragtes som værende, at den afsendte webservicebesked er fejlet hos aftager grundet en fejl hos aftager selv. DFDG benytter sig efterfølgende af sin genfremsendelsespolitik ved fejlende webservicebeskeder (se nedenstående afsnit). Det anbefales ikke at medsende beskrivende fejlbesked i HTTP response body.

• Øvrige returkoder vil ikke munde ud i genfremsendelse.

• Timeout/manglende svar fra Webhook vil medføre, at DFDG benytter sig af sin genfremsendelsespolitik.

Når aftagere af webservicebeskeder ikke korrekt kan modtage og behandle en given webservicebesked, som modtages fra DFDG, enten på grund af forretningsmæssige årsager såvel som tekniske årsager, skal aftager returnerer en HTTP status kode, som indikerer fejl.

Genfremsendelsespolitik for fejlende webservicebeskeder

Når en aftager af webservicebeskeder med en HTTP status kode angiver, at en webservicebesked ikke kunne modtages og behandles, træder genfremsendelsespolitikken i kraft. Dette betyder, at:

• den fejlende webservicebesked forsøges genfremsendt uendeligt med en passende tidsforskydning, som bliver større gang for gang webservicebeskeden forsøges genfremsendt.

• der fremsendes ikke yderligere webservicebeskeder på samme borger fra det forretningsdomæne, som i DFDG var årsagen til, at den fejlende webservicebesked blev sendt. Disse webservicebeskeder ligges på kø til efterfølgende afsendelse.

• der fremsendes ikke yderligere webservicebeskeder på samme dataentitet, som webservicebeskeden omhandler (eksempelvis samme stillingsbetegnelse), fra det forretningsdomæne, som i DFDG var årsagen til, at den fejlende webservicebesked blev sendt. Disse webservicebeskeder ligges på kø til efterfølgende afsendelse.

Når genfremsendelsespolitikken ligger webservicebeskeder på kø, er det for at sikre, at den forretningsmæssige rækkefølge af webservicebeskeder overholdes, eksempelvis pr. borger inden for et givent forretningsdomæne i DFDG. De webservicebeskeder, der ligger på kø, vil bliver afsendt fra DFDG, når aftager har modtaget og behandlet den oprindelig fejlende webservicebesked.

DFDG stiller krav om, at aftagere af webservicebeskeder stiller en teknisk kontakt (email/telefon), som kan kontaktes, når en og samme webservicebesked fejler vedvarende. Aftagere som benytter Topdesk bedes benytte Topdesk.