Al je systemen zijn gekoppeld. Alle data komt aan. Alleen…niet altijd in de juiste volgorde!?
Ontdek waarom API-koppelingen alleen niet genoeg zijn en hoe een slimme queue processen tussen Exact-applicaties bewaakt.
6 min leestijd

In dit artikel
Op papier ziet het er perfect uit.
Je webshop is gekoppeld aan Exact. Je WMS is gekoppeld aan Exact. Je CRM, PIM of productieapplicatie wisselt gegevens uit met Exact.
De API’s werken. De verbindingen staan. De data komt aan.
En toch kan het proces vastlopen.
Waarom?
Omdat verschillende applicaties niet automatisch begrijpen in welke volgorde een ander systeem de data nodig heeft.
En dat probleem wordt steeds relevanter naarmate organisaties meer kiezen voor een best-of-breed strategie*.
Ieder systeem kent zijn eigen werkelijkheid
Best-of-breed is een logische keuze.
In plaats van één softwarepakket voor alles, kies je voor ieder bedrijfsproces de applicatie die daar het beste in is.
Een gespecialiseerd WMS voor het magazijn. Een CRM voor sales. Een PIM voor productinformatie. Een webshop voor e-commerce. Een applicatie voor planning of productie.
En Exact als financieel of ERP-hart van de organisatie.
Iedere applicatie kan afzonderlijk uitstekend functioneren.
Maar iedere applicatie werkt ook vanuit zijn eigen proceslogica en zijn eigen tempo.
En daar ontstaat een interessant probleem.
Want wat voor systeem A een logische volgende gebeurtenis is, hoeft voor Exact nog helemaal niet de volgende stap te zijn.
Systeem A is al bij stap 3. Exact nog bij stap 2.
Stel dat een bedrijfsproces uit vijf stappen bestaat:
- Inkooporder aanmaken
- Productiehandeling verwerken
- Uitlevering registreren
- Factuur aanmaken
- Voorraad bijwerken
Voor het bedrijfsproces is die volgorde essentieel.
Stap 3 kan afhankelijk zijn van stap 2. En stap 4 kan pas worden uitgevoerd wanneer stap 3 succesvol is verwerkt.
Maar technisch kunnen het allemaal afzonderlijke gebeurtenissen of API-calls zijn.
De externe applicatie gaat ondertussen gewoon door.
Stap 1 wordt verstuurd. Stap 2 wordt verstuurd. Stap 3 staat alweer klaar.
De applicatie kan dan feitelijk zeggen:
“Hier is stap 3.”
Terwijl Exact nog zegt:
“Wacht even. Ik ben nog bezig met stap 2.”
Technisch doet niemand iets verkeerd.
De verzendende applicatie verstuurt de data. De API ontvangt de berichten. Exact verwerkt de opdrachten.
Alleen begrijpen de systemen niet automatisch elkaars volgorde.
Een API-koppeling lost dat niet vanzelf op
Dit is een belangrijk onderscheid.
Met een API creëer je een technische verbinding tussen twee systemen.
Systeem A kan bijvoorbeeld tegen Exact zeggen:
maak deze order aan
En Exact kan daarop reageren.
Maar een API weet daarmee niet automatisch hoe het volledige bedrijfsproces tussen beide systemen eruitziet.
Welke transactie moet eerst?
Mag de volgende al worden uitgevoerd?
Is de voorgaande transactie daadwerkelijk succesvol verwerkt?
Wat moet er gebeuren wanneer Exact tijdelijk niet reageert?
En wat gebeurt er met stap 4 en 5 wanneer stap 3 mislukt?
Dat zijn geen vragen over één API-call.
Dat zijn vragen over proceslogica en integratiearchitectuur.
Van datadump naar gecontroleerde verwerking
Tijdens een technische bespreking bij Sense-Cloud kwam dit probleem onlangs heel duidelijk naar voren.
Verschillende applicaties kunnen hun gebeurtenissen richting Exact sturen, maar ergens moet worden bewaakt wat wanneer verwerkt mag worden.
De oplossing is eigenlijk verrassend eenvoudig uit te leggen:
Zet een intelligente wachtrij tussen de applicatie en Exact.
In plaats van iedere gebeurtenis onmiddellijk door te sturen, worden de binnenkomende acties eerst opgevangen.
De queue bewaakt vervolgens de verwerking:
ontvangen → ordenen → verwerken → controleren
De applicatie aan de voorkant hoeft daardoor niet alle interne afhankelijkheden van Exact te kennen.
De applicatie kan zijn gebeurtenissen aanleveren.
De integratielaag zorgt ervoor dat ze gecontroleerd en in de juiste volgorde richting Exact gaan.
Zie het als verkeer bij een druk kruispunt
Zonder verkeersregeling kunnen alle auto’s technisch gezien het kruispunt bereiken.
Dat is het probleem niet.
Het probleem ontstaat wanneer iedereen tegelijkertijd besluit door te rijden.
Een queue vervult in een integratie eigenlijk een vergelijkbare functie.
Er komt data vanuit verschillende processen binnen.
Maar niet alles hoeft onmiddellijk door.
Eerst deze transactie.
Geslaagd?
Dan de volgende.
Daarna de volgende.
Zo wordt een stroom losse technische gebeurtenissen weer een gecontroleerd bedrijfsproces.
En wat als één stap mislukt?
Daar wordt het echt interessant.
Want een betrouwbare integratie moet niet alleen goed functioneren wanneer alles goed gaat.
Stel:
- Inkooporder aanmaken — geslaagd
- Productiehandeling — geslaagd
- Uitlevering — mislukt
- Factuur aanmaken — wacht
- Voorraad bijwerken — wacht
Dan wil je niet het hele proces opnieuw uitvoeren.
Stap 1 en 2 zijn immers al verwerkt.
Je wilt precies weten welke stap is mislukt.
Die actie moet zichtbaar zijn.
Vervolgens moet die specifieke actie opnieuw aangeboden kunnen worden wanneer het probleem is opgelost.
Pas daarna kan de rest van de queue verder.
Dat betekent dat een goede queue niet alleen zorgt voor volgorde, maar ook voor zaken als:
- monitoring;
- foutafhandeling;
- retry;
- traceerbaarheid.
De wachtrij wordt daarmee veel meer dan een technische buffer.
Het wordt een mechanisme waarmee het bedrijfsproces tussen verschillende systemen beheersbaar blijft.
En juist bij best-of-breed wordt dit belangrijk
Dit is de interessante keerzijde van best-of-breed.
Hoe meer gespecialiseerde applicaties een organisatie gebruikt, hoe meer zelfstandige processen uiteindelijk samen moeten komen.
Een webshop weet veel van e-commerce.
Een WMS weet veel van logistiek.
Een productieapplicatie kent het productieproces.
Een CRM kent de klant.
En Exact kent zijn eigen administratieve en ERP-processen.
Maar geen van die systemen begrijpt automatisch de volledige interne logica van alle andere systemen.
Ze spreken via API’s met elkaar, maar dat betekent nog niet dat ze elkaars proces begrijpen.
Daarom neemt met iedere extra applicatie niet alleen het aantal koppelingen toe.
Ook de noodzaak om de regie tussen die koppelingen goed te organiseren neemt toe.
Dat verandert ook de vraag die je bij een koppeling moet stellen
Bij een nieuwe integratie wordt vaak begonnen met:
“Heeft deze applicatie een API?”
Daarna:
“Kunnen we hem koppelen aan Exact?”
Dat zijn belangrijke vragen.
Maar ze zijn niet voldoende.
Er hoort nog een vraag achteraan:
“Wie bewaakt straks de volgorde van het proces?”
Want wanneer verschillende systemen ieder vanuit hun eigen logica data gaan aanbieden, moet ergens worden bepaald wat eerst komt, wat moet wachten en wat er gebeurt wanneer iets foutgaat.
Van API-koppeling naar integratielaag
Binnen Sense-Cloud gebruiken we hiervoor Clickker en CAS.
Clickker zorgt voor gestandaardiseerde toegang tot Exact.
CAS kan daar vervolgens proceslogica omheen organiseren, waaronder flows en queue-functionaliteit.
Daarmee ontstaat tussen de best-of-breed applicatie en Exact een laag die niet alleen zorgt dat data kan worden verstuurd, maar ook kan helpen bewaken hoe en wanneer die data wordt verwerkt.
Dat verschil is belangrijk.
Want:
Data ontvangen is nog geen proces.
Systemen koppelen is nog geen procesregie.
En:
Een werkende API betekent nog niet automatisch een werkende keten.
De volgende keer dat je een applicatie aan Exact koppelt…
Vraag daarom niet alleen:
Kan deze applicatie data naar Exact sturen?
Vraag ook:
Weet Exact welke data eerst moet?
Weet de andere applicatie wanneer Exact klaar is voor de volgende stap?
En als beide systemen dat niet van elkaar weten:
Wie bewaakt dan de volgorde?
Want bij een best-of-breed strategie zullen steeds meer systemen met elkaar moeten communiceren.
Alle data kan technisch keurig aankomen.
Maar iemand moet nog steeds bepalen wat eerst komt.
API’s verbinden systemen. Een slimme queue bewaakt het proces.
*Best-of-breed betekent dat een organisatie niet één softwarepakket voor alles gebruikt, maar per bedrijfsproces de beste gespecialiseerde applicatie kiest.
Bijvoorbeeld: Exact voor ERP/financiën, een apart WMS voor logistiek, een CRM voor sales en een PIM voor productinformatie. Het voordeel is specialisatie; de uitdaging is dat al die systemen vervolgens goed met elkaar moeten samenwerken en data in de juiste volgorde moeten uitwisselen.