Webservicebesked fejlhåndtering

 

As-is

På nuværende tidspunkt har vi to flows som er relevant for fejlhåndtering.
Disse flows har kun fokus på fejl, dermed repræsenterer de ikke de samlede flows for henholdsvis SendExternalMessage, og ProcessMessageQueue)

 

SendExternalMessage:

FejlhåndteringWSB-SendExternalMessage.drawio.png
SendexternalMessage

ProcessMessageQueue:

FejlhåndteringWSB-MessageQueueEntry.drawio.png
ProcessMessageQueue

Der eksisterer en langt mere detaljeret flow af ProcessMessageQueue her:

EksternKommunikation.WebhookService (2023-3) - Fysisk arkitektur - Confluence (atlassian.net)

 

Baseret på disse flows kan vi se at fejlhåndtering ligenu ikke har en separat håndtering af 4xx-,5xx-fejl eller exceptions.
Det står i kontrast til:https://starwiki.atlassian.net/wiki/spaces/FYS/pages/3950510658/Den+gode+WSB+webservicebesked#Returkoder-og-fejlh%C3%A5ndtering-(link-til-permanent-forretningsside) som laver en distinktion mellem 400 og 500, hvori 500 skal på genfremsendelseskøen, men ikke 400 eller exceptions.
Vi kan bekræfte dette da vi ser både 4xx og exceptions(Nullresponsecode fra messageDistributionId) i MessageQueueEntry.

Fejlhåndtering af WSB med Payloads:

Håndtering af payloads for genfremsendelse og almindelig afsendelse i tilfælde af at payloaden ikke kan serializes.

Det vi kan gøre nu, er at lave manuelle rettelser i payloaden, så den kan køre igennem.

Der er PT oprettet en sag på denne:
https://topdesk.star.dk/tas/secure/incident?unid=58f229a9411140d292e6995266d53532

 

Håndtering af Exceptions og 404:

Med udgangspunkt i T12 kan vi se hvilke former for beskeder som ligger på køen, der ikke bliver håndteret. .

Her tegner sig et billede af at exceptions og 404 får lov til at ligge på køen.
Det vi dog kan gøre i dette tilfælde er at kontakte de eksterne og sikre os at deres webhook url eller baseurl har ændret sig.
Der er et lignende billede med 404 og403(Certifikat issue, der forsøges genafsendt).

To-be