In de koppeling zaak- en documentservices lopen wij tegen het volgende probleem aan.
Indien in de vakapplicatie (zaakserviceconsumer) de status wijzigt, worden hiervoor kort achter elkaar (soms binnen één seconde) 3 aysnchrone berichten verstuurd vanuit de zaakserviceconsumer naar de zaakserviceprovider:
- Actualiseerzaakstatus om de nieuwe status te zetten.
- Updatezaak om de uitvoerende te verwijderen
- Updatezaak om een nieuwe uitvoerende toe te voegen
Bij het verzenden van de berichten door zaakserviceconsumer wordt er niet gewacht op een bevestigingsbericht door de zaakserviceprovider, de berichten worden direct achter elkaar in de juiste volgorde verzonden.
De berichten komen echter niet in de volgorde waarin ze verzonden worden binnen bij de zaakserviceprovider en "halen" elkaar onderweg in. Hiervoor zijn meerdere oorzaken te benoemen:
- Door het verschil in grootte van berichten kan het tweede bericht sneller over de lijn gaan dan het eerste bericht
- Bij het eerste bericht wordt de verbinding opgezet, deze verbinding kan gecached worden waardoor het tweede bericht sneller over de lijn kan gaan
- Er is sprake van load-balancing waardoor het tweede bericht sneller binnenkomt dan het eerste
Wij als zaakserviceprovider verwerken de berichten op volgorde van binnenkomst, waarbij de verwerking van het eerste bericht direct start na binnenkomst. Doordat de volgorde van de berichten bij aanlevering niet meer klopt, betekent dat het tweede bericht als eerste verwerkt wordt. De volgordelijkheid van berichten klopt vervolgens niet meer en het tweede bericht wat bij ons binnenkomt zullen wij niet verwerken doordat het tijdstipbericht eerder is dan van het reeds verwerkte bericht.
Het direct achter elkaar verzenden van berichten binnen eenzelfde zaak zonder te wachten op een bevestigingsbericht is naar ons idee niet wenselijk omdat dit tot problemen kan leiden in de volgordelijkheid. Dit zal namelijk ook tot problemen leiden als bijvoorbeeld het eerste bericht synchroon wordt afgekeurd. Het tweede bericht is dan al onderweg en zal gewoon verwerkt worden wat leidt tot een verschil bij de zaak tussen de zaakserviceprovider en de zaakserviceconsumer.
Als zaaksysteem kunnen wij dit probleem enkel oplossen door berichten niet direct te verwerken, maar om deze een aantal seconden on-hold te zetten. Hiermee wordt echter het near-realtime principe los gelaten en dit ligt naar ons idee niet in lijn met de standaard.
Verder is het binnen de standaard mogelijk om voor de genoemde wijzigingen één updatezaakbericht te versturen met daarin de statuswijziging en het ontkoppelen en koppelen van een nieuwe uitvoerende. Het lijkt dan ook de voorkeur te hebben om hier één bericht voor te versturen ipv drie, de standaard dwingt dit echter niet af.
Wij horen dus graag hoe er vanuit de standaard gekeken wordt naar de volgende 2 issues:
- Het direct achter elkaar verzenden van berichten binnen een zelfde zaak zonder het bevestigingsbericht af te wachten waardoor de volgordelijkheid niet gegarandeerd kan worden
- Het verzenden van meerdere berichten voor een wijziging wat ook met één bericht afgevangen kan worden.
Hallo Dave,
Zo te zien gaan hier enkele dingen mis en worden meerdere berichten verstuurd terwijl er in feite maar 1 enkele wijziging doorgevoerd wordt.
Het lijkt er sterk op dat in de vakapplicatie achter elk te wijzigen gegeven een trigger zit waardoor direct een wijzigingsbericht gestuurd wordt.
Waar het geschetste berichtenverkeer mank op kan gaan is dat in bericht 2 de zaakstatus zoals aangegeven in bericht 1 opgenomen moet zijn (was/wordt principe). Wanneer bericht 2 eerder verwerkt wordt dan bericht 1 moet dit een foutsituatie opleveren, de huidige/was situatie in het ZS komt immers niet overeen met de was situatie van het updateZaakbericht. Ditzelfde geldt voor berichten 2 en 3.
Controleren op basis van de was situatie is voor het ZS de beste optie om zeker te weten dat alle berichten in de goede volgorde verwerkt worden. De StUF foutmeldingen die gestuurd kunnen worden staan op pagna 133 van de StUF standaard, Tabel met mogeljke foutberichten.
Mogelijke fouten die teruggegeven kunnen worden zijn:
StUF058: Proces voor afhandelen bericht geeft fout met Desgewenst een omschrijving van de fout in het afhandelende proces
Wat dat betreft is jullie voorstel (en voorkeur) voor één enkel update bericht terecht en ook veel minder foutgevoelig. Belangrijk is ook de was/wordt situatie goed te valideren zodat de consumer weet waarom een wijziging niet opgeslagen is.
Hallo Michiel,
Bedankt voor je reactie. Als zaaksysteem keuren wij deze berichten nu inderdaad af indien de volgorde niet meer klopt. Wij sturen als zaaksysteem (nog) geen asynchroon foutbericht terug naar de vakapplicatie, dat zullen we wel gaan meenemen in onze ontwikkeling.
Het versturen van dergelijk foutbericht lost echter het probleem zelf niet op, maar legt dit enkel terug naar de vakapplicatie. Wat is het standpunt vanuit VNG met betrekking tot het achter elkaar verzenden van berichten zonder te wachten op een synchroon bevestigingsbericht?
Wachten op een synchroon bevestigingsbericht gaat niet werken bij asynchroon berichtenverkeer. Dit is dus geen oplossing.
Het terugsturen van een asynchroon foutbericht verlegt het probleem inderdaad naar de applicatie die het op moet lossen, daar zit immers ook de oorzaak van het probleem.
Een mogelijkheid is het bufferen van berichten net zo lang tot er een keer een bericht binnenkomt wat het begin van de puzzel is. Dit is echter geen wenselijke oplossing, op die manier kan het voorkomen dat wijzigingen niet of pas heel laat verwerkt worden wat weer andere vervelende gevolgen kan hebben. Bijvoorbeeld dat de volgende wijzigingen niet doorgevoerd worden.
De beste (en eigenlijk enige goede in mijn ogen) oplossing is de consumer applicatie alle wijzigingen in één enkel update bericht te laten versturen.