Waarom automatiseringen stilvallen

Een koppeling die stopt, stopt zelden op het moment dat iemand ernaar kijkt. Hij stopt op een dinsdagnacht en het valt donderdag op, als de facturen van twee dagen ontbreken. Wat volgt is een typisch geval; de oorzaken komen uit de documentatie van de leveranciers zelf.

Het verlopen token

De koppeling logt niet in met een wachtwoord, maar met een token dat ooit door iemand is goedgekeurd. Dat token heeft een houdbaarheid. Bij Microsoft is de looptijd van een refresh token voor de meeste toepassingen 90 dagen, en hij kan eerder worden ingetrokken, onder meer als een beheerder het wachtwoord van de gebruiker via het beheercentrum reset. Bij Google vervalt een refresh token als het zes maanden niet is gebruikt, en al na zeven dagen zolang een externe app nog op de status "Testing" staat. Bij AFAS kan een token een geldigheidsduur meekrijgen en wordt het na afloop daarvan verwijderd; app connectoren die zes maanden niet zijn gebruikt, worden geblokkeerd.

Wat de lezer ziet: een 401 of een invalid_grant in het log, of helemaal niets, omdat de koppeling na de eerste fout gewoon opnieuw probeert. Het token stond op het account van de medewerker die de koppeling destijds inrichtte. Die is inmiddels van wachtwoord veranderd, of van werkgever.

De gewijzigde export

De koppeling leest elke nacht een bestand dat het pakket exporteert. Iemand heeft in dat pakket een kolom toegevoegd, of een veld hernoemd van "Klantnr" naar "Debiteurnummer", omdat dat netter is. Het bestand komt nog steeds aan; het is alleen niet meer het bestand waar de koppeling op rekent.

Dit is de storing die het langst onopgemerkt blijft, omdat er vaak niets faalt: geen foutmelding, maar een tabel met een lege kolom. AFAS zet dit in de eigen controlelijst voor connectoren die niet meer werken: bij "geen of minder gegevens dan verwacht" kijkt de beheerder eerst naar de definitie van de GetConnector en de filterautorisatie, pas daarna naar de techniek.

De update van het pakket

Leveranciers veranderen hun koppelvlak, en kondigen dat aan waar de eigenaar van de koppeling niet kijkt. AFAS geeft de bestaande "Classic tokens" in september 2026 een einddatum van 15 februari 2027. Vanaf die dag werkt elke koppeling die nog op zo'n bestaand token draait niet meer. De aankondiging staat in het Help Center, niet in de mailbox van de eigenaar van de koppeling. Die ziet een koppeling die vrijdag nog liep en maandag niet meer, zonder dat er aan de eigen kant iets is veranderd.

De volle schijf

De koppeling schrijft een logregel per verwerking en bewaart van elk bestand een kopie. Verstandig, en na tweeëneenhalf jaar is de schijf vol. De koppeling kan dan het log niet meer schrijven. Wat er daarna gebeurt, hangt af van hoe hij is gebouwd: stoppen, doorgaan zonder log, of half werk afleveren. In alle drie de gevallen kan de melding waarom nergens heen.

Dit is de enige van de vijf die volledig aan de eigen kant ligt. Er is alleen nooit afgesproken hoe lang het log bewaard blijft.

De collega die de mailbox hernoemde

De koppeling leest bestellingen uit een map "Orders" in een gedeelde mailbox. Een collega ruimt op en hernoemt de map naar "Orders 2026", met een nieuwe map "Orders" ernaast, leeg. De koppeling kijkt de volgende ochtend in de lege map en meldt keurig: nul nieuwe orders.

Of dit misgaat, hangt af van hoe de koppeling de map heeft onthouden. Microsoft documenteert voor Graph dat de standaardmappen een well-known name hebben die ongeacht taal of weergavenaam werkt, zoals inbox en sentitems. Een zelfgemaakte map als "Orders" heeft die niet; die is alleen te vinden op weergavenaam of op een intern id. Een koppeling die op naam zoekt, valt om bij hernoemen; een koppeling die het id heeft opgeslagen, blijft de map volgen. Welke van de twee het is, staat niet op de factuur van de bouwer.

Wat de vijf gemeen hebben

Geen van de vijf begint als een fout in de koppeling. De koppeling deed wat hij op de bouwdag moest doen, in een omgeving die intussen was veranderd: een token dat verliep zoals gedocumenteerd, een pakket dat deed wat de release notes zeiden, een map die een collega mocht hernoemen.

Wat steeds ontbrak, is de aansluiting met de mensen eromheen. Niemand wist op wiens account het token stond, wie de release notes las, of dat de map "Orders" ergens in code voorkwam. Een koppeling zit met beide handen in systemen van anderen, en die anderen weten dat niet.

Wat daartegen helpt, is een onderhoudskaart van vier regels per koppeling, naast de code. Op wiens account de tokens staan en wanneer ze verlopen. Welke bestanden, mappen en veldnamen de koppeling letterlijk verwacht. Bij welke leverancier de aankondigingen staan en wie die leest. Hoe lang het log wordt bewaard en waar de koppeling het melden gaat als hij stopt. Die kaart is een halve pagina, en het is het deel van de overdrachtsmap dat het makkelijkst wordt overgeslagen. Wat een bouwer daarnaast hoort op te leveren, staat op de pagina over techniek en eigendom.

De kaart voorkomt de storing niet en ontdekt hem ook niet. Het token verloopt toch, de collega hernoemt de map toch, en zolang niemand dagelijks kijkt of de koppeling werkelijk heeft gedraaid, blijft het tot donderdag stil. Het verschil zit in die donderdag: of het uitzoeken een kwartier duurt of een dag, en of de eerste vraag is "wat is er gebeurd" of "waar staat de code eigenlijk".