Een zakelijke import zou niet moeten dwingen te kiezen tussen het afbreken van een volledige batch vanwege één defecte rij of het opnemen van twijfelachtige gegevens. Dataquarantaine bij PHP-imports biedt een derde optie: geldige records accepteren, records die aandacht vereisen isoleren en voldoende context bewaren om ze veilig af te handelen.
Dataquarantaine is niet gewoon een map met fouten of een tabel waarin mislukte rijen worden opgeslagen. Het is een operationele workflow met classificatieregels, expliciete statussen, gecontroleerde correcties en nieuwe verwerkingspogingen die geen effecten dupliceren. Voor het ontwerp is het verstandig eerst af te spreken wat «geldig» betekent voor de business en welke acties elke rol mag uitvoeren.
Classificeer fouten voordat u beslist wat u met elke rij doet
Een import omvat vaak verschillende controles. Door die van elkaar te scheiden, kunt u het resultaat uitleggen en bepalen of het record verder kan, moet worden afgewezen of menselijke beoordeling vereist.
- Structurele validatie: controleert de indeling en basisinhoud: aanwezige kolommen, gegevenstypen, interpreteerbare datums, verplichte velden en redelijke grenzen. Een onleesbaar bestand kan de verwerking van de batch verhinderen; een ongeldige datum in één rij zou dat normaal gesproken niet moeten doen.
- Businessregels: controleren domeinvoorwaarden, zoals een niet-negatieve prijs, een actieve klant of een toegestane categorie. Sommige overtredingen kunnen worden afgewezen; andere kunnen afhankelijk zijn van een operationele beslissing.
- Conflicten met bestaande gegevens: detecteren bijvoorbeeld een externe identificatie die al aan een ander record is gekoppeld of een update die uitgaat van een verouderde versie. Zulke conflicten zijn niet altijd op te lossen door het bestand te corrigeren: ze kunnen reconciliatie of beoordeling vereisen.
Stel voor elk fouttype een beleid vast. Voor een ontbrekend optioneel veld kan een standaardwaarde worden gebruikt; een ambigue identiteit mag niet worden opgelost door willekeurig een record te kiezen. Voorkom zowel te toegeeflijke regels als het classificeren van elk defect als fatale fout. De beslissing moet rekening houden met de impact van het accepteren van de gegevens en de kosten van het stilleggen van de batch.
Modelleer expliciete statussen en overgangen
Gebruik statussen met een operationele betekenis, in plaats van de situatie af te leiden uit lege velden of tekstberichten. Een aanvankelijk model kan pending, accepted, rejected en needs_review omvatten. Voeg statussen zoals processing of resolved alleen toe als ze overeenkomen met daadwerkelijke overgangen in uw workflow.
Documenteer wat elke overgang mogelijk maakt. Een rij in afwachting wordt bijvoorbeeld gevalideerd; als deze aan de regels voldoet, wordt ze geaccepteerd, en als er een beoordeelbaar conflict is, blijft ze in afwachting van beoordeling. Een gecorrigeerde rij kan opnieuw worden gevalideerd, maar een geaccepteerde rij mag niet opnieuw worden verwerkt alsof deze nieuw is. Registreer de batchstatus afzonderlijk: een batch kan eindigen met geaccepteerde rijen en andere rijen in quarantaine. Daarom beschrijft «gedeeltelijk voltooid» het resultaat beter dan één indicator voor succes of mislukking.
Statussen moeten overeenkomen met verifieerbare beslissingen. «Afgewezen» moet betekenen dat de zakelijke wijziging niet is toegepast; «beoordeling vereist» geeft aan dat een persoon een beslissing moet nemen. Als het is toegestaan bestaande gegevens te overschrijven, specificeer dan wie dat mag doen en onder welke voorwaarden.
Bewaar het origineel en licht elke beslissing toe
Sla de oorspronkelijke invoer van de rij op, evenals de genormaliseerde waarden en het validatieresultaat, maar doe dat afzonderlijk. Zo kunnen discrepanties worden onderzocht — bijvoorbeeld verschillen tussen een ontvangen datum en de interpretatie ervan — zonder dat de getransformeerde versie het enige beschikbare bewijs wordt.
Een persistentiestructuur kan een batch-ID, rijnummer, bron, bestandsreferentie, oorspronkelijke inhoud, status, gedetecteerde fouten, aanmaak- en afhandelingsdatums en de verantwoordelijke persoon bevatten. Registreer redenen als stabiele codes en begrijpelijke berichten: een code zoals customer_id_ambiguous helpt bij het filteren en meten van gevallen; het bericht moet uitleggen welke gegevens moeten worden gecontroleerd. Vertrouw niet op vrije tekst als enige classificatielogica.
Bewaar ook de context die nodig is om de analyse te reproduceren: de versie of ID van de gebruikte regels, de externe ID en gegevens die relevant zijn voor het conflict. Sla geen geheimen of onnodige persoonsgegevens op in technische logs. Stel toegangscontroles en een bewaartermijn vast die passen bij de gevoeligheid en de toepasselijke verplichtingen. Als het volledige bestand informatie kan bevatten die niet nodig is om een rij af te handelen, beperk dan de blootstelling ervan.
Corrigeer en probeer opnieuw zonder effecten te dupliceren
Een veilige nieuwe verwerkingspoging begint met het onderscheid tussen de rij en de poging om die te verwerken. Geef elke rij binnen haar scope een stabiele identiteit, bijvoorbeeld een combinatie van batch en rijnummer of een gevalideerde externe sleutel. Definieer bij herhaalbare imports ook een idempotency key waarmee dezelfde bewerking kan worden herkend. De keuze hangt ervan af of het opnieuw laden van hetzelfde bestand gegevens moet bijwerken, negeren of een nieuwe versie moet aanmaken.
Pas bij de verwerking van een rij de zakelijke wijziging en de statuswijziging waar mogelijk atomair toe: beide bewerkingen worden samen bevestigd, of geen van beide. In PHP kan een databasetransactie wijzigingen beschermen die dezelfde verbinding gebruiken; daarmee wordt een aanroep naar een externe API niet vanzelf atomair. Gebruik voor externe effecten een strategie die compatibel is met het ontvangende systeem, zoals idempotency keys, een transactionele outbox-tabel of een compensatie die voor het betreffende geval is ontworpen.
Voer na een correctie de relevante validaties opnieuw uit en bewaar de eerdere geschiedenis. Verwijder de oorspronkelijke fout niet: voeg een nieuwe poging met het resultaat ervan toe. Vermeld welke versie is toegepast als regels of referentiegegevens veranderen, en voorkom dat een nieuwe poging een al geaccepteerde beslissing stilzwijgend wijzigt. De nieuwe verwerkingspoging mag alleen invloed hebben op de geselecteerde records en mag niet zonder onderscheid de volledige batch opnieuw uitvoeren.
Ontwerp een operationeel en controleerbaar beoordelingsproces
De beoordelingsinterface moet helpen bij het nemen van een beslissing en niet alleen een technische uitzondering tonen. Vermeld de ontvangen waarde, de reden, het betrokken veld, relevante context en, waar dat veilig is, een voorgestelde correctie. Maak filteren op status, batch, fouttype en ouderdom mogelijk; maak duidelijk welke rijen al effecten hebben veroorzaakt en welke niet.
Registreer wie de zaak heeft beoordeeld, wanneer dat gebeurde, welke waarde is gewijzigd, welke beslissing is genomen en waarom. Maak onderscheid tussen een correctie door een operator en een automatische transformatie. Pas rechten toe op basis van verantwoordelijkheden: wie een bestand mag importeren, hoeft niet per se conflicten te mogen goedkeuren of geaccepteerde records te wijzigen. Overweeg een aanvullende goedkeuring voor wijzigingen met grote impact.
Voorkom dat de tool het eenvoudig maakt om informatie zonder waarschuwing te overschrijven. Controleer uniciteit, rechten en de actuele status van het record opnieuw voordat een correctie wordt geaccepteerd. Als iemand anders de gegevens heeft gewijzigd sinds het conflict werd vastgesteld, toon die situatie dan zodat ze kan worden afgehandeld, in plaats van een verouderde update toe te passen.
Test gedeeltelijke fouten en herstel
Tests moeten zowel de regels als het gedrag van de workflow afdekken. Neem bestanden op met een mix van geldige en ongeldige rijen, onverwachte indelingen, conflicten, tijdelijke databasefouten en herhaalde verwerkingspogingen. Controleer dat een afgewezen rij niet verhindert dat de andere rijen worden geaccepteerd als dat het afgesproken beleid is, en dat een fout binnen een transactie geen gedeeltelijke effecten achterlaat.
- Een rij opnieuw verwerken met dezelfde idempotency key dupliceert geen records of externe acties.
- Door een veld te corrigeren kan een nieuwe validatie worden uitgevoerd zonder het origineel of de geschiedenis te verwijderen.
- Een al geaccepteerde rij wordt niet opnieuw toegepast doordat een andere rij opnieuw wordt verwerkt.
- Conflicten die tussen beoordeling en afhandeling worden gedetecteerd, worden niet stilzwijgend overschreven.
- Foutberichten maken handelen mogelijk zonder onnodige gevoelige gegevens bloot te leggen.
Monitor in productie het aantal en de ouderdom van records in quarantaine, de meest voorkomende redenen, het afhandelingspercentage en fouten bij nieuwe verwerkingspogingen. Een aanhoudende stijging kan wijzen op een wijziging in het bronsysteem, verouderde regels of onduidelijke laad- en gebruiksinstructies. Dataquarantaine werkt wanneer die oorzaken zichtbaar maakt en het mogelijk maakt ze gecontroleerd af te handelen, niet wanneer ze verandert in een onbepaalde opslagplaats voor uitzonderingen.
