Een integratie die werkt, merkt niemand
Een integratie die nét niet werkt — dat merkt iedereen.
Finance ziet opeens verkeerde getallen. Een beheerder is een halve dag bezig om uit te zoeken wat er wél en niet is doorgekomen. De leverancier zegt stellig: "Wij hebben 100 regels aangeboden." In AFAS staan er 45. Welke 55 missen er? Dat weet op dat moment niemand.
Geen verzonnen voorbeeld. Zo gaat het als een nacalculatie-koppeling onderuit gaat en niemand vooraf de juiste vragen heeft gesteld.
Het nacalculatie-probleem
Het nacalculatie-endpoint in AFAS accepteert bulkberichten. Je kunt honderden regels in één bericht insturen: uren, kosten, declaraties, alles wat een vervolgactie nodig heeft. Handig. Maar AFAS verwerkt die regels één voor één.
Als er ergens een ID niet klopt — een verkeerde kostensoort bijvoorbeeld, of een medewerker die niet bestaat — registreert AFAS een fout en gaat door met de volgende regel. Tot tien fouten. Op dat punt stopt de verwerking. Zonder dat je terugkrijgt welke regels het wél hebben gehaald.
Dan zit je met de vraag wat er nu eigenlijk in AFAS staat. De hele batch opnieuw aanbieden? Grote kans op dubbelingen. Alleen het foute deel? Dan moet je éérst weten welk deel dat is, en die informatie heb je niet.
AFAS heeft op dit endpoint geen ingebouwde idempotentie. Er zijn manieren om dat zelf te regelen — bijvoorbeeld unieke sleutels die je aan beide kanten valideert, of regels per bericht insturen in plaats van per batch, of multi-threaded werken als snelheid een rol speelt. Welke aanpak het beste past, hangt af van vragen die je vóór de bouw stelt. Niet als de fouten al binnenrollen.
De eerste vraag die telt
Voordat we iets anders bespreken bij een integratievraagstuk, stellen we één vraag: om hoeveel data gaat het en hoe komt die binnen?
Gaat het om een paar honderd regels per nacht, of duizenden per uur? Komt het in pieken binnen of gelijkmatig? En kan de ontvangende kant dat tempo eigenlijk aan?
Klinkt technisch, maar het is een procesvraag. Het antwoord bepaalt hoe je de architectuur opzet, waar je vangnetten legt, en welk risico je bewust accepteert. Wie dat gesprek overslaat, bouwt iets voor een proces dat hij eigenlijk nog niet goed kent.
Wat partners en klanten structureel missen
Christian heeft tussen 2018 en 2024 bij AFAS partnerintegraties getoetst en gecertificeerd. Die ervaring nemen we mee in hoe we bij Covio naar integratievraagstukken kijken. Wat hij bij vrijwel iedereen terugzag, ook bij ervaren partijen: de aandacht ging naar de koppeling, niet naar hoe iemand daar later mee zou moeten werken.
De data gaat over, de techniek klopt. En toch is een controller dan twee dagen na livegang aan het puzzelen omdat een veld dat hij nodig heeft consequent leeg is. Of moet de gebruiker een handeling doen die niemand had voorzien. De koppeling werkt. Het werk eromheen werkt niet.
Het datamodel van AFAS is diep. Hoe een medewerker in dienst treedt, hoe een sollicitatieproces door de organisatie loopt, wat er allemaal aan één nacalculatieregel hangt — dat staat niet in de API-documentatie. Die kennis heb je, of je hebt hem niet. En zonder die kennis benut je standaardfunctionaliteit niet, simpelweg omdat je niet weet dat hij er is.
Goede integraties falen netjes
Dat klinkt gek, maar het is het onderscheid tussen een systeem dat je kunt vertrouwen en een systeem dat je verrast.
Een situatie die wij hebben meegemaakt: een service was een paar uur uit de lucht. Een record dat aangemaakt had moeten worden, kwam er nooit. Niemand zag het. Pas weken later vroeg iemand waar een bepaald dossier was — en daar begon het uitzoekwerk.
Het vangnet daarvoor hoeft niet ingewikkeld te zijn. Soms is een mail naar de juiste persoon al genoeg, soms regel je een backupstroom. De échte vraag is wie die melding krijgt, of die persoon er binnen acceptabele tijd op reageert, en of dat ook nog werkt als hij op vakantie is. Dat gesprek voer je vóór livegang. Niet op het moment dat het al misgaat.
Risicoprofiel: niet elke koppeling is gelijk
Een nachtelijke synchronisatie van personeelsmutaties heeft een ander risicoprofiel dan een realtime koppeling onder een primair operationeel proces. Je kunt alles dichttimmeren tot op een niveau dat normaal alleen banken doen. Voor het ene scenario is dat disproportioneel, voor het andere is het precies genoeg.
Klanten weten zelf meestal vrij goed of een koppeling een primair proces raakt. Lastiger is de vraag wat er gebeurt als zo'n koppeling een uur ligt. Wie staat er dan op? Kan de organisatie dat zelf oppakken, of belt iedereen meteen naar een externe partij? Dat laatste is op zichzelf al een risico.
Security is geen bijzaak
Elke integratie is een aanvalsvector. Een verkeerd geconfigureerd endpoint. Een token met veel te brede rechten. Een service account waar al drie jaar niemand de sleutel van heeft geroteerd. Die risico's zijn niet hypothetisch, en ze zijn vaak pas zichtbaar als het al te laat is.
Als er iets gebeurt, wil je weten hoe ver het reikt. Welke systemen zijn geraakt, welke data ligt op straat, en hoe snel kun je iets afsluiten? Vanuit onze achtergrond in security — Christian heeft als Security Engineer bij het AFAS Online team van AFAS Software gewerkt — zitten dat soort vragen bij ons vooraan in het ontwerp. Niet achteraf als compliance-vinkje.
Meer integratie is niet altijd beter
Dat is misschien wel de belangrijkste les uit tien jaar integraties. Automatisering is de moeite waard als je daarmee een echt repetitief proces sneller of betrouwbaarder maakt, en de organisatie er meer grip op krijgt in plaats van minder. Wie integreert omdat het kán, bouwt vooral onderhoudslast — vaak zonder dat iemand er beter van wordt.
De integratie is het middel. Het proces eronder is het doel. Klinkt voor de hand liggend, en in de praktijk staat het toch geregeld andersom op de tekening.
Wij werken met een beperkt aantal trajecten tegelijk — als senior consultant of adviseur op projectbasis. Voor organisaties die AFAS-integraties bouwen of verbeteren, en daarin de keuzes willen maken die later niet terugslaan.
Twintig minuten kijken of dat iets voor jullie is?