Protocolissue bij data posten naar Maykin registers verhelpen

[sytskevanhasselt]

Description

We willen dat berichten die van KISS naar een maykin register verstuurd worden correct aankomen (lees nu eerst even de specific details). Daartoe moeten we:

• de documentatie uitbreiden met instructies over de inrichting van de ingress tussen KISS en OpenKlant/OpenZaak/OverigeObjecten (1pt)
  of
• Kiss zodanig aanpassen dat JSON-data die gepost wordt altijd als een enkel pakket met een Content-Length-header verstuurd wordt, ipv gechunked (3pt)

Estimate

3

Acceptance criteria

Afhankelijk van de gekozen oplossingsrichting:

• In de installatie handleiding opnemen dat je nginx moet gebruiken of je een ingress zo moet instellen dat berichten gebufferd worden. (bijvoorbeeld zoals Utrecht doet:

“.. door een EnvoyFilter te implementeren die hetzelfde bewerkstelligt via een HTTP Buffer Filter. Dit zorgt er voor dat de Istio-Proxy (i.e. Envoy) die als sidecar naast de OpenKlant container draait, de request blijft bufferen tot ie compleet is en deze dan naar Openklant stuurt inclusief content-length header. Net zoals Nginx dat by-default dus doet.” (Jordi Teterissa))

• Alle uitgaande posts bufferen en met een Content-Length-header versturen. Dus zonder Transfer-Encoding=chunked (Gemeente Utrecht (Elias el Khaldi) is bereid te testen).
  Dit kan per request, maar het heeft wel de voorkeur dit zo generiek mogelijk op te zetten en in de readme te benoemen, zodat bij toekomstige nieuwe calls niet per ongeluk de oude standaardmethode wordt toegepast. Bij voorkeur een mogelijkheid openlaten om ook berichten wel gechunked te versturen. Dat is niet per se noodzakelijk op dit moment, aangezien de kans dat we dit nodig zullen hebben (bv bij grote bijlagen) heel klein is.

Specific details

De default manier waarop .Net en bericht post wordt niet begrepen door het framework waarop OpenKlant is ontwikkeld. Gemeente Utrecht liep tegen een heel specifiek issue aan in de communicatie tussen KISS en Openklant, maar iets vergelijkbaars zou in theorie in de toekomst ook kunnen optreden bij andere componenten die op hetzelde framework zijn ontwikkeld (Objecten API of Open Zaak).

Het komt erop neer dat rechtstreeks posten vanaf een .Net applicatie naar een Django-applicatie niet werkt. Het bericht wordt dan 'gechuncked' verstuurd. Door er een ingress tussen te zetten die het bericht buffert en vervolgens als één geheel (met Content-Length-header) doorstuurt ipv in chunks, heb je dit probleem niet. Overigens: NGINX is de meest gangbare tussenlaag, die ook door ons en door PodiumD gebruikt wordt. En NGINX buffert standaard. Daarom hebben wij hier ook nooit last van gehad. Gemeente Utrecht gebruikt echter een ándere tussenlaag (Istio), en die buffert niet out of the box. Er zijn meer smaken en het is niet te voorspellen weke organisatie welke ingress gebruikt.

Test plan

• Given I have a KISS installation connecte to an OpenKlant-installation that does not buffer incoming message, and that i am a user that is not yet present as actor in OpenKlant
• When I post a Klantcontact from KISS
• Then I will return to the Startpagina an see a green confirmation message
• And I will be able to see the Klantcontact ánd the new Actor in the OpenKlant admin interface

Delivery notes

No response