Gegevens synchroniseren zonder ongewenst overschrijven

Bepaal de bron per gegeven

Maak geen afspraak dat het CRM altijd leidend is als belangrijke onderdelen eigenlijk elders worden gecontroleerd. Verdeel verantwoordelijkheid per gegeven of logisch geheel. Een voorbeeld: het CRM beheert de accountmanager en commerciële contactpersoon; de administratie beheert goedgekeurde factuurgegevens. De koppeling moet wijzigingen uit een andere richting herkennen en behandelen volgens die afspraak.

Beschrijf ook hoe een medewerker een wijziging moet aanvragen wanneer die niet zelf de bevoegde bron kan aanpassen. Anders ontstaat een schaduwproces: iemand wijzigt toch het doel en de volgende synchronisatie draait dat weer terug. De technische fout lijkt dan een gebruiksfout, terwijl de werkwijze onvoldoende is ontworpen. Eigenaarschap is pas bruikbaar als medewerkers weten waar zij correcties kunnen laten uitvoeren.

Maak een wijziging herkenbaar

Een bruikbare wijziging bevat meer dan de nieuwe waarde. Je wilt weten op welk object die betrekking heeft, welke bron de wijziging maakte en op welke versie de beslissing rust. Een lokale ontvangsttijd vertelt alleen wanneer jouw koppeling het bericht zag. Bij vertraging kan een ouder bericht later aankomen dan een recente wijziging.

Gebruik waar beschikbaar de versie of wijzigingsreferentie van het bronsysteem en bewaar de laatst verwerkte bronversie. Wanneer zo’n voorziening ontbreekt, moet een andere controle worden ontworpen, zoals het opnieuw ophalen van de actuele bronstaat. Presenteer zelf gegenereerde tijdstempels niet als een universele oplossing. Welke aanpak werkt hangt af van de feitelijke API, gelijktijdige wijzigingen en het zakelijke gevolg van een fout.

HTTP beschrijft voorwaardelijke verzoeken, waaronder If-Match. Daarmee kan een API een wijziging laten afhangen van een eerder bekende representatie. Onderzoek of het concrete eindpunt deze mogelijkheid ondersteunt en welke versie-informatie de leverancier daarbij gebruikt; de aanwezigheid van HTTP alleen bewijst dat niet.

RFC 9110: HTTP Semantics ↗

Scheid wijzigen van leegmaken

Een ontbrekend veld kan betekenen dat het niet is meegestuurd, dat de bron het niet kent of dat iemand een bestaande waarde wil verwijderen. Als al deze situaties als leeg worden vertaald, kan een gedeeltelijk bericht ongemerkt bruikbare gegevens wissen. Leg per veld vast welke betekenissen mogelijk zijn en hoe de doelbewerking ermee omgaat.

Test het fictieve voorbeeld van een klant zonder nieuw telefoonnummer maar met een aangepast adres. Een gedeeltelijke adreswijziging mag dan niet automatisch het bestaande telefoonnummer wissen. Test vervolgens een expliciete opdracht om een verouderd nummer te verwijderen. Het juiste resultaat verschilt, ook al lijkt het inkomende veld in beide situaties leeg. Maak de bedoeling aantoonbaar in de invoer en de testverwachting.

Een conflict tussen waarden is iets anders dan dezelfde opdracht tweemaal verwerken. Onderzoek ook dat verschil: Dubbele orders en facturen voorkomen bij herhaalde API-berichten.

Ontwerp een expliciete conflictroute

Een conflict ontstaat bijvoorbeeld wanneer twee bevoegde medewerkers hetzelfde adres aanpassen voordat een uitwisseling is afgerond. Kies niet stilzwijgend voor laatst ontvangen wint. Je kunt één bron laten beslissen, wijzigingen per veld samenvoegen of een medewerker laten beoordelen. Elke keuze vraagt een reden. Voor een afgeschermde financiële referentie kan een andere regel passend zijn dan voor een commerciële notitie.

Maak de beoordeling praktisch. Toon de relevante oude waarde, twee voorgestelde waarden, bronreferenties en de zakelijke vraag die iemand moet beantwoorden. Laat de beoordelaar een keuze vastleggen met reden. Daarna moet de koppeling die keuze kunnen voortzetten zonder hetzelfde conflict bij elke uitvoering opnieuw op te werpen. Bewaar voldoende beslisinformatie voor herstel, maar kopieer niet onbeperkt alle gevoelige broninhoud naar een log.

Voorkom heen-en-weer lussen

Wanneer een koppeling een adres in systeem B wijzigt, kan B daarover een nieuwe gebeurtenis sturen. Zonder herkenning kan die gebeurtenis weer A wijzigen, waarna een nieuwe ronde ontstaat. Zelfs als de waarde gelijk blijft kunnen onnodige API-verzoeken, meldingen of wijzigingsdata ontstaan. Een lus is dus niet uitsluitend zichtbaar als voortdurend verschillende tekst.

Leg vast hoe de eigen bewerking wordt herkend. Denk aan een verwerkingsreferentie, gecontroleerde vergelijking met de gewenste staat of het niet terugschrijven van velden waarvan de andere bron eigenaar is. Test ook normalisatie: een systeem kan hoofdletters aanpassen of spaties verwijderen. De vergelijking moet betekenisvolle wijzigingen herkennen zonder willekeurig alle verschillen te negeren. Beschrijf welke vormverschillen je als gelijkwaardig beschouwt.

Behandel archiveren en verwijderen apart

Een klant archiveren kan betekenen dat nieuwe verkoop niet meer mag, terwijl bestaande documenten behouden moeten blijven. Een verwijderd contact betekent niet vanzelf dat je dezelfde handeling in elke aangesloten administratie moet uitvoeren. Definieer welke zakelijke gebeurtenis wordt doorgegeven en wat in elk systeem de toegestane consequentie is. Betrek de verantwoordelijke eigenaar bij bewaarbeleid en toegang.

Een veilige eerste afspraak kan zijn dat verwijderverzoeken naar beoordeling gaan terwijl archiefstatus automatisch wordt verwerkt. Test wat er gebeurt als een oud bericht na archivering alsnog een wijziging bevat. Zonder regel kan een afgesloten record onbedoeld opnieuw actief worden. Laat de test dus niet alleen een actuele toestand zien, maar ook de volgorde waarin oude en nieuwe gebeurtenissen worden aangeboden.

Maak achterstanden zichtbaar

Een succesvolle verbinding zegt niet dat beide systemen voldoende bijgewerkt zijn. Meet welke bronwijziging als laatste is verwerkt en hoeveel relevante items nog wachten. Toon daarnaast of controles daadwerkelijk zijn uitgevoerd. Een status actueel op basis van een geslaagde technische ping kan een medewerker misleiden wanneer de zakelijke verwerking al uren stil staat.

Bepaal een grens die bij het proces past. Een dagelijks overzicht heeft andere eisen dan een planning voor dezelfde middag. Spreek af welke handeling volgt bij veroudering: alleen waarschuwen, nieuwe acties pauzeren of de bron handmatig raadplegen. De medewerker moet weten of een waarde bruikbaar is voor zijn beslissing. Een nette waarschuwing zonder eigenaar of vervolgactie lost de achterstand niet op.

Test wijzigingen als een reeks

Maak een proef met een eerste wijziging, een tweede wijziging, vertraagde aflevering van de eerste, een dubbel bericht en een handmatige correctie. Controleer na elke stap welke zakelijke waarde hoort te blijven staan. Voeg een herstart toe zodat de proef ook laat zien of de koppeling haar eerder vastgelegde versie- en identiteitsinformatie opnieuw gebruikt.

Bewaar het verwachte eindbeeld naast de uitvoeringsgeschiedenis. Als een test faalt, onderzoek welke aanname over eigenaarschap, volgorde of betekenis onjuist was. Verander niet alleen de technische code totdat het ene voorbeeld groen wordt. Een synchronisatie is pas beheersbaar wanneer de regel ook voor andere representatieve gevallen verklaarbaar blijft. Gebruik de uitkomst om de veldmapping en de instructie voor medewerkers gezamenlijk te verbeteren.

Van uitleg naar een concrete projectkeuze

Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.

• API-koppeling laten maken ↗
• CRM Integratie ↗

Vragen over dit onderwerp

Verder met een aansluitende vraag