Integratiebetrouwbaarheid: retries, onzekere verzending en afstemming

Betrouwbaarheid betekent de bedrijfsgebeurtenis herstellen wanneer een HTTP-antwoord, worker of netwerkbevestiging ontbreekt. “Drie keer proberen” is geen financiële herstelstrategie. Een fout kan veilig weigeren, maar ook optreden nadat factuur of geldbeweging is opgeslagen.

Bewaar een identiteitenregister

Sla brontransactie, integratienamespace, documentsoort, inhoudsvingerafdruk, product-ID/nummer en laatste resultaat op. Leg voor geld tender-/refund-ID en factuur vast. Een ID na timeout wijzigen doorbreekt dubbelbescherming.

Een duurzame documentidentiteit is gebonden aan bedrijf, integratie en documentsoort. Bewegingsidentiteiten zijn uniek binnen bedrijf/integratie over facturen en bewegingssoorten heen. Rotatie of sleutelvervanging geeft ze niet vrij. Behoud dus de namespace.

Gebruik beide beschermlagen

Stuur Idempotency-Key bij herhaalbare writes. Identieke HTTP-herhaling geeft het opgeslagen antwoord waar beschikbaar; gewijzigde inhoud onder dezelfde key wordt geweigerd. De termijn van 24 uur en API-sleutelscope vervangen stabiele external_id niet.

Duurzame documentherhaling geeft het eerste voltooide documentantwoord. Bewegingsherhaling geeft de oorspronkelijke beweging met actuele afrekening en replayed: true. Gebruik die identiteiten ook na cacheverloop of sleutelvervanging. Een technische retry mag geen nieuw financieel event worden.

Classificeer voordat u plant

Een uitvoeringslease kan verlopen terwijl de boekhoudidentiteit blijft bestaan. Een hervatte verwerking herstelt het bestaande record, geen nieuwe zakelijke gebeurtenis.

Gebruik in uw client begrensde progressieve wachttijd met willekeurige spreiding voor herstelbare contention of beschikbaarheidsproblemen. Retrybudget en maximale achterstandsouderdom zijn integratiekeuzes met een eigenaar, geen productgaranties.

Scheid documentcommit van uitwisseling

Een verzendactie kan eerst de factuur opslaan en daarna een netwerkprobleem krijgen. Zoek het document en inspecteer transmissiestatus afzonderlijk. Een bekende afwijzing kan dezelfde uitgegeven bytes opnieuw gebruiken wanneer retry is toegestaan. Een onzekere uitkomst kan al aangekomen zijn en blijft geblokkeerd.

OpenPeppol maakt onderscheid tussen netwerkbevestiging en kopersbeslissing. Aflevering bewijst geen acceptatie of geld. Bewaak afrekening, transport en klantantwoord in afzonderlijke velden.

Voorbeeld: herstel na rotatie

ERP-factuur order-4711 is in namespace erp gemaakt, maar het antwoord ontbreekt. De sleutel wordt later geroteerd. De connector start met /me, bevestigt bedrijf en namespace en zoekt order-4711 op. Zo vindt hij de bestaande genummerde factuur.

Het voorschot wordt later met dezelfde tenderidentiteit gesynchroniseerd. De replay vindt de eerste beweging zonder een tweede voorschot. Een andere namespace en verzonnen factuur-ID zouden de beoogde continuïteit onderbreken.

Bewaak zakelijke uitkomsten

Volg ongestarte transacties, oudste vastgehouden item, geslaagde commits, permanente mappingfouten, onzekere verzending en afstemmingsverschillen. Tel HTTP-verzoeken apart van bedrijfsgebeurtenissen: een replay is geen nieuwe omzet.

Log opgeschoonde codes, IDs en tijden, nooit bearer secrets. Lees alle pagina's met consistente filters. Leg bij overlapping van extractie en writes het tijdvenster vast en stem late wijzigingen af. Wijs alarmeigenaar en escalatie toe volgens het echte serviceproces.

Accepteer herstel en draag over

Test verloren antwoord, gelijktijdige aanmaak, verlopen HTTP-cache, rotatie, bekende afwijzing en ambigu verzenden. Acceptatie vereist één financiële identiteit per event, verwacht saldo, geen herhaalde onzekere transmissie en een werkbare procedure voor een vervanger.

Reconcileer na incident de hele getroffen populatie vóór herstelmelding. Lever beslissingstabel, sleuteleigenaar, register, replayprocedure en providercontact aan operations. Finance krijgt resterende commerciële gevallen met impact en volgende actie. Incidentafhandeling organiseert coördinatie; API-integratie legt het contract vast.

Houd een beslissing bij iedere vastgehouden transactie

Bewaar waarom een item wacht, laatste onderzoek, toegestane volgende actie en wie mag vrijgeven. “Opnieuw proberen” zonder bekende uitkomst is geen voldoende instructie. Geef permanent geweigerde items een aparte herstelroute, zodat zij tijdelijke netwerkproblemen niet blijven blokkeren.

Verifieer na iedere grote mapping- of credentialwijziging een kleine gecontroleerde populatie met zowel nieuwe als herhaalde bronidentiteiten. Vergelijk niet alleen responsecodes, maar toegewezen factuurnummers en de afrekening. Een stijging van succesvolle requests kan immers bestaan uit replays. Deze controle maakt zichtbaar of de connector zakelijke continuïteit bewaart en of de wachtrij weer echte nieuwe gebeurtenissen verwerkt.