Een integratie kan correct reageren en toch gegevens in twee systemen verschillend achterlaten. Een verzoek kan een time-out krijgen nadat het externe systeem de wijziging heeft opgeslagen; een gebeurtenis kan te laat binnenkomen; of een lokale update kan een veld wijzigen dat ook door het andere systeem wordt beheerd. Daarom is het, naast het synchroniseren van gebeurtenissen, verstandig om statussen te kunnen vergelijken en verschillen bewust op te lossen.
Gegevens tussen systemen reconciliëren in PHP is een periodiek of op aanvraag uitgevoerd proces dat verschillen tussen gerelateerde records identificeert, bepaalt wat ze betekenen en een actie voorstelt of uitvoert. Het is niet de bedoeling om het ene systeem zonder onderscheid over het andere heen te kopiëren. Om te voorkomen dat geldige informatie verloren gaat, moet je bepalen welke bron voor elk gegeven leidend is, bewijs van de vergelijking bewaren en de applicatie beschermen tegen herhaalde of grootschalige correcties.
Bepaal welk systeem leidend is voordat je vergelijkt
Er is niet altijd één enkele bron van waarheid voor een volledige entiteit. Het CRM kan verantwoordelijk zijn voor de handelsnaam en contactgegevens, terwijl het facturatiesysteem de betaalstatus en het gevalideerde fiscale identificatienummer beheert. Als je zonder de velden te controleren een heel systeem als leidend aanwijst, kan reconciliatie correcte informatie vervangen door een oude of onvolledige kopie.
Leg het eigenaarschap vast van de velden die worden uitgewisseld. Registreer voor elk veld welk systeem wijzigingen mag initiëren, welk systeem bij een conflict voorrang heeft, of de waarde null mag zijn en welke transformaties acceptabel zijn. Maak ook onderscheid tussen bewerkbare en afgeleide velden: een berekend totaal moet bijvoorbeeld mogelijk opnieuw worden berekend op basis van de onderdelen, in plaats van te worden gekopieerd.
- Eigenaarschap per veld: bepaal wie de waarde vaststelt en wat er moet gebeuren als beide systemen wijzigingen bevatten.
- Samenvoegregels: specificeer of ontbrekende gegevens kunnen worden aangevuld zonder bestaande gegevens te vervangen.
- Uitzonderingen: geef aan voor welke conflicten goedkeuring, aanvullende validatie of tussenkomst van het verantwoordelijke team nodig is.
Als er geen veilige regel is, markeer je het conflict voor beoordeling in plaats van willekeurig het record met de recentste datum te kiezen. Klokken kunnen uiteenlopen en een tijdstempel bewijst op zichzelf niet dat een wijziging legitiem is.
Maak de vergelijking reproduceerbaar
Voor een bruikbare vergelijking moet hetzelfde record aan beide kanten kunnen worden geïdentificeerd. Gebruik een gedeelde stabiele identifier of een expliciet bijgehouden koppelingstabel. Vertrouw niet uitsluitend op namen, e-mailadressen of andere velden die kunnen veranderen, dubbel voorkomen of op verschillende manieren kunnen worden genormaliseerd. Als er geen eenduidige relatie kan worden vastgesteld, classificeer je het geval als een nog te koppelen record in plaats van records op basis van een benadering samen te voegen.
Vergelijk waarden die zijn genormaliseerd volgens gedocumenteerde regels, bijvoorbeeld voor spaties, hoofdletters of datumnotaties. Bewaar ook de oorspronkelijke waarde, want normaliseren voor de vergelijking geeft geen toestemming om de opgeslagen gegevens te wijzigen. Let op tijdzones, decimale precisie, lege waarden en het verschil tussen een ontbrekend veld en een aanwezig veld met de waarde null. Als je deze toestanden als gelijk behandelt, kunnen relevante wijzigingen onopgemerkt blijven.
Definieer voor grote datasets een verwerkingsvenster en een watermark, zoals een wijzigingsdatum of een paginatiecursor. Sla het voortgangspunt pas op wanneer de batch consistent is verwerkt. Als de provider geen betrouwbare markeringen biedt, kan een minder frequente volledige scan of een combinatie van steekproeven en gerichte reconciliatie veiliger zijn dan doen alsof incrementele verwerking mogelijk is terwijl de API dat niet garandeert. De strategie hangt af van de limieten, stabiliteit en daadwerkelijke garanties van elk systeem.
Scheid in PHP het ophalen van gegevens van het vergelijken en het opslaan van resultaten. Een vergelijkingsfunctie kan bijvoorbeeld twee genormaliseerde representaties ontvangen en een lijst met getypeerde verschillen teruggeven, zonder externe aanroepen uit te voeren of records bij te werken. Door deze scheiding kun je regels met gecontroleerde gevallen testen en voorstellen beoordelen voordat je schrijfbewerkingen inschakelt.
Classificeer verschillen en bepaal de reactie
Niet elk verschil wijst op een fout en voor elke categorie is een ander beleid nodig. Een expliciete classificatie verbetert de diagnose en voorkomt dat één destructieve regel op uiteenlopende situaties wordt toegepast.
- Ontbrekend: het record bestaat in het ene systeem, maar niet in het andere. Controleer of het om een recente aanmaak, een legitieme verwijdering, een filter of een paginatiefout gaat.
- Dubbel: meerdere records lijken bij dezelfde entiteit te horen. Kies niet automatisch een record zonder een verifieerbare identiteitsregel.
- Onverenigbare wijziging: beide kanten hebben een veld gewijzigd dat door beide wordt beheerd. Pas een eigendomsbeleid toe of stuur het conflict ter beoordeling door.
- Ongeldig gegeven: de waarde voldoet niet aan de verwachte indeling of beperkingen. Plaats deze in quarantaine en voorkom dat de waarde verder wordt verspreid.
- Tijdelijke afwijking: het verschil kan door een vertraging in de levering of verwerking zijn ontstaan. Probeer het opnieuw of wacht een vastgestelde periode voordat je het als een blijvend conflict aanmerkt.
Scheid drie fasen: detectie van het verschil, besluitvorming over de actie en toepassing van de wijziging. Een voorstel kan bestaan uit het bijwerken van een veld, het aanmaken van een koppeling, het aanvragen van een beoordeling of niets doen. Door deze fasen gescheiden te houden, kun je beginnen in alleen-lezenmodus en nagaan wat er zou veranderen voordat je automatische correcties inschakelt.
Pas wijzigingen toe zonder nieuwe schade te veroorzaken
Automatiseer alleen gevallen waarvoor duidelijke en verifieerbare regels bestaan. Bied voor de overige gevallen een beoordelingswachtrij met de identifier van de entiteit, de waargenomen waarden, de regel die van toepassing zou zijn en de voorgestelde actie. De interface of operationele werkwijze moet het mogelijk maken het voorstel te accepteren, af te wijzen of op te schalen, en waar van toepassing vastleggen wie de beslissing heeft genomen.
Ontwerp bewerkingen idempotent: als dezelfde afwijking opnieuw wordt verwerkt, mogen er geen duplicaten ontstaan en mogen waarden niet eindeloos heen en weer wisselen. Controleer vóór het schrijven of het record nog steeds de verwachte status heeft. Als het sinds het uitlezen is gewijzigd, stop je de update en vergelijk je opnieuw. Gebruik versies, voorwaardelijke schrijfbewerkingen of idempotency keys wanneer de externe API dat ondersteunt; ga er niet van uit dat deze mogelijkheden bestaan zonder dit te controleren.
Beperk de reikwijdte met kleine batches, limieten voor het aantal wijzigingen per uitvoering en opties om te pauzeren. Een correctie die het verwachte volume overschrijdt, moet worden gestopt of goedkeuring vereisen, niet stilzwijgend doorgaan. Leg voor wijzigingen met grote impact een mogelijke compenserende bewerking vast, maar presenteer die niet als een gegarandeerde rollback: er kunnen latere wijzigingen zijn of externe effecten die niet ongedaan kunnen worden gemaakt.
Registreer elke uitvoering om onderzoek en herhaling mogelijk te maken
Bewaar een uitvoerings-ID, de begin- en eindtijd, het verwerkte bereik of de verwerkte cursor, de geraadpleegde systemen, het resultaat per categorie en eventuele fouten. Bewaar voor elke afwijking de correlatiesleutel, relevante waarden of een beveiligde weergave daarvan, de geëvalueerde regel, de voorgestelde actie en het resultaat van de toepassing. Zo kun je uitleggen waarom een beslissing is genomen en een integratiefout onderscheiden van een daadwerkelijk conflict.
Beveilig de logs: ze kunnen persoonsgegevens, indirecte inloggegevens of commerciële informatie bevatten. Voorkom dat volledige payloads worden vastgelegd als specifieke velden volstaan, beperk de toegang en stel een bewaartermijn vast. Neem verwijzingen naar de bronrecords en het waarnemingstijdstip op om onderzoek te vergemakkelijken, zonder van de log een tweede, onbeheerde database te maken.
Probeer alleen tijdelijke fouten opnieuw, met limieten en een oplopende wachttijd. Registreer nieuwe pogingen en behandel permanente fouten — zoals ongeldige gegevens of onvoldoende rechten — apart om cycli te voorkomen waarin hetzelfde probleem steeds opnieuw optreedt. Een uitvoering moet volgens een bekend criterium kunnen worden hervat en mag er niet van afhangen dat het PHP-proces onbeperkt actief blijft.
Checklist voordat je automatiseert
- Is voor elk veld bepaald welk systeem leidend is en hoe null-waarden en verwijderingen worden behandeld?
- Koppelen identifiers records eenduidig en worden duplicaten afgehandeld?
- Zijn paginatie, vertragingen, API-limieten, nieuwe pogingen en gelijktijdige wijzigingen getest?
- Zijn verschillen geclassificeerd en worden uitzonderingen ter beoordeling of in quarantaine geplaatst?
- Kan de vergelijking in alleen-lezenmodus worden uitgevoerd en de voorgestelde acties tonen?
- Zijn schrijfbewerkingen idempotent, afhankelijk van de verwachte status en begrensd qua volume?
- Worden beslissingen en resultaten geregistreerd met passende gegevensbescherming en toegangsbeveiliging?
- Zijn er tests met representatieve gegevens, waaronder conflicten, lege waarden, duplicaten en gedeeltelijke fouten?
Begin met observeren en classificeren, niet met corrigeren. Activeer automatisering pas voor afwijkingen met een laag risico nadat de regels met echte gegevens zijn gevalideerd en de voorstellen zijn beoordeeld. Zorg voor een manier om het proces te pauzeren en controleer periodiek op fout-positieven, onopgeloste gevallen en wijzigingen in externe systemen. Zo wordt reconciliatie een herhaalbare operationele controle, in plaats van een synchronisatie die conflicten verbergt totdat iemand de gevolgen ervan ontdekt.
