Van FTP naar API: hoe je een legacy datakoppeling moderniseert
Bijna elk productiebedrijf heeft ze: koppelingen die ooit “tijdelijk” waren en nooit vervangen zijn. Een nachtelijke batch-job exporteert CSV, stuurt het via FTP naar een logistieke partner, die het handmatig importeert in zijn eigen systeem. Het draait al jaren. Niemand durft eraan te komen.
Tot het breekt.
Het concrete probleem
Bij een klant in de voedingsindustrie draaide precies zo’n koppeling. Elke nacht exporteerde het ERP orderdata als CSV, zette die via FTP op een gedeelde server, waarna de logistieke partner het bestand de volgende ochtend handmatig inlas. De koppeling was ooit in een middag gebouwd als overbrugging. Dat was acht jaar geleden.
Na de migratie naar Business Central 365 in de cloud was directe database-export niet meer mogelijk. De oude koppeling - gebouwd op de aanname dat je rechtstreeks bij de database kon - moest opnieuw worden opgezet. De vraag was: bouwen we hetzelfde opnieuw, of pakken we het fundamenteel anders aan?
Waarom batch-koppelingen gevaarlijk zijn
Het probleem met nachtelijke batch-integraties is niet dat ze langzaam zijn. Het probleem is dat ze onzekerheid verbergen.
Een FTP-koppeling kent drie foutmodi die je pas ontdekt als het te laat is:
- Stille fouten. Het bestand is gegenereerd maar bevat incomplete data. Er is geen validatie, geen schema-check, geen bevestiging. De partner importeert wat hij krijgt.
- Geen feedback-loop. Als de upload faalt, merkt niemand het tot de volgende werkdag. Er is geen retry, geen alert, geen audit trail.
- Versie-drift. Het bronbestand verandert structureel (een kolom erbij, een datumformaat anders), maar de ontvangende kant parseert het oude formaat. Geen error - alleen verkeerde data.
In de praktijk betekent dit: als er dinsdag iets misgaat, ontdek je het woensdag. Als je pech hebt, vrijdag. En als het stilletjes verkeerde data levert, misschien nooit.
De API-first aanpak
In plaats van de FTP-koppeling opnieuw te bouwen, hebben we een event-driven architectuur opgezet in drie stappen.
Stap 1: OData als dataleverancier
BC365 biedt standaard een OData-laag voor het ontsluiten van bedrijfsdata. In plaats van nachtelijk CSV te genereren, stellen we de relevante entiteiten beschikbaar als API-endpoints. Data wordt niet meer geduwd op een tijdstip - het wordt opgehaald wanneer de afnemer het nodig heeft.
Stap 2: Azure API Management als poortwachter
Tussen BC365 en de partner plaatsten we Azure API Management (APIM). Dit levert in één keer wat de FTP-koppeling volledig miste:
- Authenticatie via OAuth2/JWT - geen gedeelde wachtwoorden meer
- Rate limiting - bescherming tegen overbelasting
- Request logging - elke aanroep wordt geregistreerd met timestamp, payload en response
- Versiebeheer - nieuwe velden toevoegen zonder de bestaande integratie te breken
Stap 3: Webhooks voor event-driven notificatie
De logistieke partner hoeft niet meer te pollen. Bij een nieuwe order of statuswijziging stuurt het systeem een webhook-notificatie. De partner ontvangt een event, haalt de actuele data op via de API, en verwerkt het - binnen seconden in plaats van binnen een etmaal.
Wat dit oplevert
| Aspect | FTP-batch | API-integratie |
|---|---|---|
| Dataversheid | 24 uur oud | Realtime |
| Foutdetectie | Volgende werkdag | Binnen seconden |
| Authenticatie | Gedeeld FTP-wachtwoord | OAuth2/JWT per partner |
| Audit trail | Geen | Elke transactie gelogd |
| Versiebeheer | Niet aanwezig | Ingebouwd via APIM |
Maar het belangrijkste verschil is niet technisch. Het is operationeel. Fouten worden direct zichtbaar. Er is geen nachtelijk venster meer waarin data stilletjes verloren kan gaan. En als er iets faalt, weet je precies wat, wanneer en waarom.
De les
Legacy-koppelingen vervangen hoeft geen big-bang te zijn. De FTP-koppeling bleef draaien als fallback terwijl we de API-route opbouwden. Pas toen de partner bevestigde dat de nieuwe integratie stabiel was, schakelden we de oude koppeling uit.
Dat is het verschil tussen moderniseren en opnieuw bouwen. Je vervangt niet alles tegelijk - je legt een betere route naast de bestaande, valideert, en schakelt dan om.
De koppelingen die het langst meedraaien zijn vaak de koppelingen waar niemand verantwoordelijkheid voor voelt. Dat maakt ze niet onbelangrijk. Het maakt ze gevaarlijk.