Laravel + Alumio: iPaaS als orchestratielaag

Laravel + Alumio: iPaaS als orchestratielaag

90% van de integratieproblemen die wij bij klanten zien, ontstaat doordat businesslogica en connectiviteit in dezelfde codebase zitten. Eén systeem dat alles doet: data ophalen, transformeren, valideren, berekenen, wegschrijven. Het werkt tot het moment dat er een vijfde koppeling bijkomt.

Dan wordt elke wijziging een risico voor het hele systeem.

De oplossing is geen grotere Laravel-applicatie. Het is een scherpere taakverdeling. Laravel doet wat Laravel goed kan: complexe, bedrijfsspecifieke logica. Alumio doet wat een iPaaS goed kan: connectiviteit en transformatie tussen systemen. Dit artikel laat zien hoe die scheiding er in de praktijk uitziet.

Het probleem met alles-in-Laravel

Laravel is uitstekend voor maatwerk. Wij bouwen er complexe pricing-engines, order-orchestratie en domeinlogica in die nergens kant-en-klaar te koop is.

Maar Laravel als integratiehub heeft een prijs:

• Elke koppeling is code. Een nieuwe leverancier-API betekent een nieuwe client, nieuwe mappings, nieuwe error-handling. Allemaal handmatig.
• Retries en monitoring bouw je zelf. Queues, failed jobs, dead-letter-afhandeling, alerting. Werkende infrastructuur, maar het kost weken.
• Wijzigingen raken alles. Een veld dat van naam verandert in een externe API forceert een deploy van je hele applicatie.
• Niemand ziet wat er gebeurt. Zonder dashboard is een mislukte sync een zoekplaatje in de logs.

Bij twee koppelingen valt dit mee. Bij acht koppelingen, elk met eigen authenticatie, rate limits en datastructuren, wordt je Laravel-app een integratiemonoliet. Dat is precies wat je niet wilt.

De taakverdeling: wie doet wat

Het architectuurpatroon is simpel. Trek een grens tussen logica en transport.

Concreet voorbeeld. Een order komt binnen in Magento. De vraag "welke korting geldt voor deze B2B-klant met dit contract en dit volume?" is businesslogica. Die hoort in Laravel. De vraag "hoe stuur ik dit order naar het WMS dat alleen platte XML accepteert?" is transport. Die hoort in Alumio.

Architectuurpatroon in de praktijk

Zo ziet een typische flow eruit bij een klant met Magento, een ERP en een WMS.

Magento ──▶ Alumio ──▶ Laravel ──▶ Alumio ──┬──▶ ERP
         (normaliseer) (logica)  (transform) ├──▶ WMS
                                              └──▶ PIM

De winst zit in de scheiding. Wil je een vierde bestemming toevoegen? Dat is een connector in Alumio, geen deploy van je Laravel-app. Verandert de ERP-API? Je past één mapping aan, niet je domeinlogica.

Wij bouwen deze Laravel-laag als een schone API zonder kennis van de externe systemen. Het domein weet niets van XML, niets van SOAP, niets van rate limits. Dat houdt de code testbaar en begrijpelijk. Meer over onze aanpak op /laravel.

Het Laravel-endpoint in detail

De kern van dit patroon is het contract tussen Alumio en Laravel. Dat contract is een eigen, intern dataformaat. Niet het Magento-formaat, niet het ERP-formaat, maar een formaat dat jouw domein logisch vindt.

Een binnenkomend order ziet er dan zo uit:

// POST /api/orders/process
{
  "external_id": "MAG-10042",
  "customer_id": 88,
  "lines": [
    { "sku": "WIDGET-A", "qty": 12 },
    { "sku": "WIDGET-B", "qty": 3 }
  ]
}

Geen kortingen, geen prijzen, geen leveringsstrategie. Die berekent Laravel zelf. Alumio levert alleen de feiten aan. Wat Laravel teruggeeft is het verrijkte resultaat: prijzen per regel, toegepaste contractkorting, voorraadreservering en de splitsing in deelleveringen.

Dit contract is bewust dun gehouden. Hoe minder de buitenwereld over je domein hoeft te weten, hoe minder vaak je het hoeft te wijzigen. Wij versioneren dit endpoint expliciet, zodat een nieuwe Alumio-flow nooit een bestaande breekt.

De controllers zijn dun. Ze valideren de input, roepen een service of action aan en geven het resultaat terug. Alle logica zit in de domeinlaag eronder, los van HTTP en los van Alumio. Daardoor kun je de volledige orderverwerking testen zonder ook maar één externe call.

Wanneer Laravel, wanneer Alumio

De grens is niet altijd scherp. Een paar vuistregels die wij hanteren.

• De logica bedrijfsspecifiek is en nergens te koop.
• Je rekent, valideert of beslissingen neemt op basis van meerdere bronnen.
• Je een eigen datamodel nodig hebt met relaties en integriteit.
• De flow stateful is en transacties moet garanderen.

• Je systeem A met systeem B verbindt zonder ingewikkelde tussenliggende logica.
• Je data van het ene formaat naar het andere mapt.
• Je standaard-koppelingen nodig hebt die snel moeten staan.
• Je monitoring, retries en throttling out-of-the-box wilt.

Veelgemaakte fouten in deze architectuur

Wat wij in de praktijk fout zien gaan:

• Businesslogica in Alumio-transformers stoppen. Verleidelijk, want het kan. Maar transformers met if-then-else-bomen zijn onmogelijk te testen en niemand vindt ze terug. Logica hoort in Laravel.
• Laravel laten praten met externe systemen. Zodra je domein een SOAP-client importeert, lekt transport in je logica. Houd het domein schoon.
• Geen idempotentie. Alumio kan een bericht opnieuw aanbieden na een timeout. Als je Laravel-endpoint hetzelfde order dan dubbel verwerkt, heb je dubbele leveringen. Bouw idempotentie op een unieke key.
• Synchroon koppelen waar async hoort. Een trage ERP mag je orderflow niet blokkeren. Gebruik queues in Laravel en async flows in Alumio.

Deze fouten kosten geen uren maar dagen aan productie-incidenten. Ze zijn allemaal te voorkomen door de grens tussen logica en transport te bewaken.

Foutafhandeling: waar hoort wat

Een vraag die altijd terugkomt: als een sync mislukt, wie lost dat op? Het antwoord hangt af van het soort fout.

Het verschil is belangrijk. Een transportfout retry je. Een logicafout retry je nooit. Wie deze twee door elkaar haalt, krijgt een systeem dat eindeloos dezelfde foute order opnieuw aanbiedt. Door de fouttypes te scheiden, weet je altijd waar je moet kijken: Alumio-dashboard voor transport, Laravel-logs voor logica.

Wat dit oplevert in cijfers

Bij een B2B-groothandel met Magento, een verouderd ERP en drie leveranciers-feeds zagen wij na het invoeren van dit patroon:

• Nieuwe koppeling van 3 weken naar 3 dagen. Connectoren in Alumio in plaats van maatwerk-clients in Laravel.
• Deploys van Laravel met 60% gedaald. Koppelingswijzigingen raakten de applicatie niet meer.
• Mislukte syncs binnen minuten zichtbaar via het Alumio-dashboard, in plaats van pas bij klachten van de klant.
• Testdekking van de domeinlaag naar boven de 80%, omdat de logica geïsoleerd en zonder externe afhankelijkheden testbaar werd.

De grootste winst is niet technisch maar organisatorisch. Het team dat de businesslogica beheert, hoeft niet meer te weten hoe het WMS zijn XML wil. Die kennis zit in de Alumio-configuratie.

Hoe wij dit aanpakken

Wij beginnen nooit met het bouwen van connectoren. Wij beginnen met de grens.

Eerst brengen we in kaart welke beslissingen je systeem neemt en welke data daarvoor nodig is. Dat is je domein, dat wordt Laravel. Vervolgens inventariseren we de systemen die data leveren en afnemen. Dat is je connectiviteit, dat wordt Alumio.

Pas daarna bouwen we. De Laravel-API eerst, met de logica volledig getest tegen mock-input. Dan de Alumio-flows die echte systemen aansluiten op die API. Zo blijft het domein stabiel terwijl de koppelingen groeien.

Wij werken hierin samen met Sinsou als het om de Alumio-implementatie gaat, terwijl wij de Laravel-maatwerklaag voor onze rekening nemen. Twee specialismen, één architectuur.

Twijfel je of jouw integratielandschap deze scheiding nodig heeft? Neem contact op en we kijken samen naar je huidige koppelingen. We zeggen het ook eerlijk wanneer een iPaaS overkill is voor jouw situatie.

Veelgestelde vragen

Heb ik Alumio nodig als ik al Laravel gebruik?

Niet automatisch. Bij twee tot drie stabiele koppelingen is maatwerk in Laravel vaak goedkoper en simpeler. Alumio wordt interessant zodra het aantal koppelingen groeit, de externe systemen vaak veranderen, of je monitoring en retries niet zelf wilt bouwen. De afweging hangt af van het aantal en de wisselvalligheid van je integraties.

Waar plaats ik mijn businesslogica precies?

In Laravel, altijd. Alle berekeningen, validaties en beslissingen horen in je domeinlaag. Alumio transformeert en transporteert data, maar neemt geen bedrijfsbeslissingen. Zodra je if-then-else-logica in een Alumio-transformer ziet ontstaan, is dat een teken dat de logica naar Laravel moet.

Hoe voorkom ik dubbele verwerking tussen Alumio en Laravel?

Met idempotentie. Geef elk bericht een unieke key en laat je Laravel-endpoint controleren of die key al verwerkt is. Alumio kan na een timeout een bericht opnieuw aanbieden. Zonder idempotentie leidt dat tot dubbele orders of leveringen. Dit is een verplichte stap, geen optie.

Kan Alumio de orchestratie niet helemaal overnemen?

Voor eenvoudige flows wel. Maar complexe, stateful workflows met transacties, relaties en bedrijfsregels horen in Laravel. Alumio is sterk in connectiviteit en transformatie, niet in het uitvoeren van diepe domeinlogica. De combinatie levert het beste resultaat: Alumio voor transport, Laravel voor beslissingen.

Wat als mijn externe API verandert?

Dan pas je de mapping in Alumio aan, niet je Laravel-code. Dat is precies de winst van deze scheiding. Je domeinlogica weet niets van het formaat van externe systemen, dus een API-wijziging raakt alleen de Alumio-configuratie. Geen deploy van je applicatie, geen risico voor je businesslogica.