Bij ZangaBee vinden we het leuk om complexe beperkingen om te zetten in efficiënte, schaalbare oplossingen. Een van onze recente integratieprojecten draaide precies daarom.
De uitdaging
We werkten met een legacy WMS-systeem dat alleen productdata kon exporteren als een nachtelijke flat file dump — telkens duizenden regels. Er was geen mogelijkheid om alleen gewijzigde producten te exporteren.
Om het nog ingewikkelder te maken, was deze export geformatteerd als een CSV-bestand met vaste veldbreedte, waarbij elke regel slechts één kolom bevatte. Als we elk product zomaar zouden doorsturen naar het doelsysteem, zouden we al snel de API-verzoeklimieten overschrijden.
Onze oplossing
We hadden een manier nodig om te bepalen welke productrecords sinds de vorige run echt veranderd waren. Door Celigo’s nieuwe Lookup Cache-functie te combineren met JavaScript, maakten we van deze volledige export een slimme, delta-gebaseerde integratie — waarbij alleen gewijzigde records werden doorgestuurd.
Zo hebben we het aangepakt
- Regels splitsen en een checksum genereren
Het exportbestand wordt opgehaald van een FTP-server en ingeladen als een pipe-delimited CSV. Elke regel verschijnt in eerste instantie als één lange string.
Om dit op te splitsen en een unieke identifier voor veranderingen te creëren, gebruikten we een transform script hook die:
- De regel splitst in bruikbare velden.
- Een checksum genereert (bijvoorbeeld via een hashfunctie) op basis van de data.
Als je data al gestructureerd is in kolommen, kun je de splitsing overslaan en de checksum direct genereren vanuit options.record.
- Vergelijken met gecachte checksums
Tijdens de PreSave-fase van de export:
- Halen we bekende checksums op uit de Lookup Cache via één API-call per pagina (niet per record).
- Vergelijken we de huidige checksum met die uit de cache.
- Als de checksum veranderd is, markeren we het record met
changed = true, wat later als filter dient tijdens het importeren.
Om de prestaties hoog te houden:
- Stelden we de paginagrootte van de export in op minder dan 1000 (het maximum dat de Lookup Cache API ondersteunt).
- Werden cache-calls buiten eventuele loops gedaan, zodat er maar één cache-opvraag per pagina is.
- De Lookup Cache bijwerken
Eventuele nieuwe of gewijzigde checksums worden aan het eind van het proces teruggeschreven naar de cache, zodat ze klaarstaan voor de volgende nachtelijke run.
Het resultaat
In plaats van elke nacht duizenden onveranderde records te pushen, detecteert en verwerkt de flow nu alleen de deltas — waardoor de integratie licht, snel en binnen de limieten blijft.
Deze aanpak loste niet alleen een technische bottleneck op, maar gaf onze klant ook een toekomstbestendig patroon om te werken met statische exports vanuit legacy-systemen.
