Van legacy koppelingen naar een API-first integratieplatform

Situatie

Een productiebedrijf in de maakindustrie met vijf kernystemen die onderling data uitwisselen: een ERP-systeem (Business Central 365), een productieautomatiseringssysteem (MES), een planningssysteem, koppelingen met logistieke partners, en BI-tooling voor rapportages.

Historisch waren deze systemen punt-naar-punt gekoppeld. Het MES-systeem haalde orderdata rechtstreeks uit het ERP. Het planningssysteem synchroniseerde via een eigen koppeling. Logistieke partners ontvingen dagelijks een CSV-export via FTP. De BI-tooling trok data uit drie bronnen met drie verschillende authenticatiemechanismen.

Elke koppeling was ooit individueel gebouwd - vaak als “tijdelijke oplossing” - en functioneerde op zijn eigen manier: eigen credentials, eigen foutafhandeling, eigen retry-logica. Het totaalplaatje was een klassiek integratiespaghetti: bij vijf systemen geen vijf koppelingen, maar twintig mogelijke verbindingslijnen waarvan er twaalf actief waren.

Het functioneerde. Tot het niet meer functioneerde.

Uitdaging

Na de migratie van een on-premise ERP naar Business Central 365 in de cloud vielen meerdere koppelingen uit. Directe database-queries waren niet meer mogelijk. FTP-routes naar het oude datacenter waren afgesloten. En het nieuwe ERP vereiste OAuth2-authenticatie - iets waar het MES-systeem en de logistieke partners niets mee konden.

De vraag was niet hoe je twaalf kapotte koppelingen repareert. De vraag was of je dat uberhaupt moet willen.

De kernproblemen die op tafel lagen:

• Geen centraal overzicht. Niemand kon vertellen welke systemen welke data uitwisselden, hoe vaak, en of dat succesvol was. Foutdiagnose betekende inloggen op vijf systemen en vijf logbestanden doorzoeken.
• Geen uniforme authenticatie. Het MES-systeem werkte met API-keys. Logistieke partners hadden FTP-credentials. De BI-tooling gebruikte service accounts. BC365 vereiste OAuth2. Elk systeem had zijn eigen beveiligingsmodel.
• Geen realtime data. De meeste koppelingen draaiden als nachtelijke batch. Orderdata was standaard T+1: wat vandaag werd ingevoerd, was morgen beschikbaar voor planning en logistiek.
• Geen schaalbaarheid. Elke nieuwe partner of elk nieuw systeem betekende een nieuw integratietraject van weken. Er was geen standaard, geen herbruikbaarheid, geen onboarding-proces.

Aanpak

We hebben de integratielaag fundamenteel herontworpen. Geen reparatie van bestaande koppelingen, maar een architectuurwijziging: van punt-naar-punt naar hub-and-spoke, met Azure API Management (APIM) als centraal platform.

APIM als integratiehub

Alle systemen communiceren via APIM in plaats van rechtstreeks met elkaar. Het MES-systeem stuurt requests naar APIM. Het planningssysteem haalt data op via APIM. Logistieke partners roepen API-endpoints aan op APIM. De BI-tooling consumeert data via APIM.

APIM routeert, authenticeert, logt en transformeert. De backend-systemen - BC365, het MES, externe diensten - zijn afgeschermd achter de gateway. Consumerende partijen zien een uniforme API-laag.

Het resultaat: in plaats van n-keer-n mogelijke verbindingslijnen heeft elk systeem precies een verbinding - met APIM.

OAuth2-vertaallaag

Het concreetste technische probleem was authenticatie. Het MES-systeem ondersteunt uitsluitend API-key-authenticatie. BC365 vereist OAuth2 met Azure AD-tokens. Zonder tussenlaag zijn deze twee systemen incompatibel.

In APIM hebben we dit opgelost met een inbound policy:

1. Het MES-systeem stuurt een request met een API-key in de header
2. APIM valideert de key tegen een subscription
3. APIM doet een send-request naar Azure AD om een Bearer token op te halen
4. Het token wordt gecachet (zodat niet elke call een nieuwe token-aanvraag triggert)
5. APIM zet het Bearer token als Authorization-header op het doorgestuurde request naar BC365

Het MES-systeem hoeft niets te weten over OAuth2. Geen token-refresh, geen client secrets, geen token-cache. Die complexiteit zit volledig in de APIM-configuratie - geen custom code, geen aparte middleware, geen extra compute.

Van FTP-batch naar OData-APIs

BC365 biedt standaard OData-endpoints voor het ontsluiten van bedrijfsdata. In plaats van nachtelijk CSV-bestanden te genereren en via FTP te versturen, hebben we de relevante entiteiten - orders, voorraad, productieopdrachten - beschikbaar gesteld als API-endpoints via APIM.

Data wordt niet meer eenmaal per etmaal geduwd. Het wordt opgehaald wanneer de afnemer het nodig heeft, met de actuele stand.

Webhook-driven events

Voor tijdkritische processen hebben we polling en batch vervangen door webhooks. Wanneer een order wordt aangemaakt in BC365, stuurt het systeem een event-notificatie naar APIM, dat deze doorrouteert naar de relevante afnemers: het productiesysteem en de logistieke partner.

Het productiesysteem ontvangt een webhook, haalt de orderdetails op via de API, en start de productieplanning - binnen seconden na ordercreatie. Niet de volgende ochtend.

Centraal monitoren

Met Application Insights als logging-backend wordt elke API-call automatisch vastgelegd: latency, HTTP-statuscode, consumer-identiteit, payload-grootte, faalpatronen.

Probleemdiagnose gaat van “inloggen op vijf systemen en vijf logfiles doorzoeken” naar “zoek in een dashboard.” Wie riep wat aan, wanneer, met welk resultaat - alles in een audit trail.

Gecontroleerde toegang voor partners

Externe logistieke partners krijgen een eigen API-subscription in APIM met rate limits, toegestane endpoints en API-versiebeheer. Onboarding van een nieuwe partner is geen ontwikkeltraject meer - het is een configuratiewijziging.

Resultaat

De transformatie leverde meetbare verbeteringen op alle niveaus:

Aspect	Voor	Na
Architectuur	Punt-naar-punt (n x n)	Hub-and-spoke via APIM (n)
Dataversheid	T+1 (nachtelijke batch)	Realtime via API en webhooks
Foutdetectie	Volgende werkdag	Binnen seconden
Audit trail	Verspreid over vijf systemen	Centraal in Application Insights
Onboarding nieuw systeem	Weken	Dagen
Partnertoegang	FTP-credentials per partner	Self-service API met rate limits

Maar het belangrijkste resultaat is architectureel. Het bedrijf heeft nu een integratielaag die als platform functioneert. Nieuwe systemen worden aangesloten op APIM, niet rechtstreeks op vijf andere systemen. Authenticatie, logging, rate limiting en versiebeheer zijn standaard - niet iets dat per koppeling opnieuw wordt bedacht.

De twaalf punt-naar-punt koppelingen zijn vervangen door vijf APIM-verbindingen. Dat is geen vereenvoudiging. Dat is een andere manier van denken over hoe systemen met elkaar communiceren.