Een bestelling doorzetten naar een ander systeem lijkt overzichtelijk. De webshop verstuurt de gegevens, de ontvanger verwerkt ze en er komt een bevestiging terug.
Maar wat gebeurt er als die bevestiging uitblijft?
Nog een keer proberen klinkt logisch. Alleen kan de eerste poging ondertussen gewoon zijn uitgevoerd. Dan maakt de tweede poging mogelijk een tweede bestelling, een tweede dossier of een tweede verzendopdracht aan.
De interessante vraag bij een koppeling is daarom niet alleen of hij werkt. Het is ook wat er gebeurt wanneer je niet zeker weet of hij heeft gewerkt.
Geen antwoord is niet hetzelfde als niets uitgevoerd
Bij een time-out weet de verzender niet automatisch waar het misging. Misschien kwam de opdracht nooit aan. Misschien is hij wel verwerkt, maar ging het antwoord verloren.
Die onzekerheid maakt blind herhalen riskant. AWS beschrijft precies dit probleem bij het automatisch opnieuw uitvoeren van verzoeken: een nieuwe poging kan onbedoeld extra objecten aanmaken. Bron: Amazon Builders’ Library.
Voor een ondernemer is dat geen abstract technisch probleem. Stel dat een bestelling twee keer bij de partij die de verzending verzorgt terechtkomt. Dan moet iemand uitzoeken welke opdracht geldig is en voorkomen dat beide worden verzonden. De automatisering heeft dan nieuw handwerk veroorzaakt.
Geef de opdracht een eigen identiteit
Een manier om herhalingen te herkennen is een unieke sleutel per bedoelde actie. De technische term hiervoor is een idempotency key.
Bij een nieuwe poging stuur je dezelfde sleutel mee. De ontvanger kan daarmee herkennen dat dit geen nieuwe opdracht is.
Stripe ondersteunt dit bijvoorbeeld voor het aanmaken en bijwerken van objecten. Een herhaald verzoek met dezelfde sleutel krijgt het eerder opgeslagen resultaat terug. Dat mechanisme heeft wel grenzen, waaronder de bewaartermijn van de sleutel. Het is dus belangrijk om de afspraken van de ontvangende API te kennen. Bron: Stripe-documentatie.
Alleen ergens een uniek nummer toevoegen is niet voldoende. Het ontvangende systeem moet er ook daadwerkelijk iets mee doen.
Dezelfde inhoud kan toch een nieuwe opdracht zijn
Twee opdrachten met dezelfde gegevens zijn niet per definitie dubbel.
Een klant kan bewust twee identieke producten bestellen. Twee documenten kunnen dezelfde inhoud hebben en toch bij verschillende aanvragen horen.
Daarom is alleen de inhoud vergelijken niet altijd genoeg. De identiteit hoort bij de bedoelde opdracht, niet uitsluitend bij de meegestuurde gegevens. AWS maakt dit onderscheid ook expliciet in zijn uitleg over veilige herhaalpogingen. Bron: Amazon Builders’ Library.
De praktische ontwerpvraag is: wanneer bedoelt iemand “probeer die vorige actie opnieuw” en wanneer “voer nog zo’n actie uit”?
Test ook de onduidelijke uitkomst
Een nuttige acceptatietest voor een koppeling is daarom bewust een bevestiging laten wegvallen nadat de opdracht is verwerkt.
Wat doet het systeem vervolgens? Verschijnt er een tweede object? Kan de oorspronkelijke opdracht worden teruggevonden? Is voor een medewerker duidelijk wat al is gebeurd?
Doe zo’n test in een veilige testomgeving, met herkenbare testgegevens. Niet met echte klantbestellingen.
Bespreek daarbij ook wie een onduidelijke uitkomst beoordeelt. Een foutmelding zonder vervolgafspraak verplaatst het probleem alleen naar degene die toevallig het dashboard opent.
Minder herstelwerk begint bij het ontwerp
Bij het laten bouwen van een koppeling hoort dus een concrete vraag: wat gebeurt er als dezelfde opdracht nog een keer binnenkomt?
Het antwoord moet verder gaan dan “dan proberen we opnieuw”.
Een bruikbare koppeling maakt duidelijk welke opdracht wordt uitgevoerd, welk resultaat daarbij hoort en wanneer menselijke controle nodig is. Dat is minder zichtbaar dan een geslaagde demonstratie, maar minstens zo belangrijk zodra echte bedrijfsprocessen ervan afhankelijk worden.