Salesforce-integratiearchitectuur: patronen die echt schalen

Het integratiepatroon dat je kiest, niet de tool, bepaalt of Salesforce-data schoon blijft of verandert in een rommelige synchronisatie. Point-to-point-koppelingen zijn snel gebouwd en snel kapot. Middleware en event-driven patronen kosten vooraf meer, maar overleven het derde, vierde en tiende systeem dat je aansluit. De meeste integratieproblemen komen voort uit die vroege architectuurbeslissing, niet uit Salesforce zelf.

Waarom lopen de meeste Salesforce-integraties vast?

Twee systemen delen zelden hetzelfde datamodel. Salesforce denkt in Accounts, Contacts en Opportunities, een ERP denkt in klantstamgegevens en verkooporders. Elke integratie moet die vormen op elkaar afstemmen, en teams die deze stap overslaan, plakken uiteindelijk velden op Salesforce-objecten om na te bootsen wat het andere systeem stuurt. Zes maanden later weet niemand meer waarom Custom_ERP_ID__c bestaat of wat er gebeurt als het leeg is.

De oplossing is geen tool maar een canoniek datamodel: bepaal wat een "Account" over je systemen heen betekent voordat je ook maar één integratieflow schrijft, en bouw de transformatielogica rond die definitie in plaats van het laatst gekoppelde systeem het schema te laten dicteren.

Point-to-point of middleware: welk patroon past?

Point-to-point-integraties, een directe API-aanroep van Salesforce naar systeem B, zijn logisch voor één of twee koppelingen met eenvoudige, stabiele data. Zodra je drie of meer systemen integreert, wordt point-to-point een onbeheersbaar web: elke nieuwe koppeling vergroot het aantal plekken waar een veldmapping uit de pas kan gaan lopen.

Een middleware- of ESB-laag, zoals MuleSoft, Boomi of een lichtere eigen message broker, centraliseert transformatie en routering, zodat Salesforce met één integratielaag praat in plaats van rechtstreeks met vijf downstream-systemen. Dat is een echte infrastructuurinvestering, dus bewaar die voor integratielandschappen die werkelijk groeien, niet voor één losse sync.

Hoe ga je om met realtime versus batchdata?

Niet alles hoeft direct te synchroniseren, en elke integratie als realtime behandelen is precies hoe teams zonder enig voordeel door hun Salesforce API-limieten heen gaan. Een handige vuistregel:

• Gebruik Platform Events of Change Data Capture voor alles wat een gebruiker direct moet zien, zoals orderstatus of updates van supportcases.
• Gebruik geplande batchjobs en de Bulk API voor grote, niet-urgente volumes, zoals de nachtelijke financiële afstemming.
• Vermijd polling-loops die de REST API op een timer aanroepen alleen omdat dat makkelijker te bouwen is. Ze verspillen API-aanroepen en voegen vertraging toe vergeleken met event-driven alternatieven.

Change Data Capture wordt te weinig gebruikt: het publiceert wijzigingsevents op veldniveau voor standaard- en custom objecten, zonder dat je eigen triggers hoeft te bouwen om te detecteren wat er is veranderd.

Hoe voorkom je dubbele records en mislukte syncs?

Elke integratie herhaalt vroeg of laat een verzoek, door een time-out of een job in de wachtrij die twee keer draait. Is je integratie niet idempotent, dan levert die herhaling een dubbele Opportunity of een dubbel getelde metric op. De oplossing is een stabiel extern ID-veld op het Salesforce-object, gecombineerd met upsert-aanroepen op dat ID in plaats van blinde create-aanroepen.

Foutafhandeling verdient dezelfde zorg als het normale pad. Mislukte records horen in een dead-letter queue of foutenlog terecht te komen met genoeg context om ze opnieuw te verwerken, en mogen niet stilletjes verdwijnen omdat één record in een batch van 200 de validatie niet haalde.

MuleSoft of een zelfgebouwde integratielaag?

MuleSoft verdient zijn kosten terug bij veel systemen, een eigen integratieteam en connectoren die goed aansluiten op wat je bouwt. Een zelfgebouwde laag met Apex, een message queue en een lichte orchestratieservice is via gericht ontwikkelwerk vaak goedkoper op te leveren voor een handvol duidelijk afgebakende integraties, maar legt het onderhoud op lange termijn bij je eigen engineeringteam.

Het is een afweging tussen zelf bouwen en kopen die afhangt van het aantal integraties en hoe snel je systeemlandschap groeit. Die beslissing is een frisse blik van buitenaf waard voordat je je vastlegt, en daar komen de integratiediensten van Tekunda in beeld: we helpen teams het patroon kiezen en implementeren dat past bij hun echte roadmap, niet het patroon dat er in een vendordemo makkelijk uitzag.

FAQ

Wat is het verschil tussen Platform Events en Change Data Capture?

Platform Events zijn zelfgedefinieerde berichten die je expliciet publiceert vanuit Apex of een flow, terwijl Change Data Capture automatisch events uitzendt wanneer records van standaard- of custom objecten veranderen, zonder eigen publicatielogica.

Heb ik MuleSoft nodig om Salesforce met andere systemen te integreren?

Nee. MuleSoft is één optie naast onder meer Boomi, Informatica of een zelfgebouwde middlewarelaag. De juiste keuze hangt af van hoeveel systemen je koppelt en wie de integratie op lange termijn onderhoudt.

Hoe voorkom ik dat ik de Salesforce API-limieten bereik?

Verwerk grote datavolumes in batches via de Bulk API in plaats van REST-aanroepen per record, gebruik Platform Events of Change Data Capture in plaats van polling, en combineer gerelateerde aanroepen waar de API composite requests ondersteunt.

Wat is de veiligste manier om een externe integratie bij Salesforce te authenticeren?

Gebruik een Connected App met OAuth 2.0, beperk de rechten tot wat de integratie nodig heeft en vervang inloggegevens volgens een schema in plaats van te vertrouwen op één langlevend token.