Wat is middleware?

Middleware in twee zinnen

Middleware is een programma dat berichten van het ene systeem aanneemt, ze omzet naar wat het andere systeem verwacht en ze daar aflevert. Het heeft geen eigen gebruikers. Wat het bewaart zijn berichten, logs en vertaaltabellen, zoals welk e-mailadres bij welk debiteurnummer hoort.

Een order uit Shopify heeft een email, een line_items-lijst met sku en een total_price inclusief btw. Exact Online wil een debiteur-ID in OrderedBy, een artikel-ID per regel en prijzen exclusief btw. Middleware zit daartussen: het zoekt de debiteur op, vertaalt de SKU naar het artikel, rekent de btw eruit en maakt de verkooporder aan. Dat vertalen heet veldmapping, en het is meestal het grootste deel van het werk.

Waarom een tussenlaag en niet rechtstreeks?

Twee systemen koppel je prima rechtstreeks. Het verschil ontstaat bij meer systemen. Rechtstreeks heeft elk paar een eigen koppeling. Met een tussenlaag heeft elk systeem er één.

De som voor rechtstreeks is n x (n - 1) / 2: bij 5 systemen 5 x 4 / 2 is 10. Bij een webshop, ERP, WMS, marktplaats en vervoerder zijn dat 10 plekken waar een veld anders heet, een limiet geldt en iets kan misgaan. Via een tussenlaag zijn het er 5. Komt er een zesde systeem bij, dan kost dat rechtstreeks 5 nieuwe koppelingen en via de tussenlaag 1.

Het aantal koppelingen is niet eens het belangrijkste. Belangrijker is dat de regels op één plek staan. Welk systeem leidend is voor voorraad, welke buffer bol krijgt, welke locaties meetellen: rechtstreeks staat dat in 3 koppelingen die elk een eigen versie kunnen hebben. In een tussenlaag staat het één keer. Zonder die ene plek overschrijven systemen elkaars gegevens.

Rekenvoorbeeld: drie kanalen lezen dezelfde voorraad

Een groothandel heeft 6.500 artikelen in Exact Online en verkoopt via een Shopify-webshop, bol en een kassa in de winkel. Alle drie hebben elke 15 minuten de voorraad nodig.

Exact Online geeft op zijn sync-endpoints 1.000 regels per verzoek. 6.500 artikelen zijn 7 verzoeken per ronde, en een dag heeft 96 kwartieren.

• Rechtstreeks. Elk kanaal leest zelf: 3 x 96 x 7 is 2.016 verzoeken per dag. Exact Online staat 5.000 verzoeken per dag per app per administratie toe, en 60 per minuut. Lopen de drie koppelingen elk als eigen app, dan telt elke koppeling apart. Lopen ze onder één app, dan is 2.016 ruim 40% van het dagbudget, voordat er één order is verwerkt.
• Via een tussenlaag. Eén keer lezen: 96 x 7 is 672 verzoeken, 13% van de dag. De tussenlaag rekent per kanaal het juiste getal uit en schrijft alleen wat veranderd is.

Hetzelfde geldt voor de andere kant. Orders van drie kanalen komen in één wachtrij en gaan in één tempo naar het ERP, zodat de 60 verzoeken per minuut nooit door drie koppelingen tegelijk worden overschreden. Wat een limiet precies is en wat er gebeurt als je hem raakt, staat in wat is een rate limit.

Wat doet middleware precies?

Zes taken, elk met een reden die je in getallen kunt aanwijzen:

Een bericht in de wachtrij van een tussenlaag ziet er bijvoorbeeld zo uit:

{
  "id": "shopify-order-5804812345601",
  "bron": "shopify",
  "doel": "exact-online",
  "type": "verkooporder",
  "poging": 3,
  "volgende_poging": "2026-10-03T02:05:00Z",
  "laatste_fout": "429 Too Many Requests",
  "inhoud": { "name": "#10482", "total_price": "248.00" }
}

Het id maakt het bericht herkenbaar als het nog eens binnenkomt. poging en volgende_poging regelen het opnieuw proberen. Blijft het na het laatste aantal pogingen mislukken, dan gaat het met de originele inhoud naar een aparte lijst waar iemand het bekijkt. Er verdwijnt niets zonder dat iemand het ziet. Wat er bij uitval verder gebeurt, staat in wat gebeurt er als een koppeling uitvalt.

Welke soorten middleware zijn er?

Een koppelplatform rekent vaak per taak of per uitgevoerde stap, en bij tienduizenden records per maand telt dat op. Een flow die een collega met klikken heeft gebouwd is ook lastig over te dragen: de kennis zit in het platform. Een eigen tussenlaag heeft die grens niet, maar moet wel worden gehost, bewaakt en bijgehouden als een leverancier zijn API wijzigt.

Waar maakt een tussenlaag het verschil?

Vanaf drie of vier systemen verandert de som, op drie plekken:

• Drie of meer systemen lezen hetzelfde gegeven. Voorraad naar webshop, marktplaats en kassa: één keer lezen in plaats van drie keer, zoals in het rekenvoorbeeld.
• Een systeem zonder webhooks. Een ERP dat niets meldt, moet worden gevraagd. Eén plek die vraagt, is één plek die de limiet bewaakt.
• Regels die over systemen heen gaan. Een order die over twee magazijnen wordt verdeeld, of een prijs die uit het ERP komt en een buffer per kanaal krijgt, past in geen van de systemen zelf.

Wat betekent dit voor je koppeling?

Elke koppeling die wij bouwen is een tussenlaag: hij ontvangt, zet in een wachtrij, vertaalt, probeert opnieuw en legt alles vast. We schrijven hem voor jouw systemen en regels, hosten hem, bewaken hem en passen hem aan als een leverancier zijn API wijzigt. In het dashboard met logs zie je per bericht wat er binnenkwam en wat ermee gebeurde.

Hoe dat er voor jouw landschap uitziet staat op maatwerk koppeling laten maken. Hoe een webshop in stappen naar meer systemen groeit, staat in van webshop naar gekoppeld landschap. Noem de systemen die je gebruikt, dan krijg je de som voor jouw aantallen.