Tijdens het live gaan van CORV 1.0.1 hebben wij twee foute berichten ontvangen in onze service bus. Volgens het nieuwe CPA wordt zestien (16!) keer geprobeerd om een bericht opnieuw te versturen. Dit heeft bij ons in 32 mailtjes geresulteerd. Voorheen werd er acht keer gepoogd een bericht opnieuw te versturen.
Als een bericht functioneel fout is of niet doorgezet kan worden door het ontbreken van gegevens in de headers dan kunnen we zo vaak versturen als we willen maar dan gebeurd er niks meer mee. Indien een server niet reageert of tijdelijk berichten niet kan verwerken dan zijn 3 tot 5 retries al meer dan voldoende.
Kan er duidelijkheid worden verschaft waarom de keten 16 pogingen wil (een change waar wij niks van af wisten/ niet zo ver in het CPA hebben gekeken) en kunnen we het aantal pogingen, hopelijk eerder dan een volgende release, terug brengen? Er zijn betere manieren om met foutieve berichten om te gaan dan een server er mee te spammen.
Al sinds Go Live op 1 januari staat in de CPA het volgende:
<tns:ReliableMessaging>
<tns:Retries>16</tns:Retries>
<tns:RetryInterval>PT3H</tns:RetryInterval>
<tns:MessageOrderSemantics>NotGuaranteed</tns:MessageOrderSemantics>
</tns:ReliableMessaging>
Er is bewust gekozen voor 16 retries om de 3 uur zodat de kans klein is dat een bericht verloren gaat door connectie problemen buiten het service window van de verschillende ketenpartners. Gezien de beperkte service windows bij meerdere partners is er geen reden om het retry mechanisme aan te passen.
Het retry bericht wordt alleen getriggered wanneer een ketenpartner geen Acknowledgment bericht van jullie ontvangt. Wanneer jullie digikoppeling bijvoorbeeld een incomplete ebMS envelope ontvangt, waardoor het geen Acknowledgment kan sturen, dienen jullie synchroon een MessageError te sturen. Op dat moment stopt het retry mechanisme.