Drie valkuilen in SAP-integratieprojecten die je nergens leest

De bekende clichélijstjes ken je: te weinig testen, geen Git, geen exception-subprocessen. Allemaal waar, maar je hoort het in elk webinar. Hieronder drie valkuilen die we in de praktijk zien terugkomen en die zelden op zo’n lijst staan — met het alternatief erbij.

1. Packaging volgt je organisatie, niet je integratielandschap

Bij een retailer zagen we dat de eerste Salesforce-koppelingen vanuit het webkanaal in een package “WEB” terechtkwamen. Toen er een SAP-Salesforce-koppeling bijkwam, ging die naar een package “Salesforce”. De OMS-Salesforce-koppeling vervolgens naar een “OMS”-package. Resultaat: drie packages met koppelingen die in essentie hetzelfde doelsysteem raken, geen logische plek om iets terug te vinden, en geen overzicht van wat er allemaal richting Salesforce gaat.

De oorzaak zat niet in de techniek. Er was vanuit de business geen architect benoemd en geen bron- en doelarchitectuur vastgelegd, dus elke nieuwe koppeling werd vanuit het project van dat moment opgehangen — telkens met een ander packaging-instinct.

Alternatief: kies één packaging-principe vóórdat je begint — meestal per integratiedomein of per doelsysteem — en houd je eraan, ook als de organisatie eromheen verandert. Trek bestaande packages eerder mee dan dat je een nieuwe maakt. Beleg deze keuze bij een architect, niet bij het project.

2. De router wordt stilletjes een business rules engine

Een tweede patroon: een iFlow ontvangt verkooporder-events uit SAP en routeert ze naar CRM. Bij oplevering was er één conditie. Een jaar later staan er twaalf in de Content Based Router — op ordertype, klantcategorie, organisatiecode, statusvelden — en niemand durft er meer iets uit te halen.

Alternatief: filter aan de bron als de condities op stabiele kenmerken werken. Met Event Mesh of AEM kun je meerdere topics publiceren of subscription-filters zetten, zodat niet-relevante events de iFlow nooit raken. Wat dan nog over is, gaat in een Value Mapping of externe lookup; de router weet alleen welke uitkomst hij krijgt. Bij echt veel regels: een Decision Service (SAP Business Rules op BTP). Groovy is geen alternatief — het verschuift het probleem naar een plek waar functioneel beheer er niet meer bij kan.

3. Pas in productie weet je wat het kost

Berichtvolumes, runtime-kosten en opslagkosten worden bij ontwerp zelden meegerekend. Pas na een paar maanden in productie zie je dat één integratie de helft van je tenant-budget opslokt, of dat een polling-iFlow elke vijf minuten doorloopt zonder dat iemand dat nog gebruikt.

Alternatief: zet bij oplevering een eenvoudig kostenoverzicht per integratie op (volume, frequentie, geschatte processing time) en houd dat bij. Polling-iFlows krijgen een einddatum of een eigenaar die elk kwartaal bevestigt dat ze nog nodig zijn.

De rode draad in deze drie: het zijn geen ontwerpfouten op dag één, het zijn keuzes die zich pas onder druk laten zien — bij groei, na overdracht, of bij het eerste echte incident. Wie er aan de voorkant rekening mee houdt, bespaart zichzelf maandenwerk later.