Azure API Management als integratiehub: één gateway, meerdere systemen

Een productiebedrijf met vijf systemen die onderling data uitwisselen. Het MES-systeem praat met Business Central. Het planningsysteem haalt orders op uit BC365. De BI-tooling trekt data uit drie bronnen. Externe partners leveren voorraadgegevens aan via een API.

Elk van die koppelingen heeft een eigen authenticatiemechanisme, een eigen URL-structuur, eigen foutafhandeling en eigen retry-logica. Dat zijn geen vijf integraties - dat zijn vijf punten waar het mis kan gaan, vijf plekken waar je credentials beheert, vijf plekken waar je geen zicht hebt op wat er langskomt.

Dit is het klassieke point-to-point probleem. En het schaalt niet.

Van spaghetti naar hub-and-spoke

De oplossing is geen betere koppeling. De oplossing is een architectuurwijziging: zet Azure API Management (APIM) centraal als integratiehub.

In een hub-and-spoke model praten consumerende systemen niet meer rechtstreeks met backend-systemen. Ze praten met APIM. APIM vertaalt, authenticeert, logt en routeert. De consuming-kant ziet één uniforme API. De backend-kant blijft ongewijzigd.

Concreet:

• Het MES-systeem stuurt een request naar APIM met een API-key
• APIM valideert de key, wisselt deze in voor een OAuth2 Bearer token bij BC365, en forward het request
• BC365 ontvangt een standaard OAuth2-request en antwoordt
• APIM ontvangt het antwoord, logt het, en stuurt het terug naar het MES-systeem

Het MES-systeem hoeft niets te weten over OAuth2. Het hoeft geen token-refresh te implementeren, geen client secrets te beheren, geen token-cache bij te houden. Dat doet APIM.

Het OAuth-vertaalprobleem

Dit is geen theoretisch voorbeeld. We zien dit patroon regelmatig bij productiebedrijven.

Een productieautomatiseringssysteem ondersteunt uitsluitend API-key-authenticatie. Simpel, robuust, maar niet compatibel met BC365’s OAuth2-flow. Zonder tussenlaag heb je twee opties: het bronsysteem aanpassen (duur, risicovol) of een custom middleware bouwen (onderhoudslast).

Met APIM configureer je dit in een policy - een XML-configuratieblok dat op de inbound-request wordt toegepast:

1. Valideer de API-key van het bronsysteem
2. Gebruik een send-request policy om een Bearer token op te halen bij Azure AD
3. Cache het token (zodat je niet bij elke call een nieuw token aanvraagt)
4. Zet het token als Authorization-header op het doorgestuurde request

Dit is geen code die je deployt. Het is configuratie die je beheert in de Azure Portal of via Infrastructure as Code. Geen aparte service, geen extra compute, geen deployment pipeline.

Wat je configureert

Per API in APIM configureer je:

• Backend URL - waarheen het request wordt doorgestuurd (bijv. https://api.businesscentral.dynamics.com/v2.0/...)
• Authenticatiemethode - OAuth2, API-key, certificaat, managed identity
• Rate limits per consumer - het planningsysteem mag 100 calls per minuut, de externe partner 20
• Toegestane HTTP-methoden - de BI-tooling mag alleen GET, het MES-systeem mag GET en POST
• Policies - transformatielogica, header-manipulatie, caching, retry-configuratie
• Logging - elke call wordt weggeschreven naar Application Insights

Policies zijn de kracht van APIM. Ze werken als een pipeline: inbound (voor het request naar de backend gaat), backend (het daadwerkelijke request), outbound (voordat het antwoord terug gaat) en on-error. In elke fase kun je headers toevoegen, payloads transformeren, conditionele logica toepassen of requests blokkeren.

Monitoring als bijproduct

Dit is het ondergewaardeerde voordeel van een centrale gateway: als al het verkeer via één punt loopt, heb je automatisch een compleet audittrail.

Met Application Insights als logging-backend zie je per API-call:

• Latency - hoe lang duurde de volledige roundtrip
• HTTP-statuscode - successen, client errors, server errors
• Consumer-identiteit - welk systeem of welke partner deed het request
• Payload-grootte - hoeveel data er heen en terug ging
• Faalpatronen - welke backend faalt het vaakst, op welke tijdstippen

Je hoeft dit niet apart te bouwen. Het is een bijproduct van de architectuurkeuze. Zodra je APIM inricht, heb je monitoring.

In de praktijk betekent dit dat je vragen kunt beantwoorden die voorheen onmogelijk waren: “Hoeveel calls doet het planningsysteem per dag naar BC365?” of “Wat is de gemiddelde response time van het MES-endpoint?” of “Welke partner overschrijdt structureel zijn rate limit?”

Wanneer APIM overkill is

APIM is niet voor elke situatie geschikt. Als je twee systemen hebt met een stabiele, point-to-point koppeling die al jaren draait - laat het met rust. De overhead van een gateway rechtvaardigt zich pas bij drie of meer integraties, of bij koppelingen waar authenticatie, logging of rate limiting een vereiste is.

Maar zodra je merkt dat je dezelfde OAuth-logica voor de derde keer implementeert, of dat je geen zicht hebt op welk systeem welke API hoe vaak aanroept - dan heb je geen API-probleem. Dan heb je een architectuurprobleem. En APIM is het antwoord.