Wat moet er gebeuren wanneer een externe service niet beschikbaar is?

Het is 9:14 uur 's ochtends en uw webshop stopt met het synchroniseren van orders naar uw ERP omdat de API van de verzendmaatschappij een timeout retourneert. Niemand merkt dit twee uur lang op, totdat een klant belt en vraagt waarom hun orderbevestiging nooit is aangekomen. Dit scenario speelt zich in enige vorm af bij vrijwel elk bedrijf dat geïntegreerde systemen gebruikt — een betalingsgateway, een boekhoudpakket, een CRM of een carrier-API valt tien minuten uit, en het ripple effect duurt de hele dag.

De meeste bedrijven denken hier pas over na nadat het al een keer is gebeurd. Dit artikel gaat door wat er technisch en organisatorisch daadwerkelijk moet gebeuren op het moment dat een externe service onbereikbaar wordt, zodat de storing klein blijft in plaats van een crisis te worden.

Waarom gebeurt dit steeds opnieuw, zelfs met "betrouwbare" API's?

Elke externe service waarvan u afhankelijk bent — een betalingsprovider, een webshopplatform, een logistieke API, een boekhoudpakket als Exact Online of Twinfield — zal uiteindelijk uitvallen. Niet omdat de leverancier onvoorzichtig is, maar omdat 100% uptime niet bestaat. Voeg uw eigen netwerkproblemen, verlopen API-tokens, rate limits en geplande onderhoudsvensters toe, en u kijkt tegen tientallen kleine onbeschikbaarheidsevenementen per jaar in een typisch integratiesysteem aan.

De fout is niet dat de storing gebeurt. De fout is het bouwen van een integratie die aanneemt dat het nooit zal gebeuren.

Wat breekt er als niemand rekening hield met downtime?

Hier is een concreet voorbeeld dat we regelmatig zien in op FileMaker gebaseerde systemen: een script roept een externe API synchroon aan — de gebruiker klikt "Order verzenden," FileMaker wacht op een respons, en als de API niet reageert binnen de timeout, hangt het script, geeft een onverwerkt foutbericht of faalt stilzwijgend.

De gevolgen stapelen zich snel op:

• De order is in FileMaker aangemaakt maar bereikt nooit de ERP — geen foutmelding, dus niemand volgt op.
• De gebruiker, gefrustreerd door de hang, klikt opnieuw "Verzenden" — waardoor zodra de service weer actief is, een duplicaat order ontstaat.
• Een record wordt gemarkeerd als "gesynchroniseerd" hoewel de aanroep mislukte, omdat de vlag was ingesteld voordat het antwoord werd gecontroleerd.
• De storing komt pas dagen later aan het licht, wanneer iemand handmatig orderaantallen tussen twee systemen vergelijkt.

Niets van dit alles wordt veroorzaakt door de storing zelf. Dit wordt veroorzaakt door een integratie zonder gedefinieerd gedrag op het moment dat het fout gaat.

Wat moet er gebeuren op het moment dat een aanroep mislukt?

Er is een voorspelbare volgorde die een goed ontworpen integratie moet volgen. Beschouw het als een beslissingsschema, niet als een enkele fix:

1. Detecteer de storing correct. Onderscheid tussen "geen respons" (timeout), "service zegt nee" (4xx/5xx fout) en "service accepteerde het maar langzaam" (202 Accepted, nog steeds verwerkt). Elk vereist een ander antwoord.
2. Laat de storing de gebruiker nooit blokkeren. De persoon die de order invoert, mag niet naar een bevroren scherm staren. Zet de aanvraag in de wachtrij en laat hen doorgaan met werken.
3. Probeer opnieuw — maar met limieten en backoff. Een enkele herpoging onmiddellijk na een timeout raakt vaak dezelfde overbelaste server. Wacht, herhaal dan met toenemende vertragingen (bijv. 30 seconden, 2 minuten, 10 minuten) en stel een maximum aantal pogingen in.
4. Sla de mislukte aanvraag ergens duurzaam op. Niet in een variabele die verdwijnt wanneer FileMaker sluit — in een tabel, een logboek of een wachtrij die een herstart overleeft.
5. Vlag het voor een mens, uiteindelijk. Als de herpogingen uitgeput zijn, moet iemand het weten — niet door het zelf drie dagen later te ontdekken.
6. Markeer nooit stilzwijgend iets als gedaan dat niet gedaan is. Dit is de meest voorkomende en schadelijkste kortsluitingen die we in het veld zien.

Hoe bouw je eigenlijk een retry-wachtrij die werkt?

In de praktijk betekent dit het toevoegen van een klein stukje infrastructuur dat de meeste integraties overslaan: een wachtrij-tabel.

Een typisch ontwerp ziet er als volgt uit:

• Een wachtrij-tabel met velden voor: payload, doeleindpunt, status (in behandeling / opnieuw proberen / mislukt / verzonden), aantal pogingen, volgende herpoging timestamp en laatste foutbericht.
• Een geplanned script (elke 1–5 minuten via FileMaker Servers planning, of een scriptingengine als FMBetterForms als de synchronisatie vanuit een weblaag wordt uitgevoerd) dat in behandeling zijnde en voor herpoging bestemde records oppikt en opnieuw probeert.
• Een exponentiële backoff-regel, zodat herpoging #1 30 seconden wacht, herpoging #2 2 minuten wacht, herpoging #3 10 minuten wacht, en daarna wordt het als mislukt gemarkeerd in plaats van voor altijd opnieuw geprobeerd.
• Een zichtbaar dashboard of waarschuwing — zelfs iets eenvoudigs als een lay-out met alle records met status "mislukt," eenmaal per dag gecontroleerd, of beter nog, een geautomatiseerde e-mail/Slack-waarschuwing op het moment dat een record een mislukkingsdrempel overschrijdt.

Dit patroon is van toepassing of de externe service nu een betalings-API, een verzendmaatschappij, een boekhoudpakket of een AI-service is die vanuit FileMaker wordt aangesproken (bijvoorbeeld een Klai-aangedreven opzoek- of verrijkingsstap). De AI-aanroep is in dit opzicht niet anders dan elke andere API-aanroep — als deze onbereikbaar is, moet de workflow een gedefinieerde fallback hebben, geen crash.

Wat moet de eindgebruiker daadwerkelijk zien?

Dit is waar veel integraties hun eigen gebruikers stil teleurstellen. De technische herpoging-logica kan onberispelijk zijn, en de ervaring voelt toch kapot aan als de interface niet eerlijk communiceert.

Goede praktijk:

• Toon een duidelijke, niet-alarmeringsstatus: "Order opgeslagen. Verzenden naar magazijnsysteem — dit kan enkele minuten duren." Niet een spinwheel zonder uitleg, en niet een eng rood foutbericht voor iets dat eigenlijk gewoon in de wachtrij staat.
• Zeg nooit "Succes" totdat het echt waar is. Als het record in de wachtrij staat, zeg "In wachtrij," niet "Verzonden."
• Geef de gebruiker (of een beheerder) een manier om de huidige status van elke in behandeling zijnde synchronisatie te zien zonder in logboeken te graven.
• Als een storing permanent is (bijv. ongeldige gegevens werden afgewezen, geen timeout), zeg dan precies wat er aan de hand is — "Afgewezen: postcode ontbreekt" is actionabel; "Sync-fout" is niet.

Moet elke storing tot een herpoging leiden?

Nee — en dit is een onderscheid dat vaak wordt gemist. Niet alle fouten zijn gelijk:

Type storing	Wat het betekent	Wat moet gebeuren
Timeout / verbinding geweigerd	Service is tijdelijk niet beschikbaar	Opnieuw proberen met backoff
429 Too Many Requests	U bent rate-limited	Opnieuw proberen, maar langer wachten
401 Unauthorized	Token verlopen of ingetrokken	Niet zomaar opnieuw proberen — vernieuw eerst het token, dan opnieuw proberen
400 Bad Request	Uw gegevens zijn ongeldig	Niet opnieuw proberen — het zal weer mislukken. Markeer ter correctie
500 Internal Server Error	Er is iets stukgegaan aan hun kant	Een paar keer opnieuw proberen, dan escaleren

Een ongeldige aanvraag zonder ophouden opnieuw proberen vult uw wachtrij alleen met lawaai en vertraagt de waarschuwing dat iemands aandacht nodig is.

Hoe voorkom je duplicaatrecords zodra de service weer actief is?

Dit is het klassieke vervolgprobleem: de API was eigenlijk 90 seconden niet beschikbaar, de herpoging was succesvol, maar een gebruiker had de order uit frustratie al handmatig opnieuw ingevoerd. Nu zijn er twee.

De oplossing is idempotentie van het begin af aan ontwerpen:

• Genereer een unieke aanvraag-ID (een UUID) aan de FileMaker-zijde voordat de eerste poging plaatsvindt, en stuur deze mee bij elke herpoging van die aanvraag.
• Configureer of controleer of het ontvangende systeem op basis van die ID kan dedupliceren — veel moderne API's ondersteunen hiervoor precies een "idempotency key"-header.
• Als het externe systeem dat niet ondersteunt, bouw een lokale controle in: "is dit ordernummer al bevestigd als verzonden?" voordat u een handmatig opnieuw verzenden toestaat.

Wat kost dit om te bouwen — en is het het waard?

Een eenvoudige retry-wachtrij met backoff en een statusdashboard is doorgaans een paar dagen ontwikkelings- werk voor een middelmatige FileMaker/ERP-integratie — klein vergeleken met de kosten van één slechte middag met duplicaatorders, gemiste zendingen of een escalatie van een klant. De echte investering is niet de code; het is van tevoren bepalen wat "storing" voor elk integratiepoint moet betekenen, in plaats van het live in productie te ontdekken.

Dit soort veerkrachtplanning wordt in meer detail behandeld in onze gids over hoe je betrouwbare integraties tussen bedrijfssystemen ontwerpt — dit artikel zoomt in op één specifiek stuk van die puzzel: het moment waarop het fout gaat.

Een snelle checklist voordat u live gaat

• Elke externe aanroep heeft een gedefinieerde timeout — niet de standaard, een opzettelijke.
• Mislukte aanroepen worden in een duurzame wachtrij opgeslagen, niet in een temporaire variabele.
• Herpogingen gebruiken backoff en een maximum aantal pogingen.
• Permanente fouten (slechte gegevens, auth) worden onderscheiden van tijdelijke fouten (timeout, 5xx).
• Elke aanvraag draagt een unieke ID om duplicaten bij herpoging te voorkomen.
• Er is een zichtbare status voor in behandeling zijnde/mislukte items — voor gebruikers en voor beheerders.
• Iemand krijgt automatisch een waarschuwing wanneer herpogingen voorbij zijn, niet alleen wanneer een klant klaagt.

FAQ

Is dit ook van toepassing op AI-integraties? Ja. Een AI-service die vanuit een FileMaker-workflow wordt aangesproken — voor verrijking, classificatie of opzoekingen via een tool als Klai — is nog steeds slechts een API-aanroep over het netwerk. Het heeft dezelfde timeout-, herpoging- en fallback-logica nodig als elke boekhoud- of verzendintegratie; het enige verschil is bepalen wat de workflow moet doen als de AI-stap wordt overgeslagen (bijv. doorgaan zonder de suggestie, in plaats van het hele proces te blokkeren).

Kan FileMaker retry-wachtrijen natively afhandelen? Ja, met behulp van een standaardtabel voor de wachtrij en FileMaker Servers planningsfunctie om periodiek een script uit te voeren. Voor webgerichte workflows die zijn gebouwd met iets als FMBetterForms, kan dezelfde wachtrij-tabel vanuit zowel de weblaag als de native client worden gecontroleerd.

Hoe lang moeten we opnieuw proberen voordat we het opgeven? Er is geen universeel getal, maar een veelgebruikt patroon is 3–5 pogingen over ruwweg 15–30 minuten voor tijdgevoelige processen (orders, betalingen) en langere vensters (uren) voor achtergrond-synctaken als het bijwerken van voorraadinformatie.

Wat als de externe service geen statuspagina of webhook heeft om ons te vertellen dat het weer werkt? Poll het. Een lichte "health check"-aanroep om de paar minuten, gescheiden van de daadwerkelijke gegevensoverdracht, kan uw wachtrij vertellen wanneer het veilig is om volledige herpogingen te hervatten in plaats van een nog herstellende eindpunt uit te putten.

Als uw systemen momenteel stil worden — of erger, fout gaan — op het moment dat één externe service happeert, is dat meestal een teken dat de integratie alleen voor het gelukkige scenario is gebouwd. Loggix helpt bij het in kaart brengen waar die faalpunten in uw FileMaker-, ERP- en API-verbindingen zitten, en bouwt de retry-logica, wachtrijen en fallback-regels — inclusief AI-aangedreven stappen — zodat een tien minuten durende storing een tien minuten durende storing blijft in plaats van een week handmatig opschonen.